Dalawang VPN app nang sabay: aling kill switch ang talagang nalalapat?
Hindi kailanman namamana ng pangalawang VPN client ang kill switch ng una. Tatlong kondisyon ang nagtatakda kung aling patakaran ang nalalapat, at paano i-verify ang sa iyo.
Maaaring magkasabay na tumakbo ang dalawang VPN client, ngunit hindi nagsasama ang kanilang kill switch sa isang patakaran. Bawat client ay naglalagay ng mga patakaran para sa sarili nitong tunnel, at wala sa kanila ang nakakaalam na mayroon ang isa. Naranasan ko ito sa isang work client na nauna nang nakakonekta: hindi natapos ng pangalawang app ang handshake nito, nanatili ito sa „Connecting“ nang sampung minuto, at tahimik na dinala ng unang tunnel ang lahat. Kung mapoprotektahan ang pangalawang app ay nakasalalay sa tatlong kondisyon, hindi sa kung parehong ikon ay nagsasabing Nakakonekta.
Ano ba talaga ang saklaw ng isang kill switch
Wala ni isang kill switch flag sa operating system. Ang client na nag-aanunsyo ng isa ay naglalagay ng isang set ng mga patakaran: itapon ang lahat ng hindi lumalabas sa aking tunnel, at madalas fail closed kapag nawala ang tunnel. Sa Linux ito ay karaniwang nftables o iptables chain, sa Windows isang set ng Windows Filtering Platform filter, sa Android at iOS ang sariling routing ng tunnel service kasama ang system setting na humaharang sa mga koneksyon na walang VPN. Inilalarawan ng Android VPN guide ang modelong iyon ng serbisyo kung gusto mo ang pananaw ng platform.
Ang saklaw ang bahaging mahalaga. Ang patakarang tulad ng „payagan lamang ang mga packet sa output interface wg0“ ay walang pakialam kung may pangalawang tunnel. Kung ang ibang client ay magtaas ng wg1, ituturing ng mga patakaran ng unang client ang mga packet na iyon bilang ordinaryong trapiko: kadalasang itinatapon, paminsan-minsang pinapayagan. Alinman sa dalawa, ang unang client ang nagpapasya, at wala siyang ideya na may pangalawang app na naghihintay.
Tatlong kondisyon na nagtatakda kung sino ang saklaw
Hindi mo kailangang isa-isahin ang bawat kombinasyon. Tatlong tanong ang nagtatapos nito sa ilang minuto.
- Pinapayagan ba ng platform ang pangalawang tunnel? Karamihan ng Android phone at iPhone ay tumatanggap lamang ng isang aktibong VPN service bawat user profile, kaya ang pangalawang app ay walang tunnel at walang naipapatupad. Makakakuha ka ng isang patakaran, mula sa app na nanalo sa puwesto.
- Aling proseso ang may-ari ng default route? Windows, macOS at Linux ay buong galak na nagdadala ng dalawang tunnel. Ang default route ay pag-aari ng client na huling nag-configure nito o may mas magandang metric, at ang isa pang client ay nakakonekta ngunit walang ginagawa. Sa Linux, ang default-route mode ng wg-quick ay gumagamit ng policy routing na may pribadong table at fwmark rule, kaya ang pangalawang wg-quick tunnel ay nagdaragdag ng karibal na patakaran sa halip na palitan ang una.
- Naaabot ba ng pangalawang client ang sarili nitong server? Kung ang unang kill switch ay default-deny, ang panlabas na endpoint ng pangalawang app ay isa lamang itinatapong destinasyon. Tahimik itong nagretry at hindi kailanman nag-uulat ng error.
Ang maikling bersyon, para sa mga support thread:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
Dalawang sa mga linyang iyon ay magkapareho ang hitsura mula sa ikon sa system tray, at iyon ang dahilan kung bakit ang ikon ang pinakamasamang ebidensiya na makukuha dito.
Ano ang unang nabibigo, at paano ito nagmumukha
Ang client na stuck sa „Connecting“ habang malusog ang isa ay halos palaging gutom sa endpoint: itinatapon ng tumatakbong kill switch ang handshake ng pangalawang client patungo sa sarili nitong server. Kumpirmahin ito nang mura sa pamamagitan ng pag-pause ng mga block rule ng unang client sa isang pagtatangka. Kung agad na kumonekta ang pangalawa, nasagot na ang tanong.
Ang DNS ang pangalawang pagkabigo. Nagtatakda ang mga client ng resolver configuration para sa sarili nilang interface, at ang ilan ay basta na lamang nagsusulat sa global na listahan. Kapag parehong nakataas ang tunnel, maaaring lumabas ang mga query sa isang panig habang ang resolver ay pag-aari ng kabila. Idiskonekta ang alinmang app at ang natitira ay may hindi maabot na nameserver: humihinto ang mga pahina nang isang minuto at pagkatapos ay nagre-resolve muli, habang ang VPN ay nagpapakita pa ring nakakonekta.
Ang pangatlo ay route flapping. Iniaayos muli ng mga reconnect ang default route, at ang kill switch na nakatali sa interface ay hindi ito sinusundan. Ang trapikong nasa loob ng tunnel ilang sandal ang nakalipas ay tumutugma na ngayon sa isang drop rule, na sa panig ng user ay nababasa bilang VPN na biglang tumigil sa paggana.
I-verify kung aling patakaran ang talagang umiiral
Gawin ito gamit ang hindi mapanganib na trapiko, hindi sa isang bagay na mami-miss mo.
Sa Linux, tanungin ang kernel kung sino ang panalo at saan nakakabit ang firewall. Binabanggit ng ip -4 route show default ang tunnel na may-ari ng labasan. Ipinapakita ng ip rule show kung kasali ang policy routing. Ipinapakita ng sudo nft list ruleset | grep -n oifname kung ang mga drop ay nakakabit sa pangalan ng interface, sa mark, o sa buong output chain.
Sa Windows, ang parehong kuwento ay nasa route metric at filter list: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric at Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". Sa macOS, netstat -rn -f inet | head -5 at scutil --dns | head -20.
Pagkatapos ay gawin ang hakbang na nilalaktawan ng mga tao: sadyang ihinto ang tunnel at kumpirmahin na ang trapikong inaasahan mong mabibigo ay talagang nabibigo. Ang nakakonektang ikon ay estado ng interface, hindi pagpapatupad.
Kailan mali ang disenyo ng dalawang client
Kung ang tanging kinakailangan sa likod ng pangalawang app ay mas maraming proteksyon, alisin ito. Ang dalawang patakarang humaharang na nag-uugnayan ay hindi gaanong mahuhulaan kaysa sa isa, at bawat reconnect ay pagkakataong mapunta sa estadong wala ni isang vendor ang sumusubok.
Kung talagang kailangan mo ng chaining, tulad ng corporate gateway na naaabot sa pamamagitan ng commercial hop, pumili ng disenyong may isang enforcement point. Karaniwang nangangahulugan ito ng router o isang client na sumusuporta sa chain, hindi dalawang desktop app na nag-uunahan sa parehong default route. Sa isang managed device, panatilihin ang awtorisadong client at ituring ang lahat ng iba ay wala sa saklaw, anuman ang ipakita nito sa tray.
Checklist bago mo panatilihin ang dalawa
Sundin ang listahan sa ayos; ang unang item na mabibigo ang dapat ayusin.
- Kumpirmahin na eksaktong isang client ang may-ari ng default route at ng resolver.
- Kung gusto mong nakataas ang pangalawang client, hayagang payagan ang endpoint ng server nito at muling suriin pagkatapos ng bawat update ng client.
- Isulat ang inaasahang resulta kapag bumagsak ang alinmang tunnel, at subukan ang partikular na kaso iyon.
- Suriin ang daan ng pagkabigo pagkatapos ng reboot, kapag iba ang pagkakasunod-sunod ng pagsisimula.
- Sa managed profile, huminto at tanungin ang may-ari bago magdagdag ng anuman.
Kung mabibigo ang ikatlong hakbang, ang tapat na sagot ay isang client lamang ang nagbibigay sa iyo ng patakaran. Magpasya kung alin ang pinagkakatiwalaan mo at hayaang umalis ang isa.