Рутирани или мостовани VPN: бирајте према томе до чега клијент мора да дође

Истог дана стижу две пријаве: једном кориснику треба интерна веб апликација, а једном инжењеру треба да се стони инструмент понаша као да стоји на истом Ethernet сегменту. На обе се одговара ставите их на VPN, и ту невоља почиње. Рутирани тунел и мостовани тунел успостављају различите односе, а само један од њих одговара сваком захтеву. Избор топологије је одлука о приступу, а не криптографско подешавање.

Два захтева која на шалтеру изгледају исто

Захтев запосленог је услуга, доступна преко IP-а, са уређаја који не контролишете. Захтев инжењера је на нивоу везе: инструмент очекује да види Ethernet оквире и откривање емитовањем, а можда и DHCP из сегмента у ком мисли да се налази.

То су различита питања, а одговор на оба мостом без разлога проширује приступ запосленог на цео канцеларијски LAN.

Запишите захтев као реченицу пре избора: која одредишта, који протоколи и који партнери треба да изгледају локално. Ако је одговор хост и порт, рутирање то покрива. Ако је одговор однос на нивоу оквира са уређајима који говоре само емитовањем, мост може бити једина опција. Све између заслужује тест сегмент уместо продукционог LAN-а.

Рута је ужа од чланства у LAN-у

Рутирани клијент добија адресу на подмрежи тунела и руте за префиксе које одаберете. Може да дође до сервера апликације и ничега другог, ако то политика каже. Гејтвеј постаје тачка спровођења, под условом да сваки релевантни пут пролази кроз њега.

Не мешајте руту са дозволом. Рећи клијенту како да дође до подмреже не спречава га да покуша друго одредиште.

Примените контролу приступа тамо где заиста може да спроведе ток, а задржите сопствене дозволе апликације. Широко правило прослеђивања или заборављен други интерфејс могу дати више него што дијаграм сугерише. Читајте важећа правила, а не замишљена. Затим тестирајте одредиште које треба да не успе, јер политика коју нико није покушао да прекрши је хипотеза.

Мост мења питање пријема

Мостовање спаја физички интерфејс и TAP уређај у софтверски прекидач, па се удаљени уређаји придружују истој емисионој домени. То је стварна способност и стварни ризик: удаљени уређај више није рутирани гост, он је учесник.

Одлучите који уређаји смеју да се придруже, који типови оквира морају да прођу и где се блокира нежељена интеракција. Адресирање и овлашћење за DHCP постају део заједничке мреже, а два DHCP сервера на једном сегменту производе управо онај неред који очекујете.

За инструмент је наменски тест сегмент обично бољи избор од канцеларијског LAN-а. Држите приступ управљању изван експеримента и дефинишите како се привремени учесник уклања када посао заврши.

Филтрирање постоји у обе топологије

Мост није сам по себи нефилтриран, а рута није сама по себи безбедна. Филтрирање мостова у Linux-у има своје куке и своју синтаксу правила, а правило написано за рутирано IP прослеђивање не примењује се аутоматски на мостоване оквире.

Проверите шта платформа заиста подржава пре него што обећате границу:

bridge link show
nft list ruleset

TUN и TAP описују саобраћај интерфејса, а не шифру. Промена интерфејса не поправља ништа од тога: аутентификација партнера, украдени кључ и застарела криптографска политика сви преживљавају промену. Обе стране и даље требају подешавања која се поклапају и која су и даље подржана.

Докажите границу са три покушаја

Пријем су три запажања, а не преглед дијаграма. Потребна операција мора да ради, неповезано одредиште мора да не успе, а сопствене услуге управљања гејтвеја морају да остану ван домашаја.

Покрените дозвољену и одбијену путању са истог клијента и забележите обе:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

За мост додајте провере на нивоу везе: да ли дозвољени саобраћај откривања пролази, да ли адресирање долази од предвиђеног овлашћења и да ли је привремени учесник нестао након уклањања. Када обичан рутирани IP већ задовољава захтев, придруживање канцеларијском Ethernet сегменту тражи засебно оправдање и оно треба да буде записано пре промене.