Kill switch blokkearret de VPN-tsjinner foardat der ferkear floeit
Hokker stadium in kill switch blokkearret: einpunt-opspoaring, bûtenrûte, weromwei en ferâldere peer-útsûnderingen — mei tellers yn plak fan riedens.
Kill switches misse yn in rjochting dy’t minsken net ferwachtsje: se binne boud om ferkear te blokkearjen wylst de tunnel del is, en de pakketten dy’t de tunnel bouwe binne sels ferkear. Dat is de hiele flater. In regelset dy’t alles weilizze lit wat net troch de tunnel nei bûten giet, lit ek de hânskotting weilizze dy’t him ophelje soe, dus besiket de klant yn in lus op ’e nij en heart de flater by it stadium dat as earste kontrolearre wurdt. Foardat jo in firewall ferbreidzje, sykje út hokker fan trije stadia wegere wurdt: it sykjen fan de namme, it bûtenpakket nei de peer, of it antwurd dat weromkomt.
Hoe’t de tunnel en syn eigen ferfier fan elkoar ôfhinklik binne
Lês in VPN-klant as twa netwurksteaten dy’t ien socketwei diele. Foardat de tunnel bestiet, iepenet de klant in socket op de fysike adapter en stjoert fersifere frames nei it adres en de poarte fan de peer. Pas as dy útwikseling slagget, makket er it tunnelapparaat en ynstallearret er rûtes. In kill switch is in belied oer de twadde steat, sa breed skreaun dat it foar beide jildt.
Regels op basis fan ’e ynterface binne de gewoane foarm: akseptearje wat nei bûten giet troch tun0 of wg0, lis de rest fan it útgongspaad wei. Dy formulearring kin de eigen ferbining fan de klant mei de tsjinner net útsûnderje, dus in korrekte ymplemintaasje foeget dy útsûndering eksplisyt ta, en jo ek as jo regels mei de hân skriuwe. Regels per applikaasje op Windows en macOS omseilje in part hjirfan troch in proses yn plak fan in ynterface te ferlykjen, mar it proses moat noch altyd nei bûten foardat de tunnel bestiet.
Trije stadia, yn ’e folchoarder wêryn’t se barre
It earste stadium is oplossing. As it profyl in hostnamme yn plak fan in letterlik adres bewarret, hat de klant in DNS-antwurd nedich foardat er eat stjoere kin. In profyl dat DNS nei de oplosser fan de tunnel wiist, makket in deade ein: de oplosser is allinnich berikber troch de tunnel dy’t it sykjen mooglik meitsje moat. Oplosse bûten de tunnel, of it einpunt oan in adres fêstsette, hellet de dûbelsinnigens fuort.
It twadde stadium is it bûtenpakket, dat earst de rûtering en dêrnei de firewall oerlibje moat, yn dy folchoarder. wireguard-tools docht de rûteringshelte hjirfan foar WireGuard troch syn eigen pakketten te markearjen en in beliedsregel ta te foegjen sadat se de standertrûte dy’t er krekt ynstallearre hat, oerslaan; de manpage fan wg-quick beskriuwt dy regel en de tabel dy’t er brûkt. Bou dy rûtering mei de hân op ’e nij, of lit in twadde helpmiddel de regels oerskriuwe, en de markearre pakketten kinne werom stjoerd wurde yn de tunnel dy’t se meitsje moatte.
It tredde stadium is de weromwei. In hânskotting sûnder antwurd is gjin bewiis fan in útgongslizzing; it is like goed ferienichber mei in ynkommende regel fan ’e tsjinner of in NAT-apparaat dat de mapping fergetten is. Skied dat foardat jo de klant oanreitsje.
| 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 |
Klanten logge it symptoom dat se ûntdekke, net it stadium dat mislearre, dus de tabel is meastentiids flugger as it log.
Tellers beslisse flugger as logs
Op Linux, nft list ruleset of iptables -vnL OUTPUT printsje in pakketteller per regel. Ferbyn jo ien kear, lit it mislearje en lês dan de tellers wer. In regel wêrfan’t de teller beweegd is, is in regel dêr’t de hânskotting tsjin oan rekke; as nearne eat beweegd is, hat it pakket de firewall nea berikt. Ik haw in regelset syn eigen hânskotting weilizze sjoen, en allinnich de tellers seine dat.
Om nea de firewall berikt fan nea de host ferlitten te skieden, hâld de ynterface sels yn ’e gaten. ip -s link show dev wlan0 rapportearret ferstjoerde pakketten, en tcpdump -ni wlan0 udp port 51820 lit de frames sjen. As it flak bliuwt wylst de klant op ’e nij besiket, sit de flater boppe netfilter: in ûntbrekkende peer-rûte, in beliedsregel dy’t nei in apparaat wiist dat noch net bestiet, of in socketflater dy’t de klant trochslokt.
Test útsûnderingen tsjin dokumintaasje-adressen lykas 203.0.113.10, sadat in ferslies it host fan in oar net probearje kin.
In ferâldere einpunt-útsûndering lêst as in tsjinnersteuring
De meast misliedende ferzje ferskynt neidat it adres fan ’e peer feroare is: in tsjinst foar dynamyske adressen hat it ferpleatst, de host is op ’e nij boud, of it útgongsadres fan jo netwurk is oars. De útsûndering neamt noch it âlde adres, dus pakketten nei it nije reitsje de lizzingsregel. Deselde konfiguraasje wurke juster, en dêrom begjinne minsken mei it diagnoaze fan ’e tsjinner.
In hostnamme binnen in firewallregel rêdt jo net. Yn nftables wurdt de namme oplost as de regelset laden wurdt, dus it pinnelet it adres dat op dat stuit bestie en wurdt ferâldere as in letterlik ien. De duorsume oplossing is de útsûndering by te wurkjen as it einpunt feroaret en har smel te hâlden: ien peer-adres, ien transportpoarte. In berik dat breed genôch is om in adresferoaring te oerlibjen, is ek breed genôch om net besibbe ferkear nei bûten te litten.
As de kill switch op ’e tsjinner-host draait
Deselde ôfhinklikheid bestiet oan ’e oare kant, en dêr is se makliker te missen. As de masine dy’t as jo VPN-tsjinner tsjinnet ek in desktopklant mei kill switch draait, of in firewallprofyl dat fan in laptop kopyearre is, jilde syn lizzingsregels foar de tsjinst dy’t de tunnels einiget. Antwurden op in hânskotting fan in klant wurde weilizze, dus elke klant kin net ferbine wylst de tsjinner sûn liket en syn tunnel-ynterface ûnbrûkt stiet.
Dy host hat trije smelle akseptaasjes foar de lizzing nedich: de harkpoarte op ’e fysike ynterface, de tunnel-ynterface foar ûntsifere ferkear, en trochstjoering fan ’e tunnel nei wat de klanten berikke moatte. Lês de ynstalleare set mei nft list ruleset, iptables -S, of pfctl -sr foardat jo eat feroarje, en betink dat in bewarre regelset in werstart oerlibbet, dus in flater dêr oerlibbet it proses dat him makke hat.
Weromsetfolchoarder dy’t de masine ticht hâldt
Wurkje fan it profyl nei bûten ta. Lês it peer-adres en de poarte dy’t de klant brûkt, befêstigje dat de hostnamme sûnder de tunnel oplost, en foegje dan ien útsûndering ta foar dat adres en dy poarte, allinnich op ’e fysike adapter. Ferbyn jo wer en hâld de stjoerteller yn ’e gaten; in foltôge hânskotting is it sinjaal dat stadium twa reparearre is.
Lit de rest fan it lizzingsbelied op syn plak wylst jo teste. In ûnskuldige kontrôle is in ferbining besykje nei in net besibbe dokumintaasje-adres en befêstigje dat dy noch altyd ferrint, wat sjen lit dat de kill switch wurket yn stee fan útskeakele is. Krimp de útsûndering as de tunnel stabyl is, en lit gjin permaninte alles-tastean foar it klantprogramma lizze om’t it handich is.
As de tunnel omheech komt en de applikaasje noch mislearret, binne de oerbleaune stadia net dit iene: splitst DNS, MTU en rûtering per applikaasje jouwe elk in ferbûne tunnel mei brutsen ferkear, en elk hat in oare earste kontrôle.