Адзін NIC ці два? Як выбраць схему інтэрфейсаў 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 не стварае другую зону

Даданне другога адраса на той жа адаптар або стварэнне фіктыўнага інтэрфейса, каб імітаваць другі порт, змяняе вельмі мала. Пакеты ўсё яшчэ выходзяць праз той жа фізічны канал, той жа порт камутатара і звычайна той жа ланцужок міжсеткавага экрана, таму новай мяжы паміж імі няма. Гэта зручнасць наладкі, а не сегментацыя. Стаўленне да гэтага як да мяжы зоны — гэта тое, як заява пра ізаляцыю застаецца толькі на паперы.

Асобная зона патрабуе сапраўднага раздзялення ў шляху, і менавіта гэта задавальняе другі адаптар. Калі правіла залежыць ад таго, што трафік, які глядзіць на VPN, ніколі не дзеліць шырокавяшчальны дамен з трафікам, які глядзіць на LAN, адзін кабель не дасць гэтай уласцівасці, як бы ні адрасаваўся хост.

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

Праверце схему супраць трафіку, які вы дазваляеце

Пералічыце класы трафіку, якія сервер павінен несці: кліент да хоста, кліент да LAN, хост да LAN і шыфраванае знешняе злучэнне. Кожны клас мае крыніцу, пункт прызначэння і інтэрфейс, і схема павінна задаволіць усе чатыры адначасова. Схема, якая спраўляецца з трыма, звычайна і спараджае заяўкі.

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

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

Калі знешні захоп паказвае шыфраваны трафік, а ўнутраны захоп паказвае расшыфраваны трафік на тунельным інтэрфейсе, тады як фізічны адаптар нясе абодва, адзін NIC спраўляецца. Калі ўнутраны захоп пусты, праблема ў тунелі або правілах перасылкі, а не ў колькасці адаптараў. Вырашыце тапалогію па гэтых двух захопах і табліцы маршрутызацыі, і наступная змена будзе мець з чым параўнацца.