Cum să blochezi ieșirea Linuxului ca să nu se scurgă nimic când cade VPN-ul

Imaginează-ți o cutie media pe o conexiune de acasă care ar trebui să ajungă pe internet doar printr-un tunel. Când tunelul cade, aplicația ar trebui să se oprească în loc să continue în liniște pe interfața fizică. Obținerea acestui comportament este o problemă de firewall, nu de rutare, iar distincția contează pentru că o rută poate fi înlocuită printr-o repornire a demonului, în timp ce un filtru rămâne unde l-ai pus. În continuare vedem cum decide de fapt calea pachetului și apoi cum să delimitezi excepțiile care țin tunelul să se reconecteze.

Ieșirea locală este un cârlig diferit de forwarding

Un pachet care pleacă dintr-o aplicație de pe mașină traversează cârligul de ieșire; un pachet pe care mașina îl rutează pentru alt host traversează forwarding-ul. O politică ce menționează doar forward o restricționează pe cea de-a doua și o lasă pe prima larg deschisă, de aceea atât de multe blocaje de ieșire par corecte și nu fac nimic. Potrivirea interfeței aparține aceleiași reguli: oifname "tun0" accept lasă să treacă traficul deja rutat prin tunel. Rutarea și filtrarea rămân și ele decizii separate, așa că o rută de uplink poate exista în timp ce filtrul respinge pachetul. Pe această separare te bazezi.

Un gateway care face forwarding pentru alte dispozitive are nevoie de ambele cârlige. Blocarea doar a ieșirii protejează mașina în sine și lasă fiecare client din aval liber să scurgă.

Scrie lista excepțiilor de la punctul final spre exterior

Începe cu punctul final al tunelului: o adresă de destinație sau un set mic aprobat, protocolul de transport și portul de destinație, de exemplu udp dport 1194 ip daddr 203.0.113.7 accept. Dacă clientul rezolvă un nume de host, schimbul DNS inițial are nevoie de propria regulă limitată la resolver și la portul 53, nu de o permisiune generală către adresa acelui resolver. Fiecare excepție ar trebui să numească motivul pentru care există. O permisiune pentru tot traficul UDP către portul VPN acoperă mult mai mult decât singurul serviciu autentificat la care te gândeai.

Rezolvarea inițială este locul unde blocajele de obicei putrezesc. Un set de adrese reîmprospătat cu un temporizator are nevoie de un comportament definit când reîmprospătarea eșuează, iar acel comportament nu poate fi deschiderea legăturii până reușește. Reîmprospătează prin tunel cât timp tunelul e sus și, altfel, revino la ultimul punct final sănătos cunoscut.

Administrarea locală are nevoie de același tratament. O subrețea de management nu este de încredere doar pentru că adresele ei sunt private, iar o regulă care se bazează pe ea invită o a doua cale în jurul blocajului.

Potrivirea interfeței nu dovedește un tunel sănătos

Regulile care acceptă tot ce iese din tun0 presupun că un pachet de pe acea interfață a venit din tunel. Numele interfețelor sunt recreate, iar un nume nu este o identitate criptografică. Partenerul poate fi și plecat în timp ce interfața rămâne sus, ceea ce face regula o inacțiune foarte convingătoare.

Urmărirea conexiunilor adaugă o capcană înrudită. O regulă largă pentru conexiunile stabilite reia permisiunea pe care un flux a obținut-o mai devreme, așa că o sesiune începută înainte de căderea tunelului continuă după aceea. Restrânge acceptarea cu stare la interfețele și adresele pe care le urmărești cu adevărat, altfel ai construit un blocaj care se deschide singur. Regulile de intrare și de ieșire răspund și la întrebări diferite, iar întărirea uneia ignorând-o pe cealaltă lasă mașina accesibilă în direcția la care nu te-ai gândit.

Ce supraviețuiește unei căderi a demonului

Un filtru instalat de un script care rulează după ce tunelul urcă dispare împreună cu tunelul, exact în momentul în care era necesar. Încarcă blocajul la pornire și lasă demonul să administreze doar excepțiile lui.

Ștergerea rutei implicite nu este nici ea un substitut. Ruta este stare pe care demonul o deține și o rescrie, iar eliminarea ei poate lua calea necesară pentru reconectare. IPv6 are nevoie de propriul plan, pentru că descoperirea vecinilor și anunțurile routerului sunt servicii de legătură care trebuie să funcționeze în continuare cât timp traficul obișnuit este blocat. DHCP aparține aceleiași categorii. Notează aceste lucruri ca excepții cu un scop, în loc să le descoperi mai târziu ca întreruperi.

Cale de recuperare înainte de implementare

Testează blocajul așa cum va eșua: pornire fără tunel, omorârea demonului, schimbarea punctului final și reconectarea. Fiecare caz ar trebui să oprească aplicațiile și să lase canalul de recuperare funcțional. Fă-o de la o consolă, pentru că un shell la distanță este sesiunea care are cele mai mari șanse să fie blocată de propria ta regulă.

Apoi verifică unde mai ajunge o aplicație obișnuită, cu o destinație inofensivă și o cerere pe care o poți verifica. Rezultatul dorit este un refuz pe legătură și un succes prin tunel, nu un timeout ambiguu care ar putea însemna oricare dintre ele. Ține setul de reguli sub același proprietar ca restul firewall-ului, în loc să înlocuiești tot tabelul dintr-un script de shell. O politică în care fiecare permisiune se poate justifica valorează mai mult decât un set lung de reguli pe care nimeni nu le poate explica.