Един NIC или два? Как да изберем схема на интерфейсите на VPN сървър

Един физически адаптер е достатъчен за много VPN сървъри и също не е универсално решение. Криптираната връзка пристига на този адаптер, процесът на VPN я декриптира и вътрешният трафик излиза през виртуален интерфейс, преди да достигне локална услуга или маршрутизирана LAN. Дали това работи зависи от три условия: къде се намира дестинацията, дали LAN има обратен път към пула от клиенти и дали една споделена физическа връзка ви дава изолацията, която твърдите. Отговорете на тези три и броят на адаптерите следва сам.

Трите условия, които решават въпроса

Първото условие е дестинацията. До услуга на самия VPN хост се стига само през тунелния интерфейс, докато хост в LAN изисква препращане и обратен път. Второто условие е този обратен път, защото устройството в LAN трябва да знае как да достигне пула от клиенти — чрез маршрут или чрез транслация на сървъра.

Третото условие е разделянето. Един адаптер означава, че всеки пакет, криптиран или не, споделя една връзка и обикновено една верига от политики, така че твърдение за изолация, което зависи от отделен хардуер, не се изпълнява от един интерфейс. Това е факт за пътя, а не за това как е конфигурирана операционната система. Все още можете да филтрирате трафика на тунела, но не можете да твърдите граница, която нямате.

Нито едно от трите не е за броя портове на шасито. Те са за маршрутизацията, собствеността върху адресите и доколко схемата зависи от физическо разделяне.

Два адаптера остават законен избор, когато физически зони, отделни uplink връзки, пропускателна способност или извънлентов път за възстановяване ги оправдават. Това са конкретни изисквания и си струва да бъдат заявени, преди някой да поръча хардуер.

Когато услугата работи на самия 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 не създава втора зона

Добавянето на втори адрес към същия адаптер или създаването на фиктивен интерфейс, който да имитира втори порт, променя много малко. Пакетите все още излизат през същата физическа връзка, същия порт на комутатора и обикновено същата верига на защитната стена, така че между тях няма нова граница. Това е удобство при конфигурацията, не сегментиране. Да се отнасяме към него като към граница на зона е начинът твърдението за изолация да оцелее само на хартия.

Отделната зона изисква истинско разделяне в пътя и това е изискването, което вторият адаптер изпълнява. Ако правило зависи от това трафикът към VPN никога да не дели широкомовен домейн с трафика към LAN, един кабел не може да даде това свойство, както и да е адресиран хостът.

Когато продукт документира многоинтерфейсна топология за конкретен режим, следвайте документацията на този продукт, вместо да измисляте заобиколно решение. Доставчиците също променят поддържаните топологии между версиите и това е още една причина да четете актуалното ръководство, а не стар екран от съветник.

Проверете схемата спрямо трафика, който разрешавате

Избройте класовете трафик, които сървърът трябва да носи: клиент към хост, клиент към LAN, хост към LAN и криптираната външна връзка. Всеки клас има източник, дестинация и интерфейс и схемата трябва да удовлетвори и четирите наведнъж. Схема, която се справя с три от тях, обикновено е тази, която генерира тикети.

След това потвърдете действителните интерфейси и действителния захват, а не диаграмата в проектния документ. Командите по-долу показват и двете гледни точки.

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

Ако външният захват показва криптирания трафик, а вътрешният захват показва декриптирания трафик на тунелния интерфейс, докато физическият адаптер носи и двете, един NIC върши работата. Ако вътрешният захват е празен, проблемът е в тунела или в правилата за препращане, не в броя адаптери. Решете топологията от тези два захвата и таблицата за маршрутизация и следващата промяна ще има спрямо какво да се мери.