Mac VPN ŝtopiĝas ĉe «Malkonektado»: kio efektive funkcias

«Malkonektado» estas stato, kiun la kliento raportas dum ĝi malkonstruas tunelon, ne verdikto ke la trafiko haltis. En Mac tiu malkonstruo okazas kiel mallonga sinsekvo, kaj la etikedo ŝanĝiĝas nur post kiam la komponanto, kiu posedas la konekton, raportas reen. Kiam unu paŝo atendas helpanton, kromaĵon aŭ politikan decidon, la etikedo povas resti tie post kiam la interfaco foriris, aŭ la tunelo povas daŭre plusendi dum la menuo ankoraŭ montras ĝin. Traktu la tekston kiel «malkonstruo en progreso, rezulto nekonata» kaj eltrovu, kiu duono veras.

Du paneoj aspektas identaj el la menuobreto kaj postulas malajn respondojn. En unu la tunelo ankoraŭ portas pakaĵojn kaj nur la montrado estas kaduka. En la alia la tunelo foriris sed aparta politiko tenas la trafikon blokita, kio ofte estas intenca. Itineraj kaj DNS-stato apartigas ilin pli rapide ol iu ajn menuinterago.

Kion la etikedo spuras

VPN-kliento tenas malgrandan statmaŝinon, kaj la menuobreto estas ĝia projekcio. Por konekto administrata de macOS mem, tiu maŝino sidas en la sistema VPN-kadro. Por aplikaĵ-administrata tunelo, ĝi sidas en la aplikaĵo kaj ĝia privilegia helpanto. La lasta paŝo de halto ne estas fermi ingon. Ĝi estas liberigi tion, kio igis la tunelon funkcii: la utun-interfacon, la itinerajn kiuj montris al ĝi, la solvantajn enskribojn kiujn la kliento enmetis, kaj ĉiun fajroŝirman regulon aŭ politikon kiu blokis trafikon dum la konekto estis viva.

Tiuj paŝoj estas apartaj, do halto povas ŝtopiĝi ĉe iu ajn el ili. Helpanto kiu ĉesas respondi, itinerajo kiun ankaŭ dua interfaco postulas, aŭ solvanta enskribo kiun posedas alia profilo povas lasi la klienton atendi. La etikedo estas raporto pri la propra progreso de la kliento, kio igas ĝin aŭtoritata pri la intenco kaj nefidinda pri la reto.

Trovu la komponanton kiu posedas la konekton

Por denaskaj agordoj, scutil --nc list presas la servojn kiujn la sistemo konas kaj ilian staton, kaj scutil --nc status "Work VPN" donas detalojn por unu servo. Tunelo tenata de triaparta aplikaĵo eble tute ne aperos en tiu listo, do malplena rezulto ne estas pruvo ke nenio estas konektita.

Kiam la profilo apartenas al aplikaĵo, fidu ĝian statvidon kaj ĝian dokumentitan regilon «Malkonekti». Fermi la fenestron ne estas haltpeto se fona helpanto posedas la tunelon; la piktogramo malaperas kaj la helpanto tenas la interfacon viva. La referenco pri VPN-agordoj de Apple kovras la denaskajn regilojn kaj de kie venas administrataj agordoj.

Legu interfacojn, itinerajn kaj DNS

Tri kontroloj respondas la plejparton de la demando sen tuŝi la konekton. Gravas interpreti ilin kune, ĉar ĉiu sola misgvidas.

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

• utun-interfaco ĉeestas, defaŭlta aŭ dividita itinerajo tra ĝi, solvanto montras al la provizanto: la tunelo ankoraŭ staras kaj la etikedo estas kaduka.
• neniu utun, ordinara defaŭlta itinerajo, DNS el DHCP, neniu interreto: politiko kiu blokas post malkonekto faras sian laboron.
• neniu utun, neniu itinerajo, solvanto ankoraŭ montras al la provizanto: la malkonstruo haltis duonvoje, kaj DNS estas la restaĵo purigenda.

Poste sendu unu peton al interna gastiganto kiu devus respondi nur tra la tunelo kaj unu al publika gastiganto. Atingebleco apartigas politikon de restanta stato sen igi la kontrolon mezura ekzerco. Konservu unue malproksiman laboron se la vojo ankoraŭ respondas, kaj aranĝu duan eniron antaŭ ol ŝanĝi retajn agordojn sur maŝino kiun vi administras malproksime.

Kial amasa mortigo kaj profilforigo misgvidas

Procezaj nomoj kiel pppd, racoon kaj configd apartenas al certaj realigoj. Mortigi ilin povas influi aliajn konektojn, lasas itinerajn kaj utun-interfacojn malantaŭe, kaj donas al vi neniun registron pri tio, kiu paŝo ŝtopiĝis. Malnova proceza nomo ankaŭ ne estas pruvo ke ĝi posedas la nunan profilon.

Forigi kaj rekreigi la profilon estas pli granda ŝanĝo ol purigi ŝtopiĝintan transiron. Ĝi povas forĵeti administratajn agordojn kaj lokan identecan materialon sen klarigi kio malsukcesis, kaj sur prizorgata Mac ĝi eble simple restariĝos. Konservu forigon por agordo kiu vere kadukiĝis kaj anstataŭe diagnozu la transiron.

Haltsekvenco kiu lasas spuron

La suba ordo lasas la proprajn regilojn de la konekto respondecaj kaj produktas registron se la ŝtopiĝo revenos. Ĝi ankaŭ gardas vin kontraŭ igi montran problemon reta ŝanĝo.

1. Konservu malproksiman laboron, kaj konfirmu ke vi povas atingi la Mac alimaniere se ĝi estas malproksima.
2. Notu la nomon de la kliento, la version kaj la profilon. Kaptu mallongan fenestron per log show --last 5m --predicate 'subsystem == "com.apple.networkextension"'; pli malnovaj eldonoj tenas malpli da historio, do rulu ĝin baldaŭ post la ŝtopiĝo.
3. Uzu la dokumentitan regilon «Malkonekti», atendu, kaj poste ripetu la kontrolojn de interfaco kaj itineraj.
4. Se la etikedo estas kaduka sed la tunelo estas sube, lasu ĝin kaj lasu la klienton refreŝiĝi anstataŭ devigi procezojn.
5. Se la malkonstruo vere ŝtopiĝis, restartigu la klienton, kaj poste planu restartigon de la Mac post kiam laboro estas konservita. Administrataj maŝinoj bezonas la proceduron de la administranto.

Post reakiro, konfirmu ke la ordinara defaŭlta itinerajo kaj la DHCP-solvanto revenis, kaj ke blokita trafiko aŭ restariĝis aŭ ankoraŭ estas intence blokita. Notu la profilon kaj la klientan version kune kun la simptomo, por ke la sekva okazo komenciĝu de pruvoj anstataŭ de konjekto el la menuobreto.