VPN sa Mac na nakabitin sa «Nagdidiskonekta»: ano ang tunay na tumatakbo

Ang «Nagdidiskonekta» ay isang estado na iniuulat ng kliyente habang binubuwag nito ang isang tunnel, hindi hatol na tumigil na ang trapiko. Sa Mac, ang pagbuwag na iyon ay tumatakbo bilang maikling pagkakasunod-sunod, at nagbabago lamang ang label pagkatapos mag-ulat pabalik ng bahaging may-ari ng koneksyon. Kapag may isang hakbang na naghihintay sa isang helper, plugin o desisyon sa patakaran, maaaring manatili ang label pagkatapos mawala ang interface, o maaaring magpatuloy ang tunnel sa pagpapasa habang ipinapakita pa ito ng menu. Ituring ang teksto na «pagtanggal na nagaganap, resulta ay hindi alam» at alamin kung aling kalahati ang totoo.

Dalawang pagkabigo ang magkatulad tingnan mula sa menu bar at nangangailangan ng magkasalungat na tugon. Sa isa, nagdadala pa ng packet ang tunnel at ang display lamang ang luma. Sa isa pa, wala na ang tunnel ngunit may hiwalay na patakaran na nagpapanatili sa trapiko na naka-block, na kadalasan ay sinasadya. Ang mga ruta at estado ng DNS ang naghihiwalay sa kanila nang mas mabilis kaysa anumang galaw sa menu.

Ano ang sinusundan ng label

Ang kliyente ng VPN ay may maliit na state machine, at ang menu bar ay projection nito. Para sa koneksyong pinamamahalaan ng macOS mismo, ang machine ay nasa framework ng VPN ng system. Para sa tunnel na pinamamahalaan ng app, ito ay nasa app at sa privileged helper nito. Ang huling hakbang ng paghinto ay hindi pagsasara ng socket. Ito ay pagpapakawala ng gumawa sa tunnel na gumana: ang interface ng utun, ang mga rutang tumuturo rito, ang mga entry ng resolver na inilagay ng kliyente, at anumang tuntunin ng firewall o patakarang humadlang sa trapiko habang konektado.

Ang mga hakbang na iyon ay hiwalay, kaya ang paghinto ay maaaring mabitin sa alinman sa kanila. Ang helper na tumigil sumagot, isang rutang inaangkin din ng pangalawang interface, o entry ng resolver na pag-aari ng ibang profile ay maaaring magpaiwan sa kliyente na naghihintay. Ang label ay ulat tungkol sa sariling pag-unlad ng kliyente, na ginagawa itong may awtoridad sa layunin at hindi mapagkakatiwalaan sa network.

Hanapin ang bahaging may-ari ng koneksyon

Sa mga native na configuration, ipinapakita ng scutil --nc list ang mga serbisyong alam ng system at ang estado nila, at ang scutil --nc status "Work VPN" ay nagbibigay ng detalye ng isang serbisyo. Ang tunnel na hawak ng app ng ikatlong partido ay maaaring hindi lumitaw sa listahang iyon, kaya ang walang laman na resulta ay hindi patunay na walang konektado.

Kapag ang profile ay pag-aari ng isang app, umasa sa view ng estado nito at sa dokumentadong kontrol na «Idiskonekta». Ang pagsasara ng window ay hindi kahilingan sa paghinto kung may helper sa background na may-ari ng tunnel; nawawala ang icon at pinapanatili ng helper na buhay ang interface. Ang sanggunian ng mga setting ng VPN ng Apple ay sumasaklaw sa mga native na kontrol at sa pinagmulan ng mga pinamamahalaang setting.

Basahin ang mga interface, ruta at DNS

Tatlong pagsusuri ang sumasagot sa malaking bahagi ng tanong nang hindi hinahawakan ang koneksyon. Ang mahalaga ay ang pagbigkas sa kanila nang sama-sama, dahil ang bawat isa nang mag-isa ay nakapanlilinlang.

