Paano subukan ang kill switch ng VPN nang walang totoong account
Gumawa ng pagsubok sa kill switch gamit ang panlinlang na pahina at ekstrang profile: saklawin ang bawat uri ng pagkaantala, basahin ang exit code ng curl at paghiwalayin ang tunay na harang sa sira ng DNS.
Hindi mo kailangan ng totoong account para malaman kung makapit ang kill switch; ang account mismo ang inilalagay sa panganib ng pagsubok. Gumagawa ang pagsusuri ng maikling sandali kung kailan maaaring lumabas o hindi ang trapiko sa labas ng tunnel, kaya dapat ang kargada ay isang bagay na kaya mong mawala. Ginagawa ko ito ngayon gamit ang panlinlang na pahina at ekstrang profile ng browser, at mas malinaw ang sagot kaysa sa dating gawain na browser at webmail. Sa ibaba, sinusundan ko ang parehong pagkakasunod-sunod na ipinapakita ng kliyente: ang setting, ang patutunguhan, ang paglipat, at pagkatapos ang ebidensiya.
Isang makipot na tanong lang ang sinasagot ng pagsubok: sa paglipat na ito, kayang maabot ng application na ito ang network sa labas ng tunnel? wala itong sinasabi kung makatuwiran ba ang natitirang patakaran. Panatilihing ganoon kamakitid ang saklaw at sulit nang isulat ang resulta.
Hanapin ang switch at ang saklaw nito sa kliyente
Buksan ang kliyente at hanapin ang setting ng pagharang bago mo baguhin ang anumang estado ng network. Iba-iba ang tawag ng mga vendor: kill switch, lockdown mode, network lock, harangin ang trapiko sa labas ng tunnel. Mas kaunti ang sinasabi ng label kaysa sa mga opsiyon sa loob nito. Ang mahalaga ay kung palaging umiiral ang pagharang o kapag nagpasya lang ang app na kababagsak pa lang ng tunnel, at kung sakop nito ang lahat ng application o isang piling listahan.
Pagkatapos, ilista ang mga paglipat na kayang gawin ng kliyente mo. Ang pagputol na sinimulan ng gumagamit, ang paglabas sa app at ang pagkawala ng ugnayan sa server ay tatlong magkaibang landas ng code sa karamihan ng kliyente, at hindi sila nagbabahagi ng isang patakaran sa pagharang. May nag-aalis ng harang kapag lumabas ang app. May nag-iiwan ng mga tuntunin ng filter hanggang may mag-alis. Basahin ang sanggunian ng setting ng vendor para sa build na ginagamit mo sa halip na maghaka-haka, at isulat kung alin sa tatlo ang sinusubukan mo.
Itala rin ang profile: protocol, mga pamilya ng address at kung nakabukas ang split tunnelling. Walang saysay ang pag-aangkin na sakop ang buong device kung sadyang hindi kasama ng profile ang ilang application, at ang pagbubukod na ikaw mismo ang nagtakda ay hindi pagtagas. Ang sanggunian ng setting ng OpenVPN Connect ay ang uri ng pahina na nagsasabi kung aling switch ang nagbabago ng aling pag-uugali, kahit magkaiba ang mga label sa bawat kliyente.
Pumili ng panlinlang na patutunguhan na gumagana rin nang walang tunnel
Kailangan ng panlinlang ng dalawang katangian, at ang paglaktaw sa alinman ay nagdudulot ng resultang hindi mabasa. Dapat itong maabot nang direkta kapag nakababa ang tunnel at patay ang harang, kung hindi, ang pagtigil nito sa pagsagot ay maaaring nangangahulugan lang na nawala ang host. At hindi ito dapat mangailangan ng login, cookie o bayad, para ang isang pagtagas ay isang linya lang ng log at hindi isang session.
Ang isang static na pahina sa host na kontrolado mo ang pinakamalinis na pagpipilian. Halos kasinghusay ang ekstrang virtual machine na may ordinaryong HTTP server, at gumagana rin ang pampublikong pahina ng pagsusuri ng koneksiyon kung tatanggapin mong wala sa kontrol mo ang pagiging available nito. Itala ang address, port, pamilya ng address at kung kailangan ng paghahanap ng pangalan, dahil bawat isa sa mga ito ay nagiging variable na maaaring kailangan mong ihiwalay mamaya.
Itatag ang baseline bago hawakan ang switch. Kapag nakataas ang tunnel, dapat sumagot ang panlinlang sa pamamagitan ng tunnel, na nagpapatunay na gumagana ang rutang ayon sa patakaran. Kapag nakababa ang tunnel at patay ang harang, dapat itong sumagot nang direkta, na nagpapatunay na buhay ang patutunguhan. Doon lang may masasabi sa iyo ang pagkabigo sa harang na estado.
Isagawa ang mga paglipat sa takdang pagkakasunod-sunod
Isaisahin ang mga paglipat at bigyan ang bawat isa ng ilang segundo upang kumalma, dahil madalas gibain at itayo muli ng mga kliyente ang mga tuntunin sa agwat na iyon. Ang parehong maikling pagsusuri sa bawat pagkakataon ang nagpapaging maihahambing ang mga obserbasyon:
curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"| Transition | Expected with the block on | Failure signature |
|---|---|---|
| Manual disconnect | Decoy stops answering within seconds | Decoy still returns 200 |
| Server or path failure | Blocked, with no exemption for the old endpoint | Direct access during the gap |
| Quit the app | Client-dependent; record what happens | Block disappears with the process |
| Wi-Fi to Ethernet | Block holds until the tunnel returns | Traffic flows mid-change |
Ang hanay ng paglabas sa app ay dapat hiwalay na patakbuhin kahit hindi mo kailanman isinasara ang kliyente sa normal na gamit. Kung lumuluwag ang harang sa paglabas, ang pag-crash o sapilitang update ay nagbibigay ng parehong pagkakalantad, at iyon ay katotohanan tungkol sa deployment, hindi tungkol sa iyong pasensiya. Sa Windows, ang katumbas na probes ay Resolve-DnsName decoy.example at curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.
Ihiwalay ang harang sa sirang resolver
Maraming dahilan ang pahinang hindi naglo-load, at isa lang sa mga ito ang gumaganang switch. Kung hindi naresolba ang pangalan, nalaman mong naka-harang o sira ang DNS, hindi na naka-harang ang landas ng data. Subukan din ang literal na address, para hindi na umaasa ang sagot sa resolusyon.
Pinaghihiwalay ng exit code ng curl ang mga kasong iyon. 6 ay pagkabigo sa resolusyon ng pangalan, 7 ay nangangahulugang tinanggihan ang koneksiyon, 28 ay timeout. Ang naka-harang na ruta ay karaniwang lumalabas bilang timeout o pagtanggi sa literal na address, samantalang ang harang sa DNS lang ay nag-iiwan ng 6 at nagtatago ng lahat ng iba. Ang naka-cache na pahina o captive portal ay nanlilinlang sa mata, kaya ang exit code, hindi ang screen, ang ebidensiya.
Ulitin ang probe sa IPv6 gamit ang literal na address. Ang harang na sumasaklaw sa IPv4 at binabalewala ang IPv6 ay karaniwan nang sapat upang magkaroon ng sariling linya sa iyong mga tala, at ang kliyenteng nagpapatay ng IPv6 sa labas ng tunnel ay dapat malinis na mabigo sa dalawang pamilya.
Itala ang saklaw na sinasakop ng resulta
Kapag bumalik ang tunnel, kumpirmahin ang pagbangon: sumasagot ang panlinlang sa pamamagitan ng tunnel, nagbabalik ng sagot ang resolver, at naroon pa rin ang patakaran kung saan mo ito iniwan. Pagkatapos, ibalik ang mga eksperimento. Ang pansamantalang tuntunin ng firewall, rutang debug o profile ng pagsubok na naiwan ay magugulo ang susunod na pagtakbo at maaaring mabuhay pa nang mas matagal kaysa sa app.
Ang isang pagdaan ay sumasaklaw sa isang build ng kliyente, isang profile, isang paglipat at isang pamilya ng address. Isulat ang apat na iyon kasama ang kinalabasan:
- Build ng kliyente at platform, at kung per profile o global ang setting.
- Profile, protocol at anumang pagbubukod sa split tunnel.
- Paglipat na sinubukan at paano mo ito pinukaw.
- Mga pamilya ng address at DNS, kasama ang exit code ng curl para sa harang at di-harang na estado.
Kung may blangkong linya, hindi pa tapos ang pagsubok. Ang roaming ay nangangahulugang ulitin ang hanay ng pagbabago ng network. Ang hindi binabantayang restart ay nangangahulugang suriin kung bumabalik ang mga tuntunin, at iyon ay tanong tungkol sa pagkakasunod-sunod ng pagbangon, hindi sa switch. Ulitin ang sekwens pagkatapos ng update ng kliyente, dahil bihirang magbago ang mga switch samantalang nagbabago ang pag-uugali sa likod nila. Itago ang panlinlang: walang kailangang paikutin, at ang susunod na pagsusuri ay tumatagal ng limang minuto.