Dante SOCKS prin VPN: tunel complet sau rutare pe sursă

Vrei ca traficul proxy-ului SOCKS să iasă prin VPN în timp ce restul gazdei își păstrează calea normală. Două proiecte fac asta și diferă prin ce se strică atunci când ceva merge prost. Unul împinge o rută implicită în tunel și apoi o ocolește; celălalt lasă tabela principală în pace și trimite o singură adresă sursă către o a doua tabelă. Al doilea este mai curat și are propriile capcane.

Două proiecte, două raze de daună diferite

Proiectul cu tunel complet este ceea ce fac implicit majoritatea clienților VPN: înlocuiesc ruta implicită astfel încât totul să urmeze tunelul, apoi exclud ce nu ar trebui. Este ușor de gândit și greu de păstrat îngust, pentru că fiecare serviciu local pe care îl adaugi moștenește tunelul până îl excluzi. Modul de eșec este larg, deoarece o singură rută greșită ia cu ea conectivitatea proprie a gazdei.

Proiectul cu selecție pe sursă merge în direcția opusă. Tabela principală rămâne cum era, iar o singură regulă de politică trimite pachetele de la o adresă locală anume către o tabelă cu o rută implicită prin tunel. Nimic altceva nu se schimbă, ceea ce înseamnă că raza de daună este o adresă.

Această îngustime este și constrângerea: proiectul funcționează doar dacă pachetele de ieșire ale proxy-ului poartă într-adevăr acea adresă.

Ce face setarea external din Dante

Setarea external alege adresele pe care proxy-ul le folosește pentru conexiunile de ieșire; nu atinge politica de rutare a nucleului. Tocmai această separare face posibil al doilea proiect și tot aici oamenii citesc greșit documentația. Direcționarea external către o adresă a tunelului face ca proxy-ul să își origineze conexiunile din acea adresă, iar tabela de rutare decide apoi unde merg acele pachete.

Listenerul este o chestiune separată. Ține internal limitat la clienții care ar trebui să folosească proxy-ul, cere autentificare și închide portul cu un firewall, pentru că un listener deschis nu este o caracteristică a ieșirii VPN.

Confirmă că adresa configurată aparține într-adevăr tunelului în spațiul de nume de rețea al proxy-ului.

Construirea tabelei cu selecție pe sursă

Pentru o adresă TUN de 10.90.0.2/24 cu un peer accesibil la 10.90.0.1 și un număr de tabelă pe care nimic altceva nu îl folosește, aranjamentul arată așa:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

Ruta inaccesibilă este partea pe care oamenii o sar. Fără ea, o tabelă căreia îi dispare ruta tunelului cade pe ruta implicită obișnuită, iar proxy-ul iese în liniște prin WAN. Cu ea, căutarea eșuează, ceea ce este o defecțiune vizibilă în loc de o scurgere tăcută. Prioritatea regulii trebuie de asemenea să stea înaintea oricui altceva care corespunde acelei surse.

Aceste valori descriu o singură topologie. Peerii punct-la-punct, adresarea net30 și clienții care distribuie un alt prefix au toți nevoie de propriile rute, așa că copiază forma, nu adresele.

Unde pierde regula de sursă

O regulă care corespunde unei adrese sursă afectează fiecare proces care o folosește, nu doar proxy-ul. Dacă un alt demon leagă aceeași adresă, și traficul lui ia tunelul, iar defecțiunea va arăta ca o problemă a unui serviciu nelegat. Dă proxy-ului o adresă pe care nimic altceva nu o folosește sau acceptă că domeniul este adresa, nu procesul.

DNS este cealaltă scurgere. Un socket de resolver nu folosește neapărat sursa de date de ieșire a proxy-ului, așa că rezolvările de nume pot ieși în continuare prin WAN. Testează rezolvarea separat de stabilirea conexiunii și decide dacă acel rezultat este acceptabil.

IPv6 are nevoie de propriile reguli și rute, pentru că un aranjament IPv4 nu dovedește nimic despre el.

Alege în funcție de defecțiunea pe care o poți tolera

Alege tunelul complet când gazda trebuie protejată ca întreg și poți întreține lista de excluderi. Alege rutarea pe sursă când gazda trebuie să își păstreze propria cale și doar un serviciu trebuie redirecționat. Ambele sunt legitime; greșeala este să alegi unul și apoi să îl testezi ca și cum ar fi celălalt.

Orice ai alege, verifică din ambele părți: o cerere prin proxy și o cerere directă de la gazdă, cu adresa de ieșire observată înregistrată pentru fiecare.

Dacă tunelul cade, decide dinainte dacă proxy-ul trebuie să eșueze sau să revină, și lasă tabela de rutare să exprime această decizie.