Kill-switch blokkeer die VPN-bediener voordat enige verkeer vloei
Watter stadium ’n kill-switch blokkeer: eindpunt-opsoek, buitenste roete, terugpad en verouderde eweknie-uitsonderings, met tellers eerder as raaiskote.
Kill-switches faal in ’n rigting wat mense nie verwag nie: hulle is gebou om verkeer te blokkeer terwyl die tonnel af is, en die pakkette wat die tonnel bou, is self verkeer. Dit is die hele fout. ’n Reëlstel wat alles laat val wat nie deur die tonnel verlaat nie, laat ook die handskud val wat dit sou opbring, so die kliënt probeer in ’n lus weer en die fout hoort by watter stadium ook al eerste nagegaan word. Voordat jy ’n firewall verbreed, vind uit watter van drie stadiums geweier word: die naamopsoek, die buitenste pakket na die eweknie, of die antwoord wat terugkom.
Hoe die tonnel en sy eie vervoer van mekaar afhanklik is
Lees ’n VPN-kliënt as twee netwerktoestande wat een sokpad deel. Voordat die tonnel bestaan, maak die kliënt ’n sok op die fisiese adapter oop en stuur geïnkripteerde rame na die eweknie se adres en poort. Eers nadat daardie uitruiling slaag, skep hy die tonneltoestel en installeer roetes. ’n Kill-switch is ’n beleid oor die tweede toestand, so breed geskryf dat dit op albei van toepassing is.
Koppelvlakgebaseerde reëls is die gewone vorm: aanvaar wat deur tun0 of wg0, laat val die res van die uitvoerpad. Daardie formulering kan nie die kliënt se eie verbinding na die bediener vrystel nie, so ’n korrekte implementering voeg daardie uitsondering eksplisiet by, en jy ook wanneer jy reëls met die hand skryf. Per-toepassing-reëls op Windows en macOS omseil ’n deel hiervan deur ’n proses eerder as ’n koppelvlak te pas, maar die proses moet steeds uitkom voordat die tonnel bestaan.
Drie stadiums, in die volgorde waarin hulle gebeur
Die eerste stadium is oplossing. Wanneer die profiel ’n hostnaam in plaas van ’n letterlike adres stoor, het die kliënt ’n DNS-antwoord nodig voordat hy enigiets kan stuur. ’n Profiel wat DNS na die tonnel-oplosser wys, skep ’n dooie punt: die oplosser is slegs bereikbaar deur die tonnel wat die opsoek veronderstel is om te aktiveer. Om buite die tonnel op te los, of om die eindpunt aan ’n adres vas te pen, verwyder die onduidelikheid.
Die tweede stadium is die buitenste pakket, wat in daardie volgorde eers deur die roetering en dan deur die firewall moet kom. wireguard-tools hanteer die roeteringshelfte hiervan vir WireGuard deur sy eie pakkette te merk en ’n beleidsreël by te voeg sodat hulle die verstekroete wat hy pas geïnstalleer het, oorslaan; die wg-quick-manbladsy beskryf daardie reël en die tabel wat dit gebruik. Bou daardie roetering met die hand weer op, of laat ’n tweede instrument die reëls herskryf, en die gemerkte pakkette kan teruggestuur word in die tonnel in wat hulle veronderstel is om te vestig.
Die derde stadium is die terugpad. ’n Handskud sonder antwoord is nie bewys van ’n uitgaande blokkering nie; dit is ewe versoenbaar met ’n bediener se inkomende reël of ’n NAT-toestel wat die kartering vergeet het. Skei dié twee voordat jy aan die kliënt raak.
| 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 |
Kliënte teken die simptoom aan wat hulle bespeur, nie die stadium wat misluk het nie, so die tabel is gewoonlik vinniger as die log.
Tellers besluit vinniger as logs
Op Linux, nft list ruleset of iptables -vnL OUTPUT druk ’n pakketteller per reël. Maak een keer verbinding, laat dit misluk en lees dan weer die tellers. ’n Reël waarvan die teller beweeg het, is ’n reël wat die handskud getref het; as niks enige plek beweeg het nie, het die pakket nooit die firewall bereik nie. Ek het al gesien hoe ’n reëlstel sy eie handskud laat val, en net die tellers het dit gesê.
Om te onderskei tussen nooit die firewall bereik nie en nooit die gasheer verlaat nie, hou die koppelvlak self dop. ip -s link show dev wlan0 rapporteer gestuurde pakkette, en tcpdump -ni wlan0 udp port 51820 wys die rame. As dit plat bly terwyl die kliënt weer probeer, is die fout stroomop van netfilter: ’n ontbrekende eweknie-roete, ’n beleidsreël wat na ’n toestel wys wat nog nie bestaan nie, of ’n sokfout wat die kliënt insluk.
Toets uitsonderings teen dokumentasie-adresse soos 203.0.113.10, sodat ’n fout nie iemand anders se gasheer kan peil nie.
Verouderde eindpunt-uitsondering lyk soos ’n bediener-onderbreking
Die misleidendste weergawe verskyn nadat die eweknie-adres verander het: ’n dinamiese-adresdiens het dit verskuif, die gasheer is herbou, of jou netwerk se uitgangsadres verskil. Die uitsondering noem steeds die ou adres, so pakkette na die nuwe een tref die blokkeerreël. Dieselfde konfigurasie het gister gewerk, en daarom begin mense met die ontfouting van die bediener.
’n Hostnaam binne ’n firewall-reël red jou nie. In nftables word die naam opgelos wanneer die reëlstel gelaai word, so dit pen die adres vas wat op daardie oomblik bestaan het en word net so verouderd soos ’n letterlike een. Die blywende oplossing is om die uitsondering op te dateer wanneer die eindpunt verander en dit smal te hou: een eweknie-adres, een vervoerpoort. ’n Reeks wat wyd genoeg is om ’n adresverandering te oorleef, is ook wyd genoeg om onverwante verkeer uit te laat.
Wanneer die kill-switch op die bediener-gasheer loop
Dieselfde afhanklikheid bestaan aan die ander kant, en dit is makliker om daar te mis. As die masjien wat as jou VPN-bediener dien ook ’n lessenaarkliënt met ’n kill-switch laat loop, of ’n firewall-profiel wat van ’n skootrekenaar gekopieer is, geld sy blokkeerreëls vir die diens wat die tonnele beëindig. Antwoorde op ’n kliënt se handskud word laat val, so elke kliënt misluk om te verbind terwyl die bediener gesond lyk en sy tonnelkoppelvlak ongebruik sit.
Daardie gasheer het drie smal aanvaardings voor die blokkering nodig: die luisterpoort op die fisiese koppelvlak, die tonnelkoppelvlak vir ontsleutelde verkeer, en aanstuur van die tonnel na wat die kliënte veronderstel is om te bereik. Lees die geïnstalleerde stel met nft list ruleset, iptables -S, of pfctl -sr voordat jy enigiets verander, en onthou dat ’n volgehoue reëlstel ’n herbegin oorleef, so ’n fout daar oorleef die proses wat dit gemaak het.
Herstelorde wat die masjien toegedraai hou
Werk van die profiel af uitwaarts. Lees die eweknie-adres en poort wat die kliënt gebruik, bevestig dat die hostnaam sonder die tonnel oplos, en voeg dan een uitsondering by vir daardie adres en poort, net op die fisiese adapter. Verbind weer en hou die stuur-teller dop; ’n voltooide handskud is die teken dat stadium twee reg is.
Laat die res van die blokkeerbeleid in plek terwyl jy toets. ’n Onskadelike kontrole is om ’n verbinding na ’n onverwante dokumentasie-adres te probeer en te bevestig dat dit steeds uittyd, wat wys die kill-switch werk eerder as dat dit afgeskakel is. Maak die uitsondering strenger sodra die tonnel stabiel is, en moenie ’n permanente alles-toelaat vir die kliëntprogram los net omdat dit gerieflik is nie.
As die tonnel opkom en die toepassing steeds misluk, is die oorblywende stadiums nie hierdie een nie: gesplete DNS, MTU en per-toepassing-roetering lewer elkeen ’n verbonde tonnel met gebreekte verkeer, en elkeen het ’n ander eerste kontrole.