Kill switch zablokuje server VPN dřív, než proteče jakýkoli provoz
Kterou fázi kill switch blokuje: hledání koncového bodu, vnější trasu, zpáteční cestu a zastaralé výjimky pro protějšky — s počítadly místo dohadů.
Kill switch selhávají ve směru, který lidé nečekají: jsou postavené tak, aby blokovaly provoz, dokud tunel neběží, a pakety, které tunel staví, jsou samy provoz. V tom je celá chyba. Sada pravidel, která zahazuje vše, co neodchází tunelem, zahazuje i handshake, který by ho měl zvednout, takže klient zkouší znovu ve smyčce a chyba se přisoudí té fázi, která se kontroluje první. Než rozšíříte firewall, zjistěte, která ze tří fází je odmítána: hledání jména, vnější paket k protějšku, nebo odpověď, která se vrací.
Jak na sobě tunel a jeho vlastní transport závisí
Čtěte VPN klienta jako dva síťové stavy, které sdílejí jednu cestu socketu. Než tunel existuje, klient otevře socket na fyzickém adaptéru a posílá šifrované rámce na adresu a port protějšku. Teprve když tato výměna uspěje, vytvoří zařízení tunelu a nainstaluje trasy. Kill switch je politika o druhém stavu, napsaná tak široce, že platí na oba.
Pravidla založená na rozhraní jsou obvyklá forma: přijměte to, co odchází přes tun0 nebo wg0, zbytek výstupní cesty zahoďte. Taková formulace nedokáže vyjmout vlastní spojení klienta se serverem, takže správná implementace tuto výjimku přidává výslovně, a vy také, když pravidla píšete ručně. Pravidla pro jednotlivé aplikace ve Windows a macOS část tohoto obcházejí tím, že porovnávají proces místo rozhraní, ale proces se přesto musí dostat ven dřív, než tunel existuje.
Tři fáze v pořadí, v jakém nastávají
První fáze je rozlišení. Když profil ukládá jméno hostitele místo doslovné adresy, klient potřebuje odpověď DNS dřív, než cokoli odešle. Profil, který směruje DNS na resolver tunelu, vytváří slepou uličku: resolver je dostupný jen přes tunel, který má hledání umožnit. Rozlišení mimo tunel nebo připnutí koncového bodu k adrese tuto dvojznačnost odstraňuje.
Druhá fáze je vnější paket, který musí přežít nejprve směrování a potom firewall, přesně v tomto pořadí. wireguard-tools zajišťuje směrovací polovinu tohoto pro WireGuard tím, že označí vlastní pakety a přidá pravidlo politiky, aby přeskočily výchozí trasu, kterou právě nainstaloval; manuálová stránka wg-quick popisuje toto pravidlo a tabulku, kterou používá. Obnovte toto směrování ručně, nebo nechte druhý nástroj přepsat pravidla, a označené pakety mohou být poslány zpět do tunelu, který mají vytvořit.
Třetí fáze je zpáteční cesta. Handshake bez odpovědi není důkazem zahazování na výstupu; je stejně slučitelný s příchozím pravidlem serveru nebo zařízením NAT, které zapomnělo mapování. Oddělte to, než se dotknete klienta.
| 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 |
Klienti zaznamenávají příznak, který zjistí, ne fázi, která selhala, takže tabulka je obvykle rychlejší než log.
Počítadla rozhodují rychleji než logy
V Linuxu, nft list ruleset nebo iptables -vnL OUTPUT vypisuje počítadlo paketů pro každé pravidlo. Připojte se jednou, nechte to selhat a pak znovu přečtěte počítadla. Pravidlo, jehož počítadlo se pohnulo, je pravidlo, do kterého handshake narazil; pokud se nikde nic nepohnulo, paket se k firewallu nikdy nedostal. Viděl jsem sadu pravidel zahodit její vlastní handshake a řekla to jen počítadla.
Abyste oddělili nikdy se nedostal k firewallu od nikdy neopustil hostitele, sledujte samo rozhraní. ip -s link show dev wlan0 hlásí odeslané pakety a tcpdump -ni wlan0 udp port 51820 ukazuje rámce. Pokud zůstane ploché, zatímco klient zkouší znovu, je závada výše než netfilter: chybějící trasa k protějšku, pravidlo politiky mířící do zařízení, které ještě neexistuje, nebo chyba socketu, kterou klient polyká.
Testujte výjimky na dokumentačních adresách jako 203.0.113.10, aby omyl nemohl sondovat cizí hostitel.
Zastaralá výjimka koncového bodu se čte jako výpadek serveru
Nejzavádějící verze se objeví poté, co se změní adresa protějšku: služba dynamických adres ji přesunula, hostitel byl přestavěn, nebo se výchozí adresa vaší sítě liší. Výjimka stále uvádí starou adresu, takže pakety na novou spadnou pod pravidlo zahazování. Stejná konfigurace fungovala včera, a proto lidé začínají diagnostikou serveru.
Jméno hostitele uvnitř pravidla firewallu vás nezachrání. V nftables se jméno rozliší při načtení sady pravidel, takže připne adresu, která v tu chvíli existovala, a zestárne jako doslovná. Trvalým řešením je aktualizovat výjimku, když se koncový bod změní, a držet ji úzkou: jedna adresa protějšku, jeden transportní port. Rozsah dost široký, aby přežil změnu adresy, je dost široký i na to, aby pustil nesouvisející provoz.
Když kill switch běží na hostiteli serveru
Stejná závislost existuje na druhém konci a tam se přehlédne snáz. Pokud stroj, který slouží jako váš VPN server, také spouští desktopového klienta s kill switchem, nebo profil firewallu zkopírovaný z notebooku, platí jeho pravidla zahazování na službu, která tunely ukončuje. Odpovědi na handshake klienta se zahazují, takže každý klient se nemůže připojit, zatímco server vypadá zdravě a jeho tunelové rozhraní zůstává nevyužité.
Tento hostitel potřebuje tři úzká povolení před zahazováním: naslouchací port na fyzickém rozhraní, tunelové rozhraní pro dešifrovaný provoz a předávání z tunelu k tomu, čeho mají klienti dosáhnout. Přečtěte nainstalovanou sadu pomocí nft list ruleset, iptables -S, nebo pfctl -sr , než cokoli změníte, a pamatujte, že uložená sada pravidel přežije restart, takže chyba tam přežije proces, který ji udělal.
Pořadí obnovy, které udrží stroj zavřený
Pracujte od profilu ven. Přečtěte adresu a port protějšku, které klient používá, ověřte, že se jméno hostitele rozliší bez tunelu, a pak přidejte jednu výjimku pro tuto adresu a port jen na fyzickém adaptéru. Připojte se znovu a sledujte počítadlo odesílání; dokončený handshake je signál, že druhá fáze je opravená.
Zbytek politiky zahazování nechte při testování na místě. Neškodná kontrola je zkusit spojení s nesouvisející dokumentační adresou a ověřit, že stále vyprší, což ukazuje, že kill switch funguje, a ne že je vypnutý. Až se tunel ustálí, výjimku utáhněte, a nenechávejte trvalé povolení všeho pro klientský binárník jen proto, že je to pohodlné.
Pokud tunel naskočí a aplikace stále selhává, zbývající fáze nejsou tato: rozdělený DNS, MTU a směrování po aplikacích každé dávají připojený tunel s rozbitým provozem a každé má jinou první kontrolu.