iproute2 предварительное создание маршрута, я думаю
Во-первых: я знаю, что мог бы сделать это простым способом с SSH, но я хочу научиться прокладывать маршрут.
Я хочу направить пакеты обратно через тот же интерфейс tun0, с которого они пришли в мою систему.
Я могу сделать это для отдельных маршрутов.
Это работает:
sudo ip route add 74.52.23.120 metric 2 via 10.8.0.1
Но я должен был бы добавить их вручную для каждого запроса
Я принял синюю таблетку и следовал за http://lartc.org/howto/lartc.netfilter.html:
Netfilter & iproute - учебник по маркировке пакетов
Но он ориентирован на перенаправление пакетов OUTGOING на основе маркеров
Я хочу, чтобы пакет, который поступает через tun0, не был отброшен, что и происходит сейчас, при запуске scappy или чего-то подобного для получения пакетов, которые, кажется, ничего не получают.
Наблюдая за Wireshark, я вижу начальные пакеты SYN, поступающие на интерфейс tun0, но это все, что происходит без статического маршрута, как показано выше.
Я чокнутый?
1 ответ
Очевидно, у вас есть какая-то конфигурация пересылки через VPN и вы хотите предотвратить разделение маршрутов маршрутизации для трафика, достигающего вашего хоста через VPN. В этом случае ваш пакет запроса, вероятно, не отброшен (по крайней мере, не вашим хостом), ответ просто перенаправляется через другой интерфейс (предположительно тот, на который указывает маршрут по умолчанию).
В этом сценарии вам определенно не нужно динамическое создание / разборка маршрутов. Вы выбрали правильный путь, используя netfilter для маркировки пакетов. Основное отличие от примеров, приведенных в руководстве по LARTC, заключается в том, что вам нужно будет использовать CONNMARK вместо цели MARK - она будет отмечать входящие и исходящие пакеты, принадлежащие соединению, с определенной меткой. Что-то вроде iptables -t mangle -A INPUT -i tun0 -j CONNMARK --set-mark 555
После этого вы можете использовать ip rule add fwmark 555 lookup <your_secondary_routing_table>
чтобы ответы были перенаправлены так же, как поступили исходные запросы. Ваши настройки немного похожи на настройки маршрутизации для более чем одного провайдера, поэтому чтение некоторых примеров конфигурации должно поставить вас на правильный путь, если вы еще этого не сделали.
Кстати: вы могли бы добиться подобного эффекта намного легче, если бы ваша удаленная конечная точка VPN на 10.8.0.1 просто маскировала запросы TCP/UDP-соединения на свой собственный IP-адрес (iptables -t nat -A POSTROUTING -o tun0 -d <your_servers_address> -j MASQUERADE
). Таким образом, вам понадобится только один статический маршрут - тот, к удаленной конечной точке VPN, который вы автоматически настроите с помощью OpenVPN.