Vi instalas la duan klienton por kompari ĝin, kaj la unua ĉesas funkcii. Nenio estis forigita, kaj ambaŭ aplikaĵoj estas ankoraŭ instalitaj. Kio ŝanĝiĝis troviĝas sub ili: sistema etendaĵo, DNS-agordo aŭ defaŭlta itinero, kaj la du klientoj nun malkonsentas pri tio, kiu posedas ĝin. La instalado ne estas la riska parto; la riska parto estas funkciigi ambaŭ sen registrita bazlinio, al kiu vi povas reveni.

La simptomo: la funkcianta agordo ĉesas post la dua instalado

Modernaj macOS VPN-klientoj ofte venas kun reta etendaĵo anstataŭ malnova interfaco. Instalado de unu povas peti aprobon, aldoni agordan profilon aŭ registri sisteman etendaĵon, kiu influas trafikon antaŭ ol ajna konekto estas farita. La etendaĵo ŝarĝiĝas antaŭ ol la fenestro de la aplikaĵo aperas, kaj tial la origina kliento povas malsukcesi dum la nova restas senokupa.

Se poste la origina kliento ne povas konektiĝi, aŭ konektiĝas kaj solvas nenion, la nova etendaĵo estas la unua suspektato. Tio ne estas pruvo de konflikto, sed ĝi estas la loko, kie la esploro komenciĝas. Poste kontrolu la liston de etendaĵoj kaj la instalitajn agordajn profilojn, ne nur la dosierujon de aplikaĵoj.

Notu la bazlinion antaŭ ol instali ion ajn

Skribu, kio nun funkcias: la rezulto de la aplikaĵo, la versio de la kliento, la finpunkto al kiu ĝi konektiĝas, kaj ĉiujn esceptojn por unuopa aplikaĵo aŭ por dividita tunelo. Konservu la originan profilon per la protektita procezo, kiun la kliento subtenas, ne per kopiado de dosieroj el aplikaĵa pakaĵo.

scutil --dns | head -40
netstat -rn | head -30
ifconfig | grep -E "^(utun|ipsec)"

Kaptu tiujn tri eligojn dum la funkcianta kliento estas konektita. Ili donas al vi la staton de la solvilo, la itineran tabelon kaj la interfacan liston, kiujn produktas funkcianta agordo, kaj tio estas ĝuste tio, kion vi bezonas por posta komparo. Se la Mac estas administrata de dunganto, konfirmu antaŭ ol komenci, ke la komparo estas permesita, ĉar aŭtomata laborkonekto povas reaktiviĝi dum vi testas kaj la rezulto tiam reprezentas neniun el la du klientoj sole. Konservu la tri eligojn apud la profila noto, por ke la posta komparo havu referencon.

Ŝanĝu unu aktivan vojon samtempe

Haltigu la originan konekton per ĝia normala regilo, poste startigu la alternativon. Du konektitaj klientoj samtempe produktas rezulton, kiu priskribas la kombinaĵon, ne iun el la produktoj. Tenu la finpunkton kaj la taskon kompareblaj, se la servoj permesas tion, ĉar pli rapida elŝuto per alia servilo komparas du konektajn elektojn, ne du aplikaĵojn.

Se la nova kliento malsukcesas, konservu ĝian unuan eraron antaŭ ol ŝanĝi ion alian. La unua eraro kutime nomas la stadion, kaj dua provo post agorda ŝanĝo ofte raportas ion malpli utilan.

Komparu DNS, itinerojn kaj la aplikaĵon, ne nur rapidon

Rulu la samajn tri komandojn kun la nova kliento konektita kaj komparu ilin linio post linio. Solvilo, kiu montras aliloken, aŭ itinera tabelo sen la privata subreto klarigas la plej multajn diferencojn en konduto antaŭ ol vi rigardas la trafluon. Poste testu la realan aplikaĵon per la sama tasko, ĉar kliento, kiu konektiĝas rapide kaj malsukcesas solvi internan nomon, ne gajnis la komparon eĉ se la stata fenestro aspektas pli bone.

Notu, kiun interfacon la trafiko uzis. Sur macOS la nomo de la tunela interfaco ne estas fidinda indiko pri tio, kiu kliento posedas la itineron, do parigu la interfacan liston kun la itinera tabelo anstataŭ legi nur unu el ili. Se ekzistas du utun-interfacoj, tiu, kiu portas vian trafikon, estas tiu kun kongrua itinero kaj solvila enskribo. Diveni laŭ la nomo estas kiel la malĝusta interfaco estas kulpigata, ĉar la interfaco, kiu ekzistas, ne ĉiam estas tiu, kiu portas trafikon.

Legu la tri eligojn anstataŭ foliumi ilin. En la solvila eligo, noma servilo ligita al utun-interfaco montras, kiu kliento instalas ĝin; en la itinera tabelo, la defaŭlta itinero nomas la interfacon, kiu portas trafikon; en la interfaca listo, dua utun-aparato signifas, ke dua tunelo estis kreita. Tiuj tri linioj, kompare kun la bazlinio, apartigas restarigitan agordon de tiu, kie ambaŭ klientoj ankoraŭ konkurencas.

Restarigu, poste forigu purigite

Revenu per la propra laborfluo de la origina kliento kaj konfirmu, ke la bazliniaj eligoj kongruas kun tio, kion vi notis. Se la solvilo aŭ la itinera tabelo ne restariĝas, haltu kaj riparu tion antaŭ ol forigi ion alian. Forigu la neuzatan agordon per la komponento, kiu posedas ĝin: la malinstalilo de la kliento, la profilo aŭ la agordoj de la sistema etendaĵo.

Finu ĝisdatigante viajn notojn per la versio, kiun vi testis, la finpunkto, kiun vi uzis, kaj la rezulto por ĉiu. Ses monatojn poste tiu registro estas la diferenco inter decido kaj onidiro.

Rilataj artikoloj