VPN v gostu in VPN na gostitelju: katera pot resnično zmaga

Dva odjemalca tečeta hkrati, vsak prepričan, da ima privzeto pot, in simptom se pojavi kot nekaj čudnega: ena gostova aplikacija deluje, druga se razreši na napačno mesto. VPN znotraj gosta in VPN na gostitelju lahko obstajata skupaj, a le ko se zunanja pot in notranja politika strinjata, kdo kaj nosi. Zagon obeh sam po sebi ne ustvari verige. Najprej zapišite priklop, nato spreminjajte eno stvar naenkrat.

Najprej zapišite priklop gosta

Gost doseže svoj strežnik VPN po poti, ki mu jo je dal hipervizor: NAT za gostiteljem, most na fizični segment ali omrežje samo za gostitelja z usmerjanjem, dodanim na vrhu. Vsak priklop spremeni, kaj gost vidi in kaj lahko gostitelj naredi z njegovim prometom. Pod NAT so gostovi paketi videti, kot da prihajajo z gostitelja, zato jih lahko njegov lastni tunel nosi, ne da bi gost o tem karkoli vedel. Pod mostom ima gost svojo prisotnost v segmentu in svojo privzeto prehodno točko.

Zapišite priklop, preden se dotaknete kakršne koli konfiguracije, skupaj s tem, kateri odjemalec naj nosi katero aplikacijo. Ta stavek reši večino takšnih primerov, ker sta odjemalca običajno zgrajena na različnih predpostavkah. Gost, od katerega se pričakuje uporaba gostiteljevega tunela, ne sme imeti tudi svoje konkurenčne privzete poti.

Sledite končni točki gosta navzven

VPN gosta potrebuje uporabno pot do svojega strežnika, preden lahko deluje karkoli drugega. Ko je gostiteljev tunel vzpostavljen in gost sedi za NAT, rokovanje gosta odide skozi gostiteljev tunel, kar je bodisi načrt bodisi nesreča, ki je nihče ni dokumentiral. Ko gostiteljev tunel pade in je bil gost od njega odvisen, gost izgubi povezljivost brez ene same spremembe na svoji strani. Sledenje končni točki navzven vam pove, kateri od teh dveh primerov v resnici imate.

Široka pot v katerem koli kontekstu ujame promet, ki ga je pričakoval drugi odjemalec. Pot 0.0.0.0/0 znotraj gosta in gostiteljski odjemalec s polnim tunelom oba zahtevata vse, in zmaga tisti, ki se uporabi zadnji. Prekrivanja med gostovimi navideznimi omrežji, lokalnim LAN in oddaljenimi omrežji imajo enak učinek za zasebne predpone, z okvarami, ki spominjajo na težave s preverjanjem pristnosti; vedenje prevajanja naslovov je enako tistemu, opisanemu za omrežja vsebnikov.

Primerjajte zapis pred in po

Vzemite izhodišče z izklopljenim gostiteljevim tunelom ali v katerem koli nadzorovanem stanju, ki ga vaša politika dovoljuje, in zapišite pot in razreševalnik gosta. Nato uporabite kombinirano konfiguracijo in primerjajte zapisa, pri čemer ohranite zahteve zasebnosti nedotaknjene. Če neposredno izhodišče ni primerno, zapišite to omejitev v zapis, namesto da primerjavo izpustite.

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

Poizvedba poti poimenuje vmesnik in izvorni naslov, ki bi nosila določen cilj, in to je najbolj uporabna vrstica v tej preiskavi. Seznam pravil pokaže, ali usmerjanje po politiki pošilja nekatere cilje skozi drugo tabelo. Izhod razreševalnika pokaže, ali je DNS sledil gostovemu tunelu ali ostal na gostiteljevi poti. Zaženite iste tri ukaze pred spremembo in po njej, in razlika bo imenovala krivca.

Ohranite lastništvo jasno med ponovnimi zagoni

Omejitev lokalnega dostopa gostiteljskega odjemalca lahko blokira promet do navideznega NAT ali mostu, in to omejitev redno zamenjujejo za težavo s poverilnicami gosta. Preberite dokumentirano vedenje odjemalca, namesto da omejitev izklopite, da bi test uspel. Po podprtem popravku znova preizkusite gostovo aplikacijo in politiko okvare, ki jo zahtevate. Gostitelj, ki se uspešno znova poveže, ne dokazuje ničesar o gostovi poti ali razreševalniku.

Odločite, katera stran ima privzeto pot, in to zapišite v priročnik za obratovanje. Ponovni zagon gosta ali menjava omrežja na gostitelju, ki tiho obrne lastništvo, ustvari poročilo o napaki o VPN, ki ni bil nikoli kriv. Ureditev bi morala preživeti ponovni zagon, ne da bi se kdo spomnil, zakaj je delovala.