Külalis-VPN ja host-VPN: milline marsruut tegelikult võidab

Kaks klienti töötavad korraga, kumbki veendunud, et tema omab vaikimisi marsruuti, ja sümptom ilmub millegi veidrana: üks külalise rakendus töötab, teine lahendatakse valesse kohta. VPN külalise sees ja VPN hostis võivad kõrvuti eksisteerida, kuid ainult siis, kui väline tee ja sisemine poliitika on ühel meelel, kes mida kannab. Mõlema käivitamine ei loo iseenesest ahelat. Kirjuta esmalt ühendusviis üles ja muuda siis korraga ühte asja.

Kirjuta esmalt üles külalise ühendusviis

Külaline jõuab oma VPN-serverini mööda seda teed, mille hüperviisor talle andis: NAT hosti taga, sild füüsilisele segmendile või ainult hosti võrk, mille peale on marsruutimine lisatud. Iga ühendusviis muudab seda, mida külaline näeb ja mida host saab tema liiklusega teha. NAT-i all näivad külalise paketid tulevat hostist, nii et hosti enda tunnel võib neid kanda, ilma et külaline sellest midagi teaks. Silla all on külalisel segmendil oma kohalolek ja oma vaikimisi lüüs.

Kirjuta ühendusviis üles enne, kui puudutad ükskõik millist seadistust, koos sellega, milline klient peaks kandma millist rakendust. See lause lahendab enamiku sellistest juhtumitest, sest kaks klienti on tavaliselt üles ehitatud erinevatele eeldustele. Külaline, kellelt oodatakse hosti tunneli kasutamist, ei tohi omada ka oma konkureerivat vaikimisi marsruuti.

Jälgi külalise lõpp-punkti väljapoole

Külalis-VPN vajab oma serverini kasutatavat teed enne, kui miski muu saab töötada. Kui hosti tunnel on üleval ja külaline istub NAT-i taga, väljub külalise kätlus hosti tunneli kaudu, mis on kas projekteeritud nii või õnnetus, mida keegi ei dokumenteerinud. Kui hosti tunnel kukub ja külaline sõltus sellest, kaotab külaline ühenduvuse ilma ühegi muudatuseta oma poolel. Lõpp-punkti jälgimine väljapoole ütleb sulle, kumb neist kahest sul tegelikult on.

Lai marsruut kummaski kontekstis püüab liiklust, mida teine klient ootas. 0.0.0.0/0 marsruut külalise sees ja täistunneliga host-klient nõuavad mõlemad kõike ning võidab see, mis kehtib viimasena. Külalise virtuaalvõrkude, kohaliku LAN-i ja kaugvõrkude kattumised tekitavad privaatsete prefiksite puhul sama efekti, tõrgetega, mis meenutavad autentimisprobleeme; aadressitõlke käitumine on sama, mida kirjeldatakse konteinerite võrgunduse jaoks.

Võrdle enne ja pärast tehtud üleskirjutust

Võta baasjoon hosti tunnel väljas või sellises kontrollitud olekus, mille sinu poliitika lubab, ja kirjuta üles külalise marsruut ja resolver. Seejärel rakenda kombineeritud seadistus ja võrdle kahte üleskirjutust, hoides privaatsusnõuded puutumatuna. Kui otsene baasjoon ei sobi, kirjuta see piirang üleskirjutusse, selle asemel et võrdlus vahele jätta.

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

Marsruudipäring nimetab liidese ja lähteaadressi, mis kannaksid konkreetset sihtkohta, ja see on selle uurimise kõige kasulikum üksik rida. Reeglite loend näitab, kas poliitikapõhine marsruutimine saadab mõned sihtkohad läbi teise tabeli. Resolveri väljund näitab, kas DNS järgis külalise tunnelit või jäi hosti teele. Käivita samad kolm käsku enne ja pärast muudatust ning delta nimetab süüdlase.

Hoia omandiõigus selge üle taaskäivituste

Host-klienti lokaalse juurdepääsu piirang võib blokeerida liiklust virtuaalse NAT-i või sillani ja seda piirangut aetakse regulaarselt segi külalise mandaadi probleemiga. Loe kliendi dokumenteeritud käitumist, selle asemel et piirang välja lülitada, et test läbi läheks. Pärast toetatud parandust testi uuesti külalise rakendust ja nõutavat tõrkepoliitikat. Host, mis ühendub edukalt uuesti, ei tõesta midagi külalise marsruudi ega resolveri kohta.

Otsusta, milline pool omab vaikimisi marsruuti, ja kirjuta see kasutusjuhendisse. Külalise taaskäivitus või hosti võrguvahetus, mis omandiõiguse vaikselt ümber pöörab, tekitab veateate VPN-i kohta, mis ei olnud kunagi süüdi. Lahendus peaks üle elama taaskäivituse, ilma et keegi mäletaks, miks see töötas.