VPN гасця і VPN хасцяра: які маршрут сапраўды перамагае

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

Спачатку запішыце далучэнне гасця

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

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

Прасачыце канчатковы пункт гасця вонкава

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

Шырокі маршрут у любым з двух кантэкстаў захоплівае трафік, якога чакаў іншы кліент. Маршрут 0.0.0.0/0 унутры гасця і кліент хасцяра з поўным тунелем абодва прэтэндуюць на ўсё, і перамагае той, што ўжыты апошнім. Перасячэнні паміж віртуальнымі сеткамі гасця, лакальнай LAN і аддаленымі сеткамі даюць той жа эфект для прыватных прэфіксаў, а збоі нагадваюць праблемы аўтэнтыфікацыі; паводзіны пераўтварэння адрасоў тыя ж, што апісаны для кантэйнерных сетак.

Параўнайце запіс да і пасля

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

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

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

Трымайце ўладанне ясным паміж перазапускамі

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

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