Două salturi VPN pe un singur Pi: ce rută poartă ce partener

Două adrese de tunel pe o plăcuță mică par o greșeală, iar reflexul este să ștergi una. Acel reflex strică ceea ce trebuia să ordoneze. Un host care poartă două salturi ține o adresă pentru fiecare conexiune, iar fiecare adresă este selectată de o rută diferită. Întrebarea care merită pusă este ce rută alege ce transportator pentru ce destinație, nu câte adrese există.

Trei destinații care au nevoie de transportatori diferiți

Un lanț de două salturi este trei clase de destinație suprapuse, iar fiecare este purtată de o conexiune diferită. Partenerul exterior trebuie atins prin legătura fizică. Partenerul interior trebuie atins prin tunelul exterior. Destinația aplicației acoperite trebuie atinsă prin tunelul interior, al cărui transport propriu este purtat de cel exterior.

Completați rândurile cu adresele reale ale cititorului înainte de a atinge o rută, pentru că tabelul este util doar când este concret. Un lanț funcțional satisface toate cele patru rânduri simultan, iar un lanț pe jumătate funcțional satisface de obicei unul dintre ele cu transportatorul greșit. Tocmai citirea rândului greșit ca defecțiune transformă o problemă de rutare într-o după-amiază întreagă de modificări.

Adresele au roluri, nu un număr

Linux permite mai multe adrese pe o interfață și mai multe tuneluri pe un host, așa că un număr nu spune nimic despre corectitudine. Contează ce adresă aparține cărei conexiuni și dacă ruta pentru un anumit partener selectează conexiunea la care vă gândeați. Trei vederi răspund la asta din trei direcții, și merită citite în aceeași ordine de fiecare dată.

Inventarul adreselor arată ce există și ce conexiune îl deține. Tabelul de rute răspunde la întrebarea transportatorului pentru traficul obișnuit către destinații. Vederea politicilor răspunde din nou pentru traficul selectat după sursă sau marcă, care este aranjamentul normal când doi clienți împart un host.

ip -4 addr show
ip -4 route show table all
ip rule show

Ștergerea unei adrese pentru că lista pare lungă poate elimina o parte din cale, iar ștergerea unei rute pentru că pare redundantă face același lucru mai silențios. Niciuna nu produce o eroare; partenerul pur și simplu nu mai răspunde pe calea la care vă gândeați, rămânând accesibil pe alta. O aplicație care raportează adresa de ieșire a partenerului interior nu dovedește că traficul a traversat tunelul exterior, deoarece accesul direct produce aceeași observație. Exact acest decalaj între observație și dovadă este motivul pentru care transportatorul este verificat la nivelul de rutare.

Ordinea de activare învinge o așteptare fixă

Dacă clientul interior depinde de o adresă sau o rută furnizată de clientul exterior, activarea trebuie să aștepte acea resursă în locul unei întârzieri. O așteptare funcționează până în ziua în care tunelul exterior este lent, iar atunci eșuează intermitent într-un mod pe care nimeni nu îl poate reproduce. Ordinea bazată pe dependențe elimină presupunerea și nu costă nimic în afară de descrierea dependenței o dată. Nici numele interfețelor nu sunt un mecanism de ordonare.

Nucleul atribuie nume precum tun0 și tun1 în ordinea creării, iar acea ordine se poate schimba între reporniri sau reconectări. Legați configurația de o identitate oferită de instrument sau de un nume pe care îl atribuiți deliberat. Un nume pe care îl alegeți este un contract; un nume pe care îl alege nucleul este un accident.

Țineți transportul fiecărui client în afara rutei de aplicație a celuilalt și fiți precis despre ce promit de fapt opțiunile de rutare din OpenVPN 2.6. Mecanismul documentat de redirecționare implicită menține un client capabil să își atingă partenerul îndepărtat prin gateway-ul care exista deja, ceea ce taie o buclă de recursie anume. Nu transformă un client în transportatorul altuia, așa că restul lanțului rămâne proiectul dumneavoastră. Unde lanțul are nevoie de o politică în locul unei rute, scrieți o regulă explicită de sursă sau marcă și testați-o cu traficul cu care trebuie să se potrivească.

Ce se întâmplă când moare saltul exterior

Înainte ca lanțul să fie considerat complet, decideți ce se întâmplă când saltul exterior dispare. Transportul clientului interior moare odată cu el, iar următorul pas este o chestiune de politică, nu tehnică: eșec, reîncercare sau reconectare directă prin legătura fizică. Exact al treilea rezultat este cel la care merită să vă gândiți. El transformă în tăcere un proiect cu două salturi într-unul cu un salt în momentul în care utilizatorul crede că acoperirea este încă intactă.

Dacă două salturi sunt obligatorii, clientul interior nu trebuie să poată stabili o cale directă atunci când cel exterior a dispărut, iar modalitatea de a afla este să rupeți saltul exterior și să observați ce face cel interior. Un plan de rezervă aprobat este un răspuns legitim, dar trebuie scris, testat și comunicat. Un plan de rezervă pe care nimeni nu l-a documentat este imposibil de distins de o scurgere în timpul revizuirii unui incident.

DNS-ul și cealaltă familie de adrese fac parte din aceeași decizie. O interogare generată local urmează politica hostului însuși, nu pe cea a unui client transmis, așa că resolverul care funcționează pentru traficul transmis poate să nu fie cel pe care hostul îl folosește.

Acceptați fiecare strat în ordinea în care l-ați construit

Testați în ordinea în care a fost construit lanțul: mai întâi tunelul exterior singur, apoi transportul clientului interior prin tunelul exterior, apoi aplicația prin tunelul interior. Fiecare acceptare trebuie să fie o conexiune nouă, nu o pagină care era deja deschisă. Apoi rupeți și restaurați fiecare strat separat și observați ce face următorul.

Rezultatul planului de rezervă este aici cea mai valoroasă observație și cea pe care o pagină de IP public nu o arată niciodată. Salvați căile partenerilor, adresele pe care le folosesc și acel rezultat lângă configurație, pentru că drumul fericit nu este partea care este pusă sub semnul întrebării mai târziu.