Hinaharangan ng kill switch ang server ng VPN bago dumaloy ang anumang trapiko
Aling yugto ang hinaharangan ng kill switch: paghahanap ng endpoint, panlabas na ruta, daan pabalik at mga lipas nang pagbubukod ng peer — may mga counter sa halip na hula.
Nabibigo ang mga kill switch sa direksyong hindi inaasahan ng mga tao: ginawa sila para harangin ang trapiko habang nakababa ang tunnel, at ang mga packet na bumubuo ng tunnel ay trapiko rin. Iyon ang buong bug. Ang set ng patakaran na nagtatapon ng lahat ng hindi lumalabas sa tunnel ay nagtatapon din ng handshake na dapat magpataas nito, kaya inuulit ng kliyente sa loop at ang error ay itinatakda sa yugtong unang sinusuri. Bago palawakin ang firewall, alamin kung alin sa tatlong yugto ang tinatanggihan: ang paghahanap ng pangalan, ang panlabas na packet patungo sa peer, o ang sagot na bumabalik.
Paano nagtutulungan ang tunnel at ang sarili nitong transport
Basahin ang kliyente ng VPN bilang dalawang estado ng network na nagbabahagi ng isang daan ng socket. Bago umiral ang tunnel, nagbubukas ang kliyente ng socket sa pisikal na adapter at nagpapadala ng naka-encrypt na frame sa address at port ng peer. Pagkatapos lamang ng tagumpay ng palitang iyon ay gumagawa ito ng aparato ng tunnel at naglalagay ng ruta. Ang kill switch ay patakaran tungkol sa pangalawang estado, isinulat nang napakalawak kaya nalalapat sa dalawa.
Ang mga patakarang nakabatay sa interface ang karaniwang anyo: tanggapin ang lumalabas sa tun0 o wg0, itapon ang natitirang daan palabas. Hindi kayang ibukod ng pormulasyong iyon ang sariling koneksyon ng kliyente sa server, kaya idinadagdag ng tamang implementasyon ang pagbubukod na iyon nang tahasan, at gayon din kayo kapag nagsusulat ng patakaran sa kamay. Ang mga patakaran per aplikasyon sa Windows at macOS ay umiiwas sa bahagi nito sa pamamagitan ng pagtutugma ng proseso sa halip na interface, ngunit kailangan pa ring lumabas ng proseso bago umiral ang tunnel.
Tatlong yugto, sa ayos ng pangyayari
Ang unang yugto ay resolusyon. Kapag nag-iimbak ang profile ng hostname sa halip na literal na address, kailangan ng kliyente ng sagot ng DNS bago makapagpadala ng anuman. Ang profile na nagtuturo ng DNS sa resolver ng tunnel ay gumagawa ng deadlock: maaabot lamang ang resolver sa pamamagitan ng tunnel na dapat buksan ng paghahanap. Ang paglutas sa labas ng tunnel, o pagpako ng endpoint sa isang address, ay nag-aalis ng kalabuan.
Ang ikalawang yugto ay ang panlabas na packet, na dapat munang makalampas sa routing at pagkatapos sa firewall, sa ayos na iyon. Ang wireguard-tools ang humahawak sa kalahati ng routing nito para sa WireGuard sa pamamagitan ng pagmamarka ng sarili nitong packet at pagdaragdag ng patakaran na laktawan ang default na ruta na kaaayos lang nito; ang manual page ng wg-quick ay naglalarawan ng patakarang iyon at ng talahanayang ginagamit nito. Itayo muli ang routing na iyon sa kamay, o hayaang isang pangalawang tool ang magsulat muli ng patakaran, at ang mga markadong packet ay maaaring ibalik sa tunnel na dapat nilang itayo.
Ang ikatlong yugto ay ang daan pabalik. Ang handshake na walang sagot ay hindi patunay ng pagtatapon sa labas; pareho rin itong tugma sa panlabas na patakaran ng server o aparatong NAT na nakalimot sa mapping. Ihiwalay ang mga iyon bago hawakan ang kliyente.
| 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 |
Itinatala ng mga kliyente ang sintomas na natuklasan nila, hindi ang yugtong nabigo, kaya karaniwang mas mabilis ang talahanayan kaysa log.
Mas mabilis magpasya ang mga counter kaysa log
Sa Linux, nft list ruleset o iptables -vnL OUTPUT naglilimbag ng counter ng packet bawat patakaran. Kumonekta nang isang beses, hayaang mabigo, pagkatapos basahin muli ang mga counter. Ang patakarang gumalaw ang counter ay ang patakarang tinamaan ng handshake; kung walang gumalaw kahit saan, hindi naabot ng packet ang firewall. May nakita akong set ng patakaran na nagtapon ng sarili nitong handshake, at ang mga counter lang ang nagsabi.
Para ihiwalay ang hindi naabot ang firewall mula sa hindi umalis sa host, obserbahan ang interface mismo. ip -s link show dev wlan0 ay nag-uulat ng mga naipadalang packet, at tcpdump -ni wlan0 udp port 51820 ay nagpapakita ng mga frame. Kung mananatili itong patag habang nag-uulit ang kliyente, ang depekto ay nasa itaas ng netfilter: kulang na ruta ng peer, patakarang tumuturo sa aparatong wala pa, o error ng socket na nilulunok ng kliyente.
Subukan ang mga pagbubukod sa mga address ng dokumentasyon tulad ng 203.0.113.10, upang hindi masuri ng pagkakamali ang host ng iba.
Ang lipas nang pagbubukod ng endpoint ay binabasa na parang pagbagsak ng server
Ang pinakapanlinlang na bersyon ay lumilitaw pagkatapos magbago ang address ng peer: inilipat ito ng serbisyo ng dinamikong address, itinayo muli ang host, o iba ang address ng labas ng inyong network. Pinangalanan pa rin ng pagbubukod ang lumang address, kaya ang mga packet patungo sa bago ay tumatama sa patakaran ng pagtatapon. Gumana ang parehong konfigurasyon kahapon, at iyon ang dahilan kung bakit nagsisimula ang mga tao sa pag-diagnose ng server.
Ang hostname sa loob ng patakaran ng firewall ay hindi kayo maililigtas. Sa nftables, nilulutas ang pangalan kapag nag-load ang set ng patakaran, kaya ipinapako nito ang address na umiral sa sandaling iyon at naluluma tulad ng literal na address. Ang pangmatagalang lunas ay i-update ang pagbubukod kapag nagbago ang endpoint at panatilihin itong makitid: isang address ng peer, isang port ng transport. Ang saklaw na sapat ang lapad upang makayanan ang pagbabago ng address ay sapat din ang lapad upang makalabas ang walang kaugnayang trapiko.
Kapag tumatakbo ang kill switch sa host ng server
Ang parehong pag-asa ay umiiral sa kabilang dulo, at doon mas madaling makaligtaan. Kung ang makina na nagsisilbing server ng VPN ninyo ay nagpapatakbo rin ng desktop client na may kill switch, o profile ng firewall na kinopya mula sa laptop, nalalapat ang mga patakaran ng pagtatapon nito sa serbisyong nagtatapos ng tunnel. Itinatapon ang mga sagot sa handshake ng kliyente, kaya nabibigong kumonekta ang bawat kliyente habang mukhang malusog ang server at walang gamit ang interface ng tunnel nito.
Kailangan ng host na iyon ng tatlong makitid na pagtanggap bago ang pagtatapon: ang port ng pakikinig sa pisikal na interface, ang interface ng tunnel para sa na-decrypt na trapiko, at pagpapasa mula sa tunnel patungo sa dapat maabot ng mga kliyente. Basahin ang naka-install na set gamit ang nft list ruleset, iptables -S, o pfctl -sr bago baguhin ang anuman, at tandaan na ang naka-save na set ng patakaran ay nakakalampas sa reboot, kaya ang pagkakamali doon ay nabubuhay nang mas matagal kaysa sa prosesong gumawa nito.
Pagkakasunod-sunod ng pagbangon na nagpapanatiling sarado ang makina
Magtrabaho mula sa profile palabas. Basahin ang address at port ng peer na ginagamit ng kliyente, tiyakin na nalulutas ang hostname nang walang tunnel, pagkatapos ay magdagdag ng isang pagbubukod para sa address at port na iyon sa pisikal na adapter lamang. Kumonekta muli at obserbahan ang counter ng pagpapadala; ang kumpletong handshake ay ang hudyat na naayos ang ikalawang yugto.
Iwanan ang natitirang patakaran ng pagtatapon sa puwesto habang nagsubok. Ang walang pinsalang pagsusuri ay subukang kumonekta sa walang kaugnayang address ng dokumentasyon at tiyakin na nag-eexpire pa rin ito, na nagpapakita na gumagana ang kill switch at hindi ito patay. Higpitan ang pagbubukod kapag matatag na ang tunnel, at huwag mag-iwan ng permanenteng pagpayag sa lahat para sa binary ng kliyente dahil lang komportable.
Kung aangat ang tunnel at nabibigo pa rin ang aplikasyon, ang natitirang yugto ay hindi ito: ang split DNS, MTU at routing per aplikasyon ay bawat isa ay gumagawa ng konektadong tunnel na may sirang trapiko, at bawat isa ay may ibang unang pagsusuri.