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-у који никада није био крив. Распоред би требало да преживи поновно подизање без тога да се ико сећа зашто је радио.