Tunel complet sau rută de punct final: menținerea serverului VPN accesibil

Adăugați o rută implicită prin tunel, iar pachetele tunelului însuși o vor urma. Tabelul conține atunci o regulă care se înfrânge pe sine. Conexiunea criptată către server încearcă să călătorească în interiorul conexiunii pe care încearcă să o stabilească.

Două mecanisme împiedică această buclă. Unul este vizibil în tabela de rutare, celălalt trăiește în interiorul aplicației.

Traficul intern și cel extern sunt decizii diferite

Un pachet al aplicației intră în interfața virtuală și este încapsulat. Rezultatul este un pachet nou adresat adresei publice a serverului. Acel pachet are nevoie de o rută în rețeaua fizică, fiindcă nimic din el nu poate intra în tunel.

Ambele sunt decizii de rutare, iar doar prima aparține tunelului. Când clientul instalează o rută implicită care acoperă și serverul, pachetul exterior este și el capturat.

Simptomele sunt imediate și totale. Strângerea de mână se încheie și apoi nimic nu curge, sau conexiunea cade în clipa în care se instalează ruta. În ambele cazuri keepalive nu mai poate ieși.

Opțiunea unu: o rută de gazdă pentru punctul final

Abordarea directă adaugă o rută pentru adresa serverului prin poarta de acces originală. Este nevoie de o singură linie. Este vizibilă pentru oricine citește tabela. Este și ușor de explicat într-o înregistrare de modificări.

Slăbiciunea ei apare când calea de bază se schimbă. Ruta salvată numește o poartă de acces și o interfață din rețeaua veche. După o schimbare de Wi-Fi acea poartă poate să nu existe, iar ruta rămâne în urmă, pare corectă și nu face nimic.

# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7

# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0

# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7

Un nume de gazdă face acest lucru mai dificil. Dacă punctul final este un nume care se rezolvă în mai multe adrese, excepția trebuie să acopere adresa folosită efectiv. O interogare ulterioară poate returna ceva ce ruta nu a acoperit niciodată.

Opțiunea doi: protejarea socketului

Cealaltă abordare nu atinge niciodată tabela de rutare. Clientul marchează sau protejează socketul care transportă tunelul, astfel încât sistemul de operare trimite traficul acelui socket în afara tunelului conform politicii. Android expune mecanismul direct aplicațiilor VPN. Clienții pentru desktop implementează echivalente cu mărci de firewall sau apeluri de legare la dispozitiv.

Avantajul este că excepția urmează conexiunea, nu o poartă salvată. O schimbare de rețea rescrie calea de bază, iar socketul protejat se mută odată cu ea pentru că nu a fost niciodată fixat de o adresă. Tabela de rutare rămâne curată.

Costul este vizibilitatea. Nimic din tabela de rutare nu arată excepția, așa că un recenzent care caută o rută de gazdă nu găsește nimic și poate concluziona că proiectul este nesigur. Protecția trăiește în codul clientului și în regulile de politică pe care acel cod le instalează.

Alegerea între cele două

Alegeți mecanismul la nivel de socket când clientul îl acceptă, pentru că supraviețuiește schimbărilor de rețea care rup o rută fixată. Alegeți ruta de gazdă când excepția trebuie să fie vizibilă pentru alte instrumente sau când clientul nu oferă nimic mai bun.

Niciunul dintre mecanisme nu elimină nevoia ca adresa serverului să fie accesibilă măcar. O poartă privată are o adresă publică de ascultare, iar aceea este adresa care trebuie să rămână în afara tunelului. Rețelele interne din spatele ei devin accesibile doar după ce tunelul există.

Orice ați alege, țineți-o lângă componenta care deține tunelul. O rută de gazdă rătăcită adăugată manual funcționează până la următoarea rețea, iar apoi devine întreruperea misterioasă de mâine.