scutil --nc list
netstat -rn -f inet | head -20
ifconfig | grep -A 3 '^utun'
scutil --dns | head -30

• may interface ng utun, may rutang default o hating dumadaan dito, tumuturo ang resolver sa provider: buhay pa ang tunnel at luma na ang label.
• walang utun, ordinaryong rutang default, DNS mula sa DHCP, walang internet: isang patakarang humahadlang kapag nadiskonekta ang gumagawa ng trabaho nito.
• walang utun, walang ruta, tumuturo pa rin ang resolver sa provider: tumigil sa kalagitnaan ang pagbuwag, at ang DNS ang natirang kailangang linisin.

Pagkatapos ay magpadala ng isang kahilingan sa panloob na host na dapat lamang sumagot sa pamamagitan ng tunnel at isa sa pampublikong host. Ang maabot ay naghihiwalay sa patakaran mula sa natirang estado nang hindi ginagawang pagsasanay sa pagsukat ang pagsusuri. I-save muna ang malayuang trabaho kung tumutugon pa ang landas, at maghanda ng ikalawang daan papasok bago baguhin ang network sa makinang pinamamahalaan mo mula sa malayo.

Bakit nakapanlilinlang ang malawakang pagpatay at pagbura ng profile

Ang mga pangalan ng proseso tulad ng pppd, racoon at configd ay pag-aari ng partikular na implementasyon. Ang pagpatay sa kanila ay maaaring makaapekto sa ibang koneksyon, nag-iiwan ng mga ruta at interface ng utun, at wala itong ibinibigay na tala kung aling hakbang ang nabitin. Kahit lumang pangalan ng proseso ay hindi patunay na ito ang may-ari ng kasalukuyang profile.

Ang pagbura at muling paglikha ng profile ay mas malaking pagbabago kaysa paglilinis ng nabiting transisyon. Maaari nitong itapon ang mga pinamamahalaang setting at lokal na materyal ng pagkakakilanlan nang hindi ipinapaliwanag kung ano ang nabigo, at sa Mac na may pangangasiwa ay maaaring ibalik lamang ito. Itabi ang pagbubura para sa configuration na talagang laos na at i-diagnose ang transisyon sa halip.

Isang pagkakasunod-sunod ng paghinto na nag-iiwan ng bakas

Iniiwan ng kaayusan sa ibaba ang mga kontrol ng koneksyon mismo bilang responsable at gumagawa ng tala kung babalik ang pagbibit. Pinipigilan ka rin nitong gawing pagbabago sa network ang problema sa display.

1. I-save ang malayuang trabaho, at tiyakin na maaabot mo ang Mac sa ibang paraan kung ito ay malayo.
2. Itala ang pangalan ng kliyente, bersyon at profile. Kunan ng maikling window gamit ang log show --last 5m --predicate 'subsystem == "com.apple.networkextension"'; mas kaunting kasaysayan ang itinatago ng lumang release, kaya patakbuhin ito kaagad pagkatapos ng pagbibit.
3. Gamitin ang dokumentadong kontrol na «Idiskonekta», maghintay, pagkatapos ay ulitin ang mga pagsusuri sa interface at ruta.
4. Kung luma na ang label ngunit nakababa ang tunnel, hayaan ito at hayaang mag-refresh ang kliyente sa halip na pilitin ang mga proseso.
5. Kung talagang nabitin ang pagbuwag, i-restart ang kliyente, pagkatapos ay planuhin ang pag-restart ng Mac kapag na-save na ang trabaho. Ang mga pinamamahalaang makina ay nangangailangan ng pamamaraan ng administrator.

Pagkatapos ng pagbangon, tiyakin na bumalik ang ordinaryong rutang default at resolver ng DHCP, at ang na-block na trapiko ay naibalik o sadyang naka-block pa rin. Itala ang profile at bersyon ng kliyente kasama ang sintomas, upang ang susunod na pangyayari ay magsimula sa ebidensya at hindi sa haka-haka mula sa menu bar.