VPN imbricat: ce tunel transportă conexiunea exterioară?

Doi clienți VPN care rulează simultan nu produc un tunel imbricat; produc două tuneluri și o ceartă despre rutare. Un tunel imbricat există atunci când conexiunea clientului interior la propriul server este ea însăși transportată de tunelul exterior, iar acesta este un aranjament pe care îl construiești intenționat. Dacă iese bine, serverul interior vede adresa serverului exterior; dacă iese rău, un client se reconectează în tăcere pe lângă celălalt. Trei condiții decid dacă imbricarea este reală sau accidentală.

Trei condiții decid imbricarea

Prima este ce punct final are nevoie de ce cale. Numește adresa serverului interior, numește adresa serverului exterior și afirmă explicit că serverul interior este accesibil doar prin tunelul exterior. Tot restul decurge din acea frază, inclusiv ce rute stau în ce tabelă.

A doua este dacă poți vedea calea la fiecare nivel. Dacă nu poți întreba nucleul ce rută ar folosi o anumită destinație, deduci lanțul dintr-un IP de ieșire final, iar aceasta este exact dovada care nu poate distinge o imbricare de o coincidență.

A treia este ce se întâmplă când cade tunelul exterior. Tunelul interior se poate opri odată cu el, se poate reconecta prin rețeaua obișnuită sau poate rămâne blocat până când calea exterioară revine, iar toate trei sunt politici justificabile. Nu sunt aceeași politică, iar comportamentul implicit al majorității clienților este al doilea. Un client care își reconectează punctul final prin rețeaua fizică în timp ce arată o conexiune sănătoasă este cel mai obișnuit mod în care un lanț dorit devine în tăcere două tuneluri fără legătură.

Condiția unu: ce punct final are nevoie de ce cale

ip route get 203.0.113.10 răspunde direct la această întrebare: tipărește ruta, adresa sursă și interfața pe care nucleul ar folosi-o pentru acea destinație chiar acum.

Ruleaz-o pentru serverul interior înainte ca clientul interior să pornească și din nou după, apoi compară. Dacă răspunsul se schimbă de la interfața fizică la interfața tunelului exterior, imbricarea este reală în acel moment. Dacă nu se schimbă, clientul interior se conectează direct, orice ar spune panoul de control. Repetă pentru adresa serverului exterior, care tot trebuie rezolvată prin interfața fizică, pentru că o rută care capturează ambele puncte finale recursiv este defecțiunea care scoate complet mașina din rețea.

Condiția doi: inspectează calea la fiecare nivel

Selecția rutei este mai mult decât tabela principală pe un client modern. Regulile de politică pot trimite pachete marcate către altă tabelă, un client își poate lega socketul de o interfață, iar un container sau un namespace are tabele proprii. ip rule și ip route show table all sunt modul de a afla care dintre aceste mecanisme este în joc.

Un client care pune SO_MARK pe propriul socket sau este configurat să se lege de un anumit dispozitiv ocolește ruta implicită pe care credeai că ai aranjat-o. Aceasta este o funcție, nu un defect, și înseamnă că singura verificare fiabilă este cea care rulează în același namespace cu clientul. Dacă clienții rulează în containere, rulează verificările în acele containere în loc de pe gazdă.

Condiția trei: ce se întâmplă când cade tunelul exterior

Comportamentul la defecțiune cere o decizie, nu o valoare implicită. Notează ce trebuie să se întâmple cu tunelul interior când dispare cel exterior, apoi fă clienții să facă asta.

Opțiunile sunt concrete. Oprirea clientului interior când dispare calea exterioară dă un lanț curat și o întrerupere evidentă. Lăsarea lui să se reconecteze direct dă disponibilitate și elimină în tăcere proprietatea pentru care a fost construit lanțul. Blocarea până la revenirea căii exterioare este cea mai strictă și cea mai incomodă de operat, pentru că fiecare oscilație a tunelului exterior devine un incident vizibil.

Testează toate trei cu trafic inofensiv și cu o defecțiune provocată a tunelului exterior, pentru că citirea configurației nu îți spune care variantă o ai. Omoară tunelul exterior, urmărește ce face clientul interior și verifică ruta din nou cât timp este căzut. Apoi adu tunelul exterior înapoi și confirmă că lanțul se reformează în loc să lase clientul interior pe calea directă pe care a ales-o între timp.

Ce nu îți dă lanțul

Straturile suplimentare adaugă puncte finale, chei și moduri de eșec; nu adaugă nicio garanție de anonimat și nu fac operatorul exterior incapabil să vadă că există un tunel. Orice afirmație despre ce protejează imbricarea trebuie să numească observatorul împotriva căruia protejează.

Livrabilul este un document scurt și nu o conexiune funcțională: ce punct final folosește ce cale, ce se întâmplă la o defecțiune exterioară și cele trei comenzi care arată starea actuală. documentația strongSwan despre forwarding este o referință utilă pentru modul în care traficul de tunel este transmis între interfețe pe un host Linux. Rulează din nou verificările după fiecare actualizare de client, pentru că valorile implicite care ți-au produs lanțul nu sunt un contract. Un tunel imbricat pe care nu îl poți inspecta este un zvon cu un bec de stare.