Gnezdeni VPN: kateri tunel nosi zunanjo povezavo?

Dva hkrati delujoča odjemalca VPN ne ustvarita gnezdenega tunela; ustvarita dva tunela in prepir o usmerjanju. Gnezdeni tunel obstaja, ko povezavo notranjega odjemalca z njegovim lastnim strežnikom nosi sam zunanji tunel, in to je ureditev, ki jo zgradiš namenoma. Če se izide, notranji strežnik vidi naslov zunanjega strežnika; če se ne, se en odjemalec tiho znova poveže okoli drugega. O tem, ali je gnezdenje resnično ali naključno, odločajo trije pogoji.

O gnezdenju odločajo trije pogoji

Prvi je, katera končna točka potrebuje katero pot. Poimenuj naslov notranjega strežnika, poimenuj naslov zunanjega strežnika in izrecno navedi, da je notranji strežnik dosegljiv le skozi zunanji tunel. Vse drugo izhaja iz tega stavka, tudi katere poti sodijo v katero tabelo.

Drugi je, ali vidiš pot na vsakem sloju. Če jedra ne moreš vprašati, katero pot bi uporabil določen cilj, sklepaš verigo iz končnega izhodnega IP, in to je prav tisti dokaz, ki ne more ločiti gnezdenja od naključja.

Tretji je, kaj se zgodi, ko zunanji tunel pade. Notranji tunel se lahko ustavi z njim, se znova poveže po običajnem omrežju ali ostane blokiran, dokler se zunanja pot ne vrne, in vsi trije so zagovorljive politike. Niso ista politika, in privzeto vedenje večine odjemalcev je drugo. Odjemalec, ki znova poveže svojo končno točko prek fizičnega omrežja, medtem ko kaže zdravo povezavo, je najpogostejši način, kako nameravana veriga tiho postane dva nepovezana tunela.

Pogoj ena: katera končna točka potrebuje katero pot

ip route get 203.0.113.10 na to vprašanje odgovori neposredno: izpiše pot, izvorni naslov in vmesnik, ki bi ga jedro zdaj uporabilo za ta cilj.

Zaženi ga za notranji strežnik, preden se notranji odjemalec zažene, in še enkrat po tem, nato primerjaj. Če se odgovor spremeni s fizičnega vmesnika na vmesnik zunanjega tunela, je gnezdenje v tistem trenutku resnično. Če se ne spremeni, se notranji odjemalec povezuje neposredno, kar koli pravi plošča. Ponovi za naslov zunanjega strežnika, ki se mora še vedno razreševati prek fizičnega vmesnika, ker je pot, ki rekurzivno zajame obe končni točki, okvara, ki stroj povsem odklopi od omrežja.

Pogoj dva: preglej pot na vsakem sloju

Izbira poti je na sodobnem odjemalcu več kot glavna tabela. Pravila politike lahko pošljejo označene pakete v drugo tabelo, odjemalec lahko svoj socket veže na vmesnik, vsebnik ali imenski prostor pa ima svoje tabele. ip rule in ip route show table all sta način, da ugotoviš, kateri od teh mehanizmov je v igri.

Odjemalec, ki na svoj socket nastavi SO_MARK ali je nastavljen tako, da se veže na določeno napravo, obide privzeto pot, za katero si mislil, da si jo uredil. To je funkcija in ne napaka, in pomeni, da je edino zanesljivo preverjanje tisto, ki teče v istem imenskem prostoru kot odjemalec. Če odjemalci tečejo v vsebnikih, preverjanja zaženi v teh vsebnikih namesto na gostitelju.

Pogoj tri: kaj se zgodi, ko zunanji tunel pade

Vedenje ob okvari zahteva odločitev, ne privzete vrednosti. Zapiši, kaj se mora zgoditi z notranjim tunelom, ko zunanji izgine, in potem poskrbi, da odjemalci to naredijo.

Možnosti so konkretne. Ustavitev notranjega odjemalca, ko zunanja pot izgine, da čisto verigo in očiten izpad. Če mu dovoliš neposredno ponovno povezavo, dobiš razpoložljivost in tiho odstraniš lastnost, za katero je bila veriga zgrajena. Blokiranje do vrnitve zunanje poti je najstrožje in najbolj nadležno za upravljanje, ker vsako nihanje zunanjega tunela postane viden dogodek.

Preizkusi vse tri z neškodljivim prometom in namerno okvaro zunanjega tunela, ker branje konfiguracije ti ne pove, katero imaš. Ubij zunanji tunel, opazuj, kaj počne notranji odjemalec, in znova preveri pot, medtem ko je dol. Nato vrni zunanji tunel in potrdi, da se veriga znova oblikuje, namesto da notranji odjemalec ostane na neposredni poti, ki jo je medtem izbral.

Česa ti veriga ne da

Dodatni sloji dodajo končne točke, ključe in načine okvar; ne dodajo nobenega jamstva anonimnosti in ne preprečijo zunanjemu operaterju, da bi videl, da tunel obstaja. Vsaka trditev o tem, pred čim gnezdenje ščiti, mora imenovati opazovalca, pred katerim ščiti.

Rezultat je kratek dokument in ne delujoča povezava: katera končna točka uporablja katero pot, kaj se zgodi ob zunanji okvari in trije ukazi, ki kažejo trenutno stanje. Dokumentacija strongSwan o posredovanju je koristen vir za to, kako se tunelski promet posreduje med vmesniki na gostitelju Linux. Preverjanja znova zaženi po vsaki nadgradnji odjemalca, ker privzete vrednosti, ki so ustvarile tvojo verigo, niso pogodba. Gnezdeni tunel, ki ga ne moreš pregledati, je govorica z lučko stanja.