Kill switch blokira strežnik VPN, preden se pretaka kakšen promet
Katero stopnjo blokira kill switch: iskanje končne točke, zunanja pot, povratna pot in zastarele izjeme za partnerje — s števci namesto ugibanj.
Kill switchi odpovejo v smeri, ki je ljudje ne pričakujejo: zgrajeni so, da blokirajo promet, ko je tunel spodaj, paketi, ki gradijo tunel, pa so sami promet. To je vsa napaka. Nabor pravil, ki zavrže vse, kar ne gre skozi tunel, zavrže tudi rokovanje, ki bi ga moralo dvigniti, zato odjemalec poskuša znova v zanki in napaka se pripiše tisti stopnji, ki se preveri prva. Preden razširite požarni zid, ugotovite, katera od treh stopenj je zavrnjena: iskanje imena, zunanji paket do partnerja ali odgovor, ki se vrne.
Kako sta tunel in njegov lastni transport odvisna drug od drugega
Berite odjemalca VPN kot dve omrežni stanji, ki si delita eno pot vtičnice. Preden tunel obstaja, odjemalec odpre vtičnico na fizičnem vmesniku in pošlje šifrirane okvire na naslov in vrata partnerja. Šele ko ta izmenjava uspe, ustvari tunelsko napravo in namesti poti. Kill switch je politika o drugem stanju, napisana tako široko, da velja za oba.
Pravila na podlagi vmesnika so običajna oblika: sprejmite tisto, kar gre ven skozi tun0 ali wg0, zavrzite preostanek izhodne poti. Ta formulacija ne more izvzeti lastne povezave odjemalca s strežnikom, zato pravilna izvedba to izjemo doda izrecno, in tudi vi, ko pravila pišete ročno. Pravila za posamezne aplikacije v Windows in macOS se delu tega izognejo tako, da ujemajo proces namesto vmesnika, a proces mora vseeno priti ven, preden tunel obstaja.
Tri stopnje, v vrstnem redu, v katerem se zgodijo
Prva stopnja je razreševanje. Ko profil shranjuje ime gostitelja namesto dobesednega naslova, odjemalec potrebuje odgovor DNS, preden lahko kar koli pošlje. Profil, ki usmerja DNS na razreševalnik tunela, ustvari slepo ulico: razreševalnik je dosegljiv le skozi tunel, ki naj bi ga iskanje omogočilo. Razreševanje zunaj tunela ali pripetje končne točke na naslov odpravi to dvoumnost.
Druga stopnja je zunanji paket, ki mora v tem vrstnem redu najprej prestati usmerjanje in nato požarni zid. wireguard-tools opravi usmerjevalno polovico tega za WireGuard tako, da označi svoje pakete in doda pravilo politike, da preskočijo privzeto pot, ki jo je pravkar namestil; ročna stran wg-quick opisuje to pravilo in tabelo, ki jo uporablja. Obnovite to usmerjanje ročno ali pustite drugemu orodju, da prepiše pravila, in označeni paketi so lahko poslani nazaj v tunel, ki naj bi ga vzpostavili.
Tretja stopnja je povratna pot. Rokovanje brez odgovora ni dokaz zavrženja na izhodu; enako se ujema s pravili vhoda na strežniku ali napravo NAT, ki je pozabila preslikavo. Ločite to, preden se dotaknete odjemalca.
| 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 |
Odjemalci beležijo simptom, ki ga zaznajo, ne stopnje, ki je spodletela, zato je tabela običajno hitrejša od dnevnika.
Števci odločajo hitreje kot dnevniki
V Linuxu, nft list ruleset ali iptables -vnL OUTPUT izpiše števec paketov na pravilo. Povežite se enkrat, pustite, da spodleti, in nato znova preberite števce. Pravilo, katerega števec se je premaknil, je pravilo, ki ga je zadelo rokovanje; če se ni nič nikjer premaknilo, paket ni nikoli dosegel požarnega zidu. Videl sem nabor pravil, ki je zavrgel lastno rokovanje, in to so povedali le števci.
Da ločite nikoli ni dosegel požarnega zidu od nikoli ni zapustil gostitelja, opazujte sam vmesnik. ip -s link show dev wlan0 poroča o poslanih paketih, in tcpdump -ni wlan0 udp port 51820 prikazuje okvire. Če ostane raven, medtem ko odjemalec poskuša znova, je napaka nad netfilter: manjka pot do partnerja, pravilo politike kaže na napravo, ki še ne obstaja, ali napaka vtičnice, ki jo odjemalec pogoltne.
Preizkusite izjeme na dokumentacijskih naslovih, kot je 203.0.113.10, da spodrsljaj ne more sondirati tujega gostitelja.
Zastarela izjema končne točke se bere kot izpad strežnika
Najbolj zavajajoča različica se pojavi po tem, ko se naslov partnerja spremeni: storitev dinamičnih naslovov ga je premaknila, gostitelj je bil ponovno zgrajen ali je izhodni naslov vašega omrežja drugačen. Izjema še vedno navaja stari naslov, zato paketi na novega zadenejo pravilo zavrženja. Ista konfiguracija je delovala včeraj, zato ljudje začnejo z diagnostiko strežnika.
Ime gostitelja znotraj pravila požarnega zidu vas ne reši. V nftables se ime razreši ob nalaganju nabora pravil, zato pripne naslov, ki je takrat obstajal, in zastara kot dobesedni. Trajna rešitev je posodabljanje izjeme, ko se končna točka spremeni, in ohranjanje ozke: en naslov partnerja, ena transportna vrata. Obseg, dovolj širok, da preživi spremembo naslova, je dovolj širok tudi za spust nepovezanega prometa.
Ko kill switch teče na gostitelju strežnika
Ista odvisnost je na drugem koncu, in tam jo je lažje spregledati. Če stroj, ki služi kot vaš strežnik VPN, poganja tudi namiznega odjemalca s kill switchom ali profil požarnega zidu, kopiran s prenosnika, njegova pravila zavrženja veljajo za storitev, ki končuje tunele. Odgovori na rokovanje odjemalca so zavrženi, zato se noben odjemalec ne more povezati, medtem ko je strežnik videti zdrav in njegov tunelski vmesnik stoji neuporabljen.
Ta gostitelj potrebuje tri ozke odobritve pred zavrženjem: vrata za poslušanje na fizičnem vmesniku, tunelski vmesnik za dešifriran promet in posredovanje iz tunela proti temu, kar naj bi odjemalci dosegli. Preberite nameščeni nabor z nft list ruleset, iptables -S, ali pfctl -sr , preden karkoli spremenite, in ne pozabite, da shranjen nabor pravil preživi ponovni zagon, zato napaka tam preživi proces, ki jo je ustvaril.
Vrstni red obnovitve, ki drži stroj zaprt
Delajte od profila navzven. Preberite naslov in vrata partnerja, ki jih uporablja odjemalec, potrdite, da se ime gostitelja razreši brez tunela, nato dodajte eno izjemo za ta naslov in vrata samo na fizičnem vmesniku. Znova se povežite in opazujte števec pošiljanja; dokončano rokovanje je znak, da je druga stopnja popravljena.
Pustite preostanek politike zavrženja na mestu med preizkušanjem. Neškodljiv pregled je poskus povezave z nepovezanim dokumentacijskim naslovom in potrditev, da še vedno poteče, kar kaže, da kill switch deluje in ni izklopljen. Zaostrite izjemo, ko je tunel stabilen, in ne puščajte trajnega dovoljenja za vse za odjemalski program samo zato, ker je priročno.
Če se tunel dvigne in aplikacija še vedno odpove, preostale stopnje niso ta: razdeljeni DNS, MTU in usmerjanje po aplikacijah vsak dajo povezan tunel z zlomljenim prometom, in vsak ima drugačen prvi pregled.