Избегать обращения с пакетами как с "марсианами": правильно ли это мышление?

У меня есть кабельное соединение с маршрутизатором на основе Linux. Маршрутизатор имеет два физических интерфейса:

enp1s0 (dhcp from cable provider)
enp2s0 (192.168.1.1)

с маскировкой на enp1s0. тогда у меня есть клиентское соединение OpenVPN:

tun0 (10.0.0.4)

Опять же, с маскарадом на этом устройстве. Обычная таблица маршрутизации не имеет записей, указывающих на это устройство, но у меня есть дополнительная таблица маршрутизации:

vpn-clients

так что я могу добавить маршрут по умолчанию, используя это устройство:

ip route add default via 10.0.0.1 dev tun0 table vpn-clients

а затем укажите для каждого клиента, какую таблицу использовать:

ip rule add from 192.168.1.200 lookup vpn-clients
ip rule add from 192.168.1.201 lookup vpn-clients
...

и переадресация портов на tun0:

/sbin/iptables -t nat -A PREROUTING -i tun0 -p udp --dport 5555 -j DNAT --to-destination 192.168.1.200:5555

Похоже, что это работает (по крайней мере для исходящих соединений). Весь трафик от клиентов с маршрутизацией от источника, похоже, направляется через vpn.

Теперь входящие соединения - это совсем другая история. Раньше я регистрировал множество марсиан.

Я понял, что это может быть вызвано комбинацией маршрутизации источника, переадресации портов и маскировки, то есть ядро ​​может не знать, что будет изменен пункт назначения входящего пакета, и вместо этого предположить, что 10.0.0.4 является конечным пунктом назначения, это было бы невозможно, потому что не было установлено никаких маршрутов, которые объясняли бы вещи, поступающие в этот пункт назначения из чего-либо, кроме его собственной подсети.

Итак, я добавил несколько фиктивный маршрут:

ip rule lookup from 10.0.0.4 lookup vpn-clients

так что "таблица маршрутизации" для этого интерфейса становится "vpn-клиенты", который имеет маршрут по умолчанию, указывающий в этом направлении.

Это остановило марсиан, которые были зарегистрированы и сброшены. Входящие соединения работают нормально сейчас. Это "правильный" путь, хотя? Можно ли было сделать это лучше?

0 ответов

Другие вопросы по тегам