Kill switch blokira VPN server prije nego što krene ikakav saobraćaj
Koju fazu kill switch blokira: traženje krajnje tačke, vanjsku rutu, povratni put i zastarjele izuzetke za partnere — s brojačima umjesto nagađanja.
Kill switch uređaji otkazuju u smjeru koji ljudi ne očekuju: napravljeni su da blokiraju saobraćaj dok je tunel pao, a paketi koji grade tunel i sami su saobraćaj. U tome je cijela greška. Skup pravila koji odbacuje sve što ne izlazi kroz tunel odbacuje i rukovanje koje bi ga podiglo, pa klijent ponavlja u petlji, a greška pripada onoj fazi koja se prva provjerava. Prije nego proširite firewall, utvrdite koja se od tri faze odbija: traženje imena, vanjski paket prema partneru ili odgovor koji se vraća.
Kako tunel i njegov vlastiti transport zavise jedan od drugog
Čitajte VPN klijenta kao dva mrežna stanja koja dijele jednu putanju soketa. Prije nego tunel postoji, klijent otvara soket na fizičkom adapteru i šalje šifrirane okvire na adresu i port partnera. Tek nakon što ta razmjena uspije, stvara tunelski uređaj i postavlja rute. Kill switch je politika o drugom stanju, napisana tako široko da se primjenjuje na oba.
Pravila zasnovana na interfejsu uobičajen su oblik: prihvatite ono što izlazi kroz tun0 ili wg0, odbacite ostatak izlazne putanje. Ta formulacija ne može izuzeti vlastitu vezu klijenta sa serverom, pa ispravna implementacija to izuzeće dodaje izričito, kao i vi kada pravila pišete ručno. Pravila po aplikaciji na Windowsu i macOS-u zaobilaze dio ovoga upoređujući proces umjesto interfejsa, ali proces ipak mora izaći prije nego tunel postoji.
Tri faze, redom kojim se dešavaju
Prva faza je razrješavanje. Kada profil čuva ime hosta umjesto doslovne adrese, klijentu treba DNS odgovor prije nego što išta pošalje. Profil koji DNS usmjerava na razrješivač tunela stvara zastoj: razrješivač je dostupan samo kroz tunel koji pretraga treba da omogući. Razrješavanje izvan tunela ili prikivanje krajnje tačke na adresu uklanja tu dvosmislenost.
Druga faza je vanjski paket, koji mora preživjeti rutiranje pa firewall, tim redom. wireguard-tools odrađuje rutirajuću polovinu ovoga za WireGuard označavanjem vlastitih paketa i dodavanjem pravila politike da preskoče zadanu rutu koju je upravo postavio; stranica priručnika za wg-quick opisuje to pravilo i tabelu koju koristi. Obnovite to rutiranje ručno ili pustite drugi alat da prepiše pravila, pa označeni paketi mogu biti poslani natrag u tunel koji treba da uspostave.
Treća faza je povratni put. Rukovanje bez odgovora nije dokaz odbacivanja na izlazu; jednako je spojivo s ulaznim pravilom servera ili NAT uređajem koji je zaboravio mapiranje. Razdvojite to prije nego dirate klijenta.
| 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 |
Klijenti bilježe simptom koji otkriju, ne fazu koja je pala, pa je tabela obično brža od dnevnika.
Brojači odlučuju brže od dnevnika
Na Linuxu, nft list ruleset ili iptables -vnL OUTPUT ispisuje brojač paketa po pravilu. Povežite se jednom, pustite da padne, pa ponovo pročitajte brojače. Pravilo kojem se brojač pomjerio jeste pravilo koje je rukovanje pogodilo; ako se nigdje ništa nije pomjerilo, paket nikada nije stigao do firewalla. Gledao sam kako skup pravila odbacuje vlastito rukovanje, i samo su brojači to rekli.
Da biste razlikovali nikad nije stiglo do firewalla od nikad nije napustilo host, gledajte sam interfejs. ip -s link show dev wlan0 prijavljuje poslane pakete, a tcpdump -ni wlan0 udp port 51820 pokazuje okvire. Ako stoji ravno dok klijent ponavlja, kvar je iznad netfiltera: ruta do partnera nedostaje, pravilo politike pokazuje u uređaj koji još ne postoji, ili klijent guta grešku soketa.
Testirajte izuzeća na dokumentacijskim adresama poput 203.0.113.10, da greška ne bi mogla ispitivati tuđi host.
Zastarjelo izuzeće krajnje tačke čita se kao ispad servera
Najzavodljivija verzija pojavljuje se nakon što se adresa partnera promijeni: servis dinamičkih adresa ju je premjestio, host je ponovo izgrađen ili se izlazna adresa vaše mreže razlikuje. Izuzeće još navodi staru adresu, pa paketi prema novoj upadaju u pravilo odbacivanja. Ista konfiguracija radila je juče, i zato ljudi počinju s dijagnostikom servera.
Ime hosta unutar firewall pravila vas ne spašava. U nftablesu se ime razrješava kad se skup pravila učita, pa prikiva adresu koja je tada postojala i zastari kao doslovna. Trajno rješenje je ažurirati izuzeće kada se krajnja tačka promijeni i držati ga uskim: jedna adresa partnera, jedan transportni port. Raspon dovoljno širok da preživi promjenu adrese dovoljno je širok i da propusti nepovezani saobraćaj.
Kada kill switch radi na hostu servera
Ista zavisnost postoji na drugom kraju, i tamo je lakše propustiti. Ako mašina koja služi kao vaš VPN server pokreće i desktop klijenta s kill switchom ili firewall profil kopiran s laptopa, njena pravila odbacivanja važe za servis koji završava tunele. Odgovori na rukovanje klijenta se odbacuju, pa svaki klijent ne uspijeva da se poveže dok server izgleda zdrav a njegov tunelski interfejs stoji neiskorišten.
Taj host treba tri uska prihvata prije odbacivanja: port za slušanje na fizičkom interfejsu, tunelski interfejs za dešifrovani saobraćaj i prosljeđivanje iz tunela prema onome što klijenti treba da dosegnu. Pročitajte instalirani skup pomoću nft list ruleset, iptables -S, ili pfctl -sr prije nego što bilo šta promijenite, i zapamtite da sačuvani skup pravila nadživi restart, pa greška tamo nadživi proces koji ju je napravio.
Redoslijed oporavka koji drži mašinu zatvorenom
Radite od profila prema van. Pročitajte adresu i port partnera koje klijent koristi, potvrdite da se ime hosta razrješava bez tunela, pa dodajte jedno izuzeće za tu adresu i port samo na fizičkom adapteru. Povežite se ponovo i gledajte brojač slanja; završeno rukovanje znak je da je druga faza ispravljena.
Ostavite ostatak politike odbacivanja na mjestu dok testirate. Bezopasna provjera je pokušati vezu s nepovezanom dokumentacijskom adresom i potvrditi da još ističe, što pokazuje da kill switch radi, a ne da je isključen. Zategnite izuzeće kad se tunel stabilizuje, i ne ostavljajte trajno dopuštenje za sve za klijentski program samo zato što je zgodno.
Ako se tunel podigne a aplikacija i dalje pada, preostale faze nisu ova: podijeljeni DNS, MTU i rutiranje po aplikaciji svaki daje povezan tunel sa pokvarenim saobraćajem, i svaki ima drugačiju prvu provjeru.