Kill switch blochează serverul VPN înainte să curgă orice trafic
Ce etapă blochează un kill switch: căutarea punctului final, ruta exterioară, calea de întoarcere și excepțiile învechite pentru parteneri — cu contoare în loc de presupuneri.
Kill switch-urile eșuează într-o direcție la care oamenii nu se așteaptă: sunt construite să blocheze traficul cât timp tunelul este jos, iar pachetele care construiesc tunelul sunt ele însele trafic. Asta este toată eroarea. Un set de reguli care aruncă tot ce nu iese prin tunel aruncă și strângerea de mână care ar trebui să-l ridice, așa că clientul reîncearcă în buclă, iar eroarea este atribuită etapei care este verificată prima. Înainte de a lărgi un firewall, aflați care dintre cele trei etape este refuzată: căutarea numelui, pachetul exterior către partener sau răspunsul care se întoarce.
Cum depind unul de altul tunelul și propriul său transport
Citiți un client VPN ca două stări de rețea care împart o singură cale de socket. Înainte ca tunelul să existe, clientul deschide un socket pe adaptorul fizic și trimite cadre criptate la adresa și portul partenerului. Abia după ce acel schimb reușește creează dispozitivul de tunel și instalează rutele. Un kill switch este o politică despre a doua stare, scrisă atât de larg încât se aplică ambelor.
Regulile bazate pe interfață sunt forma obișnuită: acceptați ce iese prin tun0 sau wg0, aruncați restul căii de ieșire. Această formulare nu poate excepta propria conexiune a clientului la server, așa că o implementare corectă adaugă acea excepție în mod explicit, și la fel faceți și dumneavoastră când scrieți reguli de mână. Regulile pe aplicație din Windows și macOS ocolesc o parte din asta potrivind un proces în loc de o interfață, dar procesul tot trebuie să iasă înainte ca tunelul să existe.
Trei etape, în ordinea în care se întâmplă
Prima etapă este rezolvarea. Când profilul stochează un nume de gazdă în loc de o adresă literală, clientul are nevoie de un răspuns DNS înainte să poată trimite ceva. Un profil care îndreaptă DNS-ul spre resolverul tunelului creează un blocaj: resolverul este accesibil doar prin tunelul pe care căutarea ar trebui să-l activeze. Rezolvarea în afara tunelului, sau fixarea punctului final la o adresă, elimină această ambiguitate.
A doua etapă este pachetul exterior, care trebuie să supraviețuiască mai întâi rutării și apoi firewall-ului, în această ordine. wireguard-tools se ocupă de jumătatea de rutare a acestui lucru pentru WireGuard, marcându-și propriile pachete și adăugând o regulă de politică pentru ca acestea să sară peste ruta implicită pe care tocmai a instalat-o; pagina de manual a wg-quick descrie acea regulă și tabelul pe care îl folosește. Reconstruiți acea rutare manual, sau lăsați un al doilea instrument să rescrie regulile, iar pachetele marcate pot fi trimise înapoi în tunelul pe care ar trebui să-l stabilească.
A treia etapă este calea de întoarcere. O strângere de mână fără răspuns nu este dovada unei aruncări la ieșire; este la fel de compatibilă cu o regulă de intrare a serverului sau cu un dispozitiv NAT care a uitat maparea. Separați-le înainte de a atinge clientul.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Clienții înregistrează simptomul pe care îl detectează, nu etapa care a eșuat, așa că tabelul este de obicei mai rapid decât jurnalul.
Contoarele decid mai repede decât jurnalele
În Linux, nft list ruleset sau iptables -vnL OUTPUT tipărește un contor de pachete pe regulă. Conectați-vă o dată, lăsați-l să eșueze, apoi citiți din nou contoarele. O regulă al cărei contor s-a mișcat este o regulă lovită de strângerea de mână; dacă nimic nu s-a mișcat nicăieri, pachetul nu a ajuns niciodată la firewall. Am văzut un set de reguli aruncându-și propria strângere de mână, și doar contoarele au spus-o.
Pentru a distinge niciodată nu a ajuns la firewall de niciodată nu a plecat de pe gazdă, urmăriți interfața însăși. ip -s link show dev wlan0 raportează pachetele trimise, iar tcpdump -ni wlan0 udp port 51820 arată cadrele. Dacă rămâne plat în timp ce clientul reîncearcă, defecțiunea este deasupra netfilter: lipsește o rută către partener, o regulă de politică indică un dispozitiv care încă nu există, sau o eroare de socket pe care clientul o înghite.
Testați excepțiile cu adrese de documentare precum 203.0.113.10, ca o scăpare să nu poată sonda gazda altcuiva.
O excepție învechită de punct final se citește ca o cădere a serverului
Cea mai înșelătoare versiune apare după ce adresa partenerului se schimbă: un serviciu de adrese dinamice a mutat-o, gazda a fost reconstruită, sau adresa de ieșire a rețelei dumneavoastră este alta. Excepția numește încă adresa veche, așa că pachetele către cea nouă ajung pe regula de aruncare. Aceeași configurație funcționa ieri, și de aceea oamenii încep cu diagnosticarea serverului.
Un nume de gazdă într-o regulă de firewall nu vă salvează. În nftables numele este rezolvat la încărcarea setului de reguli, așa că fixează adresa care exista în acel moment și devine învechit ca una literală. Soluția durabilă este să actualizați excepția când punctul final se schimbă și să o țineți îngustă: o adresă de partener, un port de transport. Un interval suficient de larg ca să supraviețuiască unei schimbări de adresă este la fel de larg pentru a lăsa să iasă trafic nelegat.
Când kill switch-ul rulează pe gazda serverului
Aceeași dependență există și la celălalt capăt, iar acolo este mai ușor de ratat. Dacă mașina care servește drept server VPN rulează și un client de birou cu kill switch, sau un profil de firewall copiat de pe un laptop, regulile ei de aruncare se aplică serviciului care termină tunelurile. Răspunsurile la strângerea de mână a clientului sunt aruncate, așa că fiecare client nu se poate conecta în timp ce serverul pare sănătos și interfața sa de tunel stă nefolosită.
Acea gazdă are nevoie de trei acceptări înguste înainte de aruncare: portul de ascultare pe interfața fizică, interfața de tunel pentru traficul decriptat și redirecționarea din tunel către ceea ce clienții trebuie să atingă. Citiți setul instalat cu nft list ruleset, iptables -S, sau pfctl -sr , înainte de a schimba ceva, și amintiți-vă că un set de reguli salvat supraviețuiește unei reporniri, așa că o greșeală acolo supraviețuiește procesului care a făcut-o.
Ordinea de recuperare care ține mașina închisă
Lucrați dinspre profil spre exterior. Citiți adresa și portul partenerului pe care le folosește clientul, confirmați că numele de gazdă se rezolvă fără tunel, apoi adăugați o excepție pentru acea adresă și port doar pe adaptorul fizic. Reconectați-vă și urmăriți contorul de trimitere; o strângere de mână finalizată este semnalul că a doua etapă este reparată.
Lăsați restul politicii de aruncare la locul ei în timpul testării. O verificare inofensivă este să încercați o conexiune la o adresă de documentare fără legătură și să confirmați că încă expiră, ceea ce arată că kill switch-ul funcționează, nu că este oprit. Strângeți excepția când tunelul este stabil, și nu lăsați o permisiune permanentă pentru tot pentru binarul clientului doar pentru că este comod.
Dacă tunelul urcă și aplicația încă eșuează, etapele rămase nu sunt aceasta: DNS-ul divizat, MTU și rutarea pe aplicație produc fiecare un tunel conectat cu trafic stricat, și fiecare are o primă verificare diferită.