Pesastatud VPN: milline tunnel kannab välist ühendust?

Kaks korraga töötavat VPN-klienti ei tekita pesastatud tunnelit; need tekitavad kaks tunnelit ja vaidluse marsruutimise üle. Pesastatud tunnel on olemas siis, kui sisemise kliendi ühendust omaenda serveriga kannab ise välimine tunnel, ja see on lahendus, mida ehitatakse meelega. Kui see õnnestub, näeb sisemine server välimise serveri aadressi; kui ei õnnestu, ühendub üks klient vaikselt ümber teisest. Kolm tingimust otsustavad, kas pesastamine on tegelik või juhuslik.

Kolm tingimust otsustavad pesastamise

Esimene on see, milline lõpp-punkt vajab millist teed. Nimeta sisemise serveri aadress, nimeta välimise serveri aadress ja ütle selgelt, et sisemine server on kättesaadav ainult välimise tunneli kaudu. Kõik muu tuleneb sellest lausest, sealhulgas see, millised marsruudid kuuluvad millisesse tabelisse.

Teine on see, kas näed teed igal kihil. Kui ei saa tuumalt küsida, millist marsruuti konkreetne sihtkoht kasutaks, tuletad ahela lõplikust väljund-IP-st, ja see on täpselt see tõestus, mis ei suuda pesastamist juhuslikkusest eristada.

Kolmas on see, mis juhtub, kui välimine tunnel kukub. Sisemine tunnel võib sellega peatuda, tavalise võrgu kaudu uuesti ühenduda või jääda blokeerituks, kuni välimine tee naaseb, ja kõik kolm on kaitstavad poliitikad. Need ei ole sama poliitika ja enamiku klientide vaikekäitumine on teine. Klient, mis ühendab oma lõpp-punkti füüsilise võrgu kaudu uuesti, näidates samal ajal tervet ühendust, on kõige tavalisem viis, kuidas kavatsetud ahel vaikselt kaheks mitteseotud tunneliks muutub.

Tingimus üks: milline lõpp-punkt vajab millist teed

ip route get 203.0.113.10 vastab sellele küsimusele otse: see prindib marsruudi, lähteaadressi ja liidese, mida tuum praegu selle sihtkoha jaoks kasutaks.

Käivita see sisemise serveri jaoks enne sisemise kliendi käivitumist ja veel kord pärast, ning võrdle. Kui vastus muutub füüsiliselt liideselt välimise tunneli liideseks, on pesastamine sel hetkel tegelik. Kui see ei muutu, ühendub sisemine klient otse, mida iganes paneel ütleb. Korda välimise serveri aadressi puhul, mis tuleb endiselt lahendada füüsilise liidese kaudu, sest marsruut, mis haarab mõlemad lõpp-punktid rekursiivselt, on tõrge, mis võtab masina täielikult võrgust välja.

Tingimus kaks: uuri teed igal kihil

Marsruudi valik on kaasaegses kliendis rohkem kui põhitabel. Poliitikareeglid võivad saata märgistatud paketid teise tabelisse, klient saab oma sokli liidesega siduda ning konteineril või nimeruumil on oma tabelid. ip rule ja ip route show table all on viis teada saada, milline neist mehhanismidest mängus on.

Klient, mis seab oma soklile SO_MARK või on konfigureeritud siduma end konkreetse seadmega, möödub vaikimisi marsruudist, mille sa arvasid olevat korda teinud. See on funktsioon, mitte viga, ja see tähendab, et ainus usaldusväärne kontroll on see, mis töötab samas nimeruumis kui klient. Kui kliendid töötavad konteinerites, käivita kontrollid nendes konteinerites, mitte hostil.

Tingimus kolm: mis juhtub, kui välimine tunnel kukub

Rikke käitumine nõuab otsust, mitte vaikeväärtust. Kirjuta üles, mis peab sisemise tunneliga juhtuma, kui välimine kaob, ja pane kliendid siis nii tegema.

Valikud on konkreetsed. Sisemise kliendi peatamine, kui välimine tee kaob, annab puhta ahela ja ilmse katkestuse. Sellel otse ühenduda laskmine annab kättesaadavuse ja eemaldab vaikselt omaduse, mille jaoks ahel ehitati. Blokeerimine kuni välimise tee naasmiseni on kõige rangem ja käitamisel tüütum, sest iga välimise tunneli kõikumine muutub nähtavaks juhtumiks.

Testi kõiki kolme kahjutu liiklusega ja tahtliku välimise tunneli rikkega, sest konfiguratsiooni lugemine ei ütle sulle, milline sul on. Tapa välimine tunnel, jälgi, mida sisemine klient teeb, ja kontrolli marsruuti uuesti, kuni see on maas. Seejärel too välimine tunnel tagasi ja kinnita, et ahel moodustub uuesti, mitte ei jäta sisemist klienti otse teele, mille see vahepeal valis.

Mida ahel sulle ei anna

Lisakihid lisavad lõpp-punkte, võtmeid ja rikkerežiime; need ei lisa mingit anonüümsuse garantiid ega tee välist operaatorit võimetuks nägema, et tunnel on olemas. Iga väide selle kohta, mille eest pesastamine kaitseb, peab nimetama vaatleja, kelle eest see kaitseb.

Tulemus on lühike dokument, mitte töötav ühendus: milline lõpp-punkt kasutab millist teed, mis juhtub välimise rikke korral ja kolm käsku, mis näitavad praegust olekut. strongSwani dokumentatsioon edasisaatmise kohta on kasulik allikas selle kohta, kuidas tunneli liiklust Linuxi hostis liideste vahel edasi saadetakse. Käivita kontrollid uuesti pärast iga kliendi uuendust, sest vaikeväärtused, mis sinu ahela lõid, ei ole leping. Pesastatud tunnel, mida sa ei saa kontrollida, on kuulujutt olekutulega.