Always-on VPN vs kill switch: alin ba talaga ang in-activate mo?

Ang always-on at kill switch ay dalawang linya lang ang layo sa parehong screen ng settings, kaya binabasa sila ng mga tao bilang dalawang pangalan ng isang feature. Hindi sila ganoon. Ang always-on ay patakaran sa muling pagkonekta: simulan ang tunnel sa boot, ibalik ito pagkatapos ng crash o pagbabago ng network, at magpatuloy sa pagsubok habang nabibigo. Ang kill switch ay patakaran sa trapiko: pinangalanan nito ang mga packet na pwede pa ring lumabas ng makina habang down ang tunnel. Pwede mong i-activate ang una nang wala ang pangalawa, at sa karamihan ng platform ang default na resulta ay nagpapalabas pa rin ng trapiko sa agwat na iyon.

Pagsusuri 1: sariling switch ba ang pagharang?

Sa Android 10 at mas bago, ang naka-save na profile ng VPN ay nagbubukas ng dalawang independiyenteng toggle sa likod ng icon ng gear: Always-on VPN at Block connections without VPN. Ang pangalawa lang ang kill switch. Sa always-on lang, bumabalik nga ang tunnel pagkatapos ng pagkahiwalay, at kahit anong app na nasa gitna ng kahilingan ay nakakaabot sa network sa Wi-Fi o mobile data hanggang mangyari iyon.

Pinapanatili ng mga pinamamahalaang device ang parehong pagkakahati sa API ng patakaran. Kinukuha ng setAlwaysOnVpnPackage() ang pangalan ng package at flag na lockdownEnabled; ang administrator na nagtakda ng package at iniwang false ang flag ay gumawa ng permanenteng tunnel, hindi saradong device. Bihirang ipakita ng pananalita sa console ang pagkakaibang iyon.

Basahin ang estado mula sa device, hindi sa console: adb shell settings get global always_on_vpn_app at adb shell settings get global always_on_vpn_lockdown. Kung ang una ay nagbabalik ng null, walang package na ipinatutupad sa antas ng platform; kung ang pangalawa ay nagbabalik ng 0, wala namang hinaharang ang platform. Ang gabay sa VPN ng Android ay inilalarawan ang mga ito bilang magkahiwalay na kakayahan, hindi isang mode.

Pagsusuri 2: aling layer ang may pagharang?

Nasa client ang mga label at kadalasan nasa firewall ang mga pagharang, kaya iba ang ibig sabihin ng parehong salita sa bawat platform. Ang mga hilera sa ibaba ang sulit tiyakin bago paniwalaan ang alinman sa kanila.

Ang Windows ang pinakamalinaw na halimbawa ng label na hindi naghaharang. Doon, inilalarawan ng Always On ang pagiging matibay ng tunnel: tunnel ng device para sa authentication ng makina at tunnel ng user para sa naka-sign in na account, na kinokonfigura sa pamamagitan ng XML ng profile o Add-VpnConnection. Walang anuman sa profile na iyon ang pumipigil sa palabas na packet kapag wala ang tunnel, at ang filtering palabas ay hindi naka-on bilang default, kaya patuloy na gumagana ang laptop sa Wi-Fi habang down ang VPN.

Ganoon din ang pagkakahati ng WireGuard, pero ayon sa client. May opsyon ang WireGuard for Windows na Block untunneled traffic kada tunnel na naglalagay ng mga tuntunin ng filter; wala ang mga tool sa Linux ng katumbas. Nagdaragdag ang wg-quick ng ruta para sa bawat entry na AllowedIPs at tuntunin na fwmark, at inaalis ng wg-quick down ang dalawa, kaya muling pumapasan ang pisikal na default na ruta nang walang nawawalang packet.

Sa mga platform ng Apple, dumarating ang always-on bilang feature ng profile ng pamamahala para sa mga device na sinusubaybayan at ipinapahayag bilang mga tuntunin ng on-demand, hindi bilang checkbox. Ang tanong na dapat sagutin mula sa payload ay kung tinatanggihan ng bigong tunnel ang trapiko o humihingi lang ng ibang koneksyon. Hindi sasabihin iyon ng pamagat ng menu.

