A kill switch blokkolja a VPN-kiszolgálót, mielőtt bármilyen forgalom elindulna
Melyik szakaszt blokkolja a kill switch: végpontfeloldás, külső útvonal, visszaút és elavult társ-kivételek — találgatás helyett számlálókkal.
A kill switchek olyan irányban hibáznak, amire az emberek nem számítanak: arra épültek, hogy blokkolják a forgalmat, amíg az alagút áll, és az alagutat építő csomagok maguk is forgalom. Ez az egész hiba. Az a szabálykészlet, amely mindent eldob, ami nem az alagúton keresztül megy ki, az azt felhozó kézfogást is eldobja, ezért a kliens hurokban próbálkozik újra, és a hiba ahhoz a szakaszhoz tartozik, amelyet először ellenőriznek. Mielőtt szélesíti a tűzfalat, derítse ki, melyik szakaszt utasítják el a három közül: a névfeloldást, a társ felé menő külső csomagot vagy a visszatérő választ.
Hogyan függ egymástól az alagút és a saját átvitele
Olvassa a VPN-klienst két hálózati állapotként, amelyek egy socket-útvonalat osztanak meg. Mielőtt az alagút létezik, a kliens socketet nyit a fizikai adapteren, és titkosított kereteket küld a társ címére és portjára. Csak miután ez a csere sikerül, hozza létre az alagút-eszközt és telepíti az útvonalakat. A kill switch a második állapotra vonatkozó szabályzat, olyan szélesre írva, hogy mindkettőre érvényes.
Az interfész alapú szabályok a szokásos forma: fogadja el, ami ezen keresztül megy ki: tun0 vagy wg0, dobja el a kimeneti útvonal többi részét. Ez a megfogalmazás nem tudja kivonni a kliens saját kapcsolatát a kiszolgálóval, ezért a helyes megvalósítás ezt a kivételt kifejezetten hozzáadja, és ön is, amikor kézzel ír szabályokat. A Windows és macOS alatti alkalmazásonkénti szabályok ennek egy részét elkerülik azzal, hogy interfész helyett folyamatot párosítanak, de a folyamatnak így is ki kell jutnia, mielőtt az alagút létezik.
Három szakasz, abban a sorrendben, ahogy történnek
Az első szakasz a feloldás. Amikor a profil szó szerinti cím helyett hosztnevet tárol, a kliensnek DNS-válaszra van szüksége, mielőtt bármit küldhetne. Az a profil, amely a DNS-t az alagút feloldójára irányítja, holtpontot teremt: a feloldó csak azon az alagúton keresztül érhető el, amelyet a keresésnek lehetővé kellene tennie. Az alagúton kívüli feloldás vagy a végpont címhez rögzítése megszünteti a kétértelműséget.
A második szakasz a külső csomag, amelynek előbb az útválasztást, majd a tűzfalat kell túlélnie, ebben a sorrendben. A wireguard-tools elvégzi ennek az útválasztási felét a WireGuard számára azzal, hogy megjelöli a saját csomagjait, és hozzáad egy házirend-szabályt, hogy kihagyják az éppen telepített alapértelmezett útvonalat; a wg-quick kézikönyvoldala leírja ezt a szabályt és a használt táblázatot. Építse újra ezt az útválasztást kézzel, vagy hagyja, hogy egy második eszköz átírja a szabályokat, és a megjelölt csomagok visszaküldhetők abba az alagútba, amelyet létre kellene hozniuk.
A harmadik szakasz a visszaút. A válasz nélküli kézfogás nem bizonyíték a kimenő eldobásra; ugyanúgy összeegyeztethető egy kiszolgálói bejövő szabállyal vagy egy NAT-eszközzel, amely elfelejtette a leképezést. Válassza szét ezeket, mielőtt a klienshez nyúl.
| 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 |
A kliensek a felismert tünetet naplózzák, nem a meghibásodott szakaszt, ezért a táblázat általában gyorsabb a naplónál.
A számlálók gyorsabban döntenek a naplóknál
Linuxon, nft list ruleset vagy iptables -vnL OUTPUT csomagszámlálót nyomtat szabályonként. Csatlakozzon egyszer, hagyja meghibásodni, majd olvassa újra a számlálókat. Az a szabály, amelynek a számlálója elmozdult, az a szabály, amelyet a kézfogás eltalált; ha sehol sem mozdult semmi, a csomag soha nem érte el a tűzfalat. Láttam már szabálykészletet a saját kézfogását eldobni, és csak a számlálók mondták meg.
Hogy megkülönböztesse a soha nem érte el a tűzfalat a soha nem hagyta el a gazdagépet esetétől, figyelje magát az interfészt. ip -s link show dev wlan0 jelenti a küldött csomagokat, és tcpdump -ni wlan0 udp port 51820 mutatja a kereteket. Ha lapos marad, miközben a kliens újra próbálkozik, a hiba a netfilter felett van: hiányzó társ-útvonal, olyan eszközre mutató házirend-szabály, amely még nem létezik, vagy socket-hiba, amelyet a kliens lenyel.
Tesztelje a kivételeket dokumentációs címeken, például 203.0.113.10, hogy egy hiba ne tudja más gazdagépét fürkészni.
Az elavult végpont-kivétel kiszolgáló-kiesésként olvasható
A legfélrevezetőbb változat a társ címének megváltozása után jelenik meg: egy dinamikus cím szolgáltatás elmozdította, a gazdagépet újraépítették, vagy a hálózat kimenő címe más. A kivétel még mindig a régi címet nevezi meg, ezért az új címre menő csomagok az eldobási szabályra futnak. Ugyanez a konfiguráció tegnap működött, és ezért kezdik az emberek a kiszolgáló hibakeresésével.
A tűzfalszabályon belüli hosztnév nem menti meg. Az nftablesben a nevet a szabálykészlet betöltésekor oldja fel, tehát rögzíti azt a címet, amely abban a pillanatban létezett, és elavul, mint egy szó szerinti. A tartós megoldás a kivétel frissítése, amikor a végpont változik, és szűken tartása: egy társ-cím, egy átviteli port. Az a tartomány, amely elég széles egy címváltozás túléléséhez, elég széles ahhoz is, hogy nem kapcsolódó forgalmat engedjen ki.
Amikor a kill switch a kiszolgáló gazdagépén fut
Ugyanez a függőség a másik végén is megvan, és ott könnyebb elszalasztani. Ha a VPN-kiszolgálóként működő gép kill switch-es asztali klienst is futtat, vagy laptopról másolt tűzfalprofilt, annak eldobási szabályai az alagutakat lezáró szolgáltatásra vonatkoznak. A kliens kézfogására adott válaszok eldobódnak, ezért minden kliens nem tud csatlakozni, miközben a kiszolgáló egészségesnek látszik, és az alagút-interfésze kihasználatlanul áll.
Ennek a gazdagépnek három szűk elfogadás kell az eldobás előtt: a figyelő port a fizikai interfészen, az alagút-interfész a visszafejtett forgalomhoz, és az továbbítás az alagútból afelé, amit a klienseknek el kell érniük. Olvassa ki a telepített készletet ezzel: nft list ruleset, iptables -S, vagy pfctl -sr , mielőtt bármit módosít, és ne feledje, hogy a mentett szabálykészlet túléli az újraindítást, így az ottani hiba túléli az őt létrehozó folyamatot.
Helyreállítási sorrend, amely zárva tartja a gépet
A profilból kifelé dolgozzon. Olvassa ki a társ címét és portját, amelyet a kliens használ, erősítse meg, hogy a hosztnév az alagút nélkül feloldódik, majd adjon hozzá egy kivételt ahhoz a címhez és porthoz csak a fizikai adapteren. Csatlakozzon újra, és figyelje a küldési számlálót; a befejezett kézfogás a jele annak, hogy a második szakasz rendben van.
Hagyja a többi eldobási szabályzatot a helyén a tesztelés alatt. Ártalmatlan ellenőrzés megpróbálni egy kapcsolatot egy nem kapcsolódó dokumentációs címre, és megerősíteni, hogy még mindig időtúllépéssel végződik, ami azt mutatja, hogy a kill switch működik, nem pedig ki van kapcsolva. Szigorítsa a kivételt, amikor az alagút stabil, és ne hagyjon állandó mindent engedélyező szabályt a kliens binárisának csak azért, mert kényelmes.
Ha az alagút feljön, és az alkalmazás még mindig meghibásodik, a maradék szakaszok nem ez: a megosztott DNS, az MTU és az alkalmazásonkénti útválasztás mindegyike csatlakozott alagutat ad törött forgalommal, és mindegyiknek más az első ellenőrzése.