Один сетевой адаптер или два? Как определить схему интерфейсов VPN-сервера

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

Три условия, которые это решают

Первое условие — назначение. Служба на самом VPN-хосте доступна только через туннельный интерфейс, тогда как хост в LAN требует пересылки и обратного пути. Второе условие — этот обратный путь, потому что устройство LAN должно знать, как добраться до пула клиентов, будь то маршрутом или трансляцией на сервере.

Третье условие — разделение. Один адаптер означает, что каждый пакет, зашифрованный или нет, делит одно звено и обычно одну цепочку политик, поэтому заявление об изоляции, опирающееся на отдельное оборудование, одним интерфейсом не выполняется. Это факт о пути, а не о том, как настроена операционная система. Вы всё ещё можете фильтровать трафик туннеля, но не можете заявлять о границе, которой у вас нет.

Ни одно из трёх не про число портов на корпусе. Они про маршрутизацию, владение адресами и то, насколько проект зависит от физического разделения.

Два адаптера остаются законным выбором, когда физические зоны, отдельные аплинки, пропускная способность или путь восстановления вне полосы это оправдывают. Это конкретные требования, и их стоит сформулировать до того, как кто-то закажет оборудование.

Когда служба работает на VPN-хосте

Самый простой случай не требует пересылки вовсе. Демон принимает пакеты клиента на туннельном интерфейсе и передаёт их локальному сокету, а ответ возвращается тем же интерфейсом. Для хоста адрес пула клиентов — настоящий локальный адрес.

Две вещи всё же должны быть верны: служба должна слушать на адресе, достижимом из туннеля, а межсетевой экран хоста должен принимать трафик, приходящий на туннельный интерфейс. И то и другое видно в командах ниже.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Привязка службы только к публичному адресу или ошибочная фильтрация туннельного интерфейса дают соединение, которое доходит до хоста и затем умирает. Это похоже на сбой VPN, а обычно это решение по сокету или межсетевому экрану.

Когда назначение находится в LAN

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

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

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Асимметричный путь — классический симптом: запрос клиента приходит, ответ уходит через другой маршрутизатор, и соединение истекает по тайм-ауту без ошибки на обоих концах. Снимите трафик с обеих сторон, прежде чем делать вывод о туннеле.

Почему alias не создаёт вторую зону

Добавление второго адреса на тот же адаптер или создание dummy-интерфейса, имитирующего второй порт, меняет очень мало. Пакеты по-прежнему выходят через то же физическое звено, тот же порт коммутатора и обычно ту же цепочку межсетевого экрана, поэтому новой границы между ними не возникает. Это удобство конфигурации, а не сегментация. Отношение к этому как к границе зоны — это способ, которым заявление об изоляции выживает только на бумаге.

Отдельная зона требует реального разделения на пути, и это требование выполняет второй адаптер. Если правило зависит от того, что трафик в сторону VPN никогда не делит широковещательный домен с трафиком в сторону LAN, один кабель не даст этого свойства, как бы ни был адресован хост.

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

Проверьте схему на соответствие трафику, который вы разрешаете

Перечислите классы трафика, которые сервер должен нести: клиент к хосту, клиент к LAN, хост к LAN и зашифрованное внешнее соединение. У каждого класса есть источник, назначение и интерфейс, и схема должна удовлетворять всем четырём сразу. Схема, которая решает три из них, обычно и порождает заявки.

Затем подтвердите фактические интерфейсы и фактический перехват, а не диаграмму в проектной документации. Команды ниже печатают оба представления.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

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