Pagsusuri 3: sukatin ang agwat, hindi ang icon

Apat na transisyon ang mahalaga, at iba-iba ang paraan ng pagbigo nila: boot bago mag-log in ang sinuman, pagtulog at paggising, paglipat mula Wi-Fi patungong mobile data, at pag-crash ng client na nag-iiwan sa interface ng tunnel na kalahating naka-configure. Walang pinapatunayan ang malinis na muling pagkonekta sa isa sa kanila tungkol sa tatlo pa.

Ang pinakamurang pagsubok ay sadyang hinihinto ang tunnel at pagkatapos ay sinusubukang lumabas. Habang down ang tunnel, ang curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com na nagbabalik ng 200 ay nangangahulugang fail-open ang patakaran; ang timeout o tinanggihang koneksyon ay nangangahulugang may pumipigil pa. Pinangalanan ng ip route get 1.1.1.1 ang interface na magdadala ng packet, na kadalasan mas may impormasyon kaysa icon sa tray, at ipinapakita ng systemctl status wg-quick@wg0 kung malinis na naalis ang interface.

Patakbuhin ang parehong pagsusuri sa ikalawang window habang nagbabago ang network, hindi lang pagkatapos nitong kumalma. Ang agwat sa pagitan ng pagkahiwalay at ng bagong pagsubok ang mahalaga, at ang paglutas ng pangalan ang pinakamabilis na paraan para mapansin na nakatakas ang trapiko: kung sumasagot ang lokal na resolver habang down ang tunnel, hindi kumpleto ang pagharang.

Pagsusuri 4: pagdesisyunan ang mga eksepsyon bago mag-lock

Dalawang eksepsyon ang estruktural. Kailangang maabot ng client ang mismong server ng VPN, kaya pinipigilan din ng set ng tuntuning nagtatapon ng lahat ang muling pagkonekta na magbabalik ng proteksyon. Hindi rin maaabot ang captive portal sa tunnel na hindi nakataas, kaya ang naka-lock na device sa Wi-Fi ng hotel ay kailangan ng dokumentadong paraan para buksan ang portal, hindi improvised.

Minimal na anyo, pinapayagan ang endpoint at itinatapon ang lahat ng iba pa:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Ituring na variable ang linyang iyon ng endpoint, hindi constant. Nagpapalit ng address ang mga provider, at ang lumang eksepsyon ang karaniwang dahilan kung bakit nagiging device na hindi makakonekta muli ang gumaganang kill switch. Ang mga lokal na printer, share ng NAS at serbisyo sa development ay kabilang sa parehong nakasulat na listahan, kung hindi, isa-isang natutuklasan ang mga ito tuwing support ticket.

Pagsusuri 5: itala ang tunay na napatunayan

Magtago ng talahanayang may apat na kolum at punuin ito sa pamamagitan ng pagsubok: estado, inaasahang pag-uugali, naobserbahang pag-uugali, ebidensya. Ang mga hilera ay ang mga transisyon mula sa pagsusuri 3 at isang sadyang pagbigo. Ang hilerang hindi mo mapupuno ng output ng command ay hilerang hindi mo pa nasusubok, at ang device na pumapasa sa hilerang muling pagkonekta pero bumabagsak sa hilerang boot ay karaniwan na para sulit ang dagdag na sampung minuto.

Bago mo sabihing tapos:

• Tiyakin na hiwalay ang setting ng pagharang sa setting ng muling pagkonekta, at basahin ang halaga nito sa device.
• Alamin kung aling layer ang nagpapatupad ng pagharang - opsyon ng client, patakaran ng device o firewall - at saan kinokonfigura ang layer na iyon.
• Magtago ng isang command sa pagsusuri na nagpapatunay ng pagharang, at patakbuhin ito habang may transisyon, hindi pagkatapos.
• Isulat ang listahan ng eksepsyon, kasama ang endpoint, at itala kung sino ang nagre-refresh nito.
• Sa pinamamahalaang hardware, hayaang mapayapa ang ipinatutupad na patakaran; binabago ng pag-alis ng pagharang ang pangangailangan sa halip na ayusin ang tunnel.