Bakit pinapatay ng kill switch ang trapiko kapag nagpapalit ka ng server
Bakit hinaharangan ng kill switch ang trapiko habang nagpapalit ng server, ano ang ginagawa ng kliyente sa pagitan, at paano makikilala ang normal na paghinto sa isang stuck na harang.
Pumipili ka ng server na mas malapit ang tingin, pinindot mo ang kumonekta, at huminto ang pag-load ng browser bago pa umangat ang bagong tunnel. Lumilipat ang icon sa kalagayang kumokonekta at nananatili roon habang nauubos ang oras ng bawat tab. Ang paghintong iyon ay karaniwang ang kill switch na gumagana ayon sa disenyo: nahaharang ang trapiko habang walang tunnel ang kliyente na mapagpapadalhan. Kung katanggap-tanggap ang paghinto ay depende sa ginagawa ng kliyente sa mga segundong iyon, at kung tinatanggal ang harang kapag sinabi nitong tinanggal na.
Ano ang ginagawa ng kliyente sa pagitan ng dalawang server
Ang pagpalit ng endpoint ay ilang hakbang, hindi isang switch. Binabagsak ng kliyente ang kasalukuyang tunnel, ina-update ang mga tuntunin nito sa pagharang, nireresolba at naaabot ang bagong endpoint sa labas ng tunnel, pagkatapos ay inilalagay ang mga bagong ruta at inaalis ang harang. Ang puwang na nararamdaman mo ay nasa pagitan ng unang hakbang at ng huli.
Mas mahalaga ang pagkakasunod-sunod kaysa bilis dito. Kung papasok ang mga tuntunin sa pagharang bago ang eksepsiyon para sa bagong endpoint, hindi makukumpleto ng kliyente ang pakikipagkamay at mananatili itong kumokonekta hanggang sa mag-timeout. Kung ang eksepsiyon ay kopya ng address ng lumang server, magmumukhang ordinaryong papalabas na packet ang bagong pakikipagkamay at itatapon. Magkapareho ang itsura ng dalawang kaso mula sa browser, kaya ang pagpalit na nakakabawi pagkatapos ng anim na segundo at ang isang hindi nakakabawi kailanman ay maaaring magbahagi ng parehong dahilan.
Kailangan ng bagong endpoint ng butas sa harang
Para maitayo ang tunnel, kailangang magpadala ang kliyente ng mga packet sa address at port ng bagong server sa pisikal na interface, halimbawa UDP 51820 para sa karaniwang profile ng WireGuard o 1194 at 443 para sa OpenVPN, anuman ang itakda ng sarili mong profile. Wala ang trapikong iyon sa loob ng tunnel na gagawin pa lang, kaya nilulunok ito ng harang para sa buong device maliban kung may tugmang tuntunin ng pahintulot.
Ang mga profile na nakabatay sa hostname ay nagdadagdag ng ikalawang kondisyon: ang paghahanap mismo. Kung niresolba ng kliyente ang endpoint bago umangat ang harang, makakagamit ito ng naka-cache na address, ngunit kapag pinaikot ng profile ang mga address o naluma ang cache entry, pupunta ang pakikipagkamay sa address na hindi saklaw ng tuntunin ng pahintulot. Ginagawang nakikita ito ng IPv6, dahil ang endpoint na may dalawang stack ay makapaglalathala ng parehong record na A at AAAA, at ang tuntunin ng pahintulot na sumasaklaw lamang sa address na v4 ay nag-iiwan sa kliyente na patuloy na sumusubok laban sa harang na address na v6.
Nagkakaiba ang mga pangalan ng opsiyon at default na halaga ayon sa kliyente at bersiyon, kaya basahin ang dokumentadong listahan para sa iyo sa halip na manghula mula sa mga screenshot. Ang sanggunian ng mga setting ng OpenVPN Connect sa openvpn.net/connect-docs/app-settings-windows ay isang halimbawa kung paano inilalarawan ng isang kliyente ang mga opsiyon nito sa pagharang at hati na tunnel.
Ang fail-closed ay isang state machine, hindi switch
Ipinapahayag ng karamihan ng kliyente ang harang bilang patakaran ng firewall sa tatlong kalagayan: tunnel pataas, may trapikong dumadaan sa tunnel at walang harang; tunnel pababa, aktibo ang harang; at transisyon, aktibo ang harang kasama ng pansamantalang eksepsiyon para sa endpoint. Sa ikatlong kalagayan nakatira ang mga bug, dahil kailangan nitong magbago nang dalawang beses sa loob ng ilang segundo, at ang hindi paglabas doon ay mukhang permanenteng harang.
Nagkakaiba ang mekanismo ayon sa platform, at gayundin ang pagkabigo. May timbang ang mga filter ng Windows Filtering Platform, kaya ang filter ng pagharang na lumalampas sa pahintulot mo ay patuloy na nagtatapon ng packet kahit may pahintulot, at mga filter na iniwan ng pinatay na proseso ng kliyente ay maaaring magpanatili sa makina na offline pagkatapos mawala ang app. Ang mga kliyente ng macOS ay karaniwang nagsusulat ng mga tuntunin ng pf sa isang anchor, kung saan ang pagkakasunod-sunod ng tuntunin at mabilis na desisyon ang nagtatakda kung aling tuntunin ang nalalapat. Ang mga kliyente ng Linux ay karaniwang namamahala ng chain ng nftables o iptables na may patakarang drop at malinaw na pahintulot para sa endpoint, interface ng tunnel at loopback. Ang always-on VPN ng Android na may opsiyon na harangin ang mga koneksiyong walang VPN ang pinakamahigpit sa grupo, dahil inilalapat ng operating system ang harang sa buong device at hindi kada app.
Kailangan ng WireGuard ng sariling tala, dahil ang AllowedIPs ay tagapili ng ruta, hindi tagaharang. Ito ang nagtatakda kung aling destinasyon ang papasok sa tunnel; wala itong ginagawa para pigilan ang packet na wala pang tunnel na lumabas sa Wi-Fi. Sa setup na WireGuard lamang at walang tuntunin ng firewall, ang kill switch ay talagang kawalan ng ruta, at pagkatapos ng itinapong pakikipagkamay ay makalalabas ang tunay na packet sa pisikal na interface.
Sukatin ang puwang sa halip na tingnan ang icon
Bantayan ang mga packet, hindi ang ilaw ng kalagayan. Sa Linux magsimula ng mabagal na ping sa pampublikong address sa isang terminal at hulihin ang port ng transportasyon ng tunnel sa pisikal na interface sa isa pa:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Palitan ang server sa kliyente habang tumatakbo ang dalawa. Tatlong bagay ang mahalaga: gaano katagal huminto ang mga ping, kung ipinapakita ng huli na naaabot ng pakikipagkamay ang bagong endpoint, at kung bumabalik ang trapiko bago o pagkatapos maging konektado ang kalagayan ng kliyente. Kung mauuna ang pagtatapos ng puwang sa ping, alinman sa naagang tanggalin ang harang o nakataas na ang tunnel bago pa aminin ng indicator. Kung huli itong matatapos, masyadong optimistiko ang indicator.
Sa Windows, nagsusulat ang netsh wfp show state ng snapshot kung saan maaari mong hanapin ang mga filter ng pagharang na naroon pa rin habang sinasabi ng kliyente na nadiskonekta ito. Sa macOS, inililista ng sudo pfctl -sr ang mga na-load na tuntunin at ang pagkakasunod-sunod nila. Ipares ang alinman sa snapshot sa sariling log ng kliyente; sinasabi ng timeline mula sa iyong ping kung huli natapos ang harang o hindi natapos kailanman.
Normal na dilim laban sa stuck na harang
Ang kaunting pagkaantala ay siyang layunin ng feature, kaya mag-triage bago baguhin ang anumang setting:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Kung mapunta ka sa ikalawa o ikalimang hanay, huwag patayin ang kill switch para magsubok, dahil ginagawa nitong tagas ng bug sa ruta ang nangyayari. I-restart ang serbisyo ng kliyente, o i-reboot ang makina kung saan nakakaligtas ang mga filter sa pagpatay ng proseso, pagkatapos tingnan kung nawawala ang harang. Kung nawawala, ang depekto ay sa paglilinis habang nagpapalit at hindi sa harang mismo.
Bago ang susunod na pagpalit, tiyakin ang apat na bagay: sinasaklaw ng pahintulot ng endpoint ang bawat pamilya ng address na nireresolba ng profile mo, ipinapakita ng log ng kliyente ang natapos na transisyon, sinusukat ng ping test mo ang puwang at hindi ang icon, at ibinabalik ng pagsasara ng kliyente ang normal na koneksiyon. Ang kill switch na humahawak habang nagpapalit at nagpapakawala pagkatapos ay gumagawa ng trabaho nito. Ang nagpapakawala nang maaga, o kailanman, ay dapat i-debug.