У меня есть Сервер с (66.66.66.66) (конечно, не реальный IP), и у моей домашней сети тоже есть публичный IP (202.202.122.123).

После того, как я подключаюсь к серверу с маршрутизатора (172.22.34.1), используя VPN (технически OpenVPN, это не имеет значения) для прокси,

Затем у меня есть основная таблица маршрутов, например: 202.202.122.1 dev ppp0 proto kernel scope link 172.22.34.0/24 dev br0 proto kernel scope link src 172.22.34.1 10.12.12.0/24 dev tap11 proto kernel scope link src 10.12.12.2 default via 202.202.122.1 dev ppp0 и таблицу маршрутов ov1, например: 172.22.34.0/24 dev br0 scope link 66.66.66.66/32 via 202.202.122.1 dev ppp0 0.0.0.0/1 via 10.12.12.1 dev tap11 128.0.0.0/1 via 10.12.12.1 dev tap11 и правило ip следующим образом (я делаю это для управления тем, кто может использовать VPN-туннель): 0: from all lookup local 32764: from 172.22.34.101 lookup ov1 32765: from 172.22.34.44 lookup ov1 32766: from all lookup main 32767: from all lookup default

Сервер с IP 66.66.66.66 может просматривать веб-сайт HTTPS, размещенный дома (202.202.122.123:443 DNAT до 172.22.34.44:443), но другие нет (Мой телефон, средство проверки онлайн-порта и т.д.).

Затем я отслеживал пакеты с помощью tshark(wireshark CLI) на 172.22.34.44, даже при входе в Интернет с моего телефона (с использованием сотовой сети) нет даже входящего трафика, но после ТОЛЬКО мне нужно вручную добавить IP-адрес телефона в таблицу маршрутов ov1 как сервер (ip route add PHONEIP dev ppp0 table ov1), то работает нормально.

То, что меня смущает, так это то, что, как я знаю, в таблице маршрутов указано "Назначение", а не "Источник": Kernel IP routing table Назначение ....Gateway Genmask Flags Metric Ref Use Iface 202.202.122.1 * 255.255.255.255 UH 0 0 0 ppp0 172.22.34.0 * 255.255.255.0 U 0 0 0 br0 10.12.12.0 * 255.255.255.0 U 0 0 0 tap11 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 202.202.122.1 0.0.0.0 UG 0 0 0 ppp0 который должен влиять только на исходящий трафик, я не ожидал, что входящий трафик исчезнет.

Где не так?

PS.1 Когда del 172.22.34.44 из правила ip, чтобы заставить его использовать основную таблицу маршрутов, он тоже работает нормально.

PS.2.1 ip route add 0.0.0.0/0 dev ppp0 table ov1 имеет никакого эффекта, что
PS.2.2 ip route add PHONEIP dev ppp0 table ov1 оказывает влияние (упоминалось ранее)

PS.3 Какие-либо документы рекомендовать?

|источник

1 ответ1

0

Основной вопрос, кажется, решен с помощью echo 0 > /proc/sys/net/ipv4/conf/ppp0/rp_filter для отключения проверки обратного пути. Таблица маршрутов действительно означает пункт назначения, а не IP-адрес источника.

Для тех, кто интересуется, что случилось, вот краткое объяснение.

Когда IP с 0.0.0.0/0(equals 0.0.0.0/1 + 128.0.0.0/1 в таблице маршрутов ov1) через ppp0(eth0) пытается соединиться 202.202.122.123:443,
маршрутизатор будет DNAT это,
затем используйте основной маршрут, потому что, как показывает команда ip rule (из ALL lookup main),
172.22.34.44 (:443) ответов,
но теперь маршрутизатор теперь будет использовать таблицу ov1 (из 172.22.34.44 lookup ov1),
пытается отправить этот пакет через tap11,
затем, если на маршрутизаторе включена проверка обратного пути,
этот пакет будет отброшен.

Поэтому лучшее решение моей проблемы - добавить виртуальный интерфейс 172.22.34.45 на 172.22.34.44, а затем DNAT на 172.22.34.45.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .