Mac VPN konektiĝas unufoje, poste tempolimas: purigu la IKE-demonon

La unua konekto post relanĉo funkcias. Ĉiu provo poste haltas en la konekta fazo kaj finfine tempolimas, kaj la sola fidinda kuracilo estas alia relanĉo. Tiu ŝablono ne estas profila problemo kaj ne estas problemo de akreditaĵoj. Io en la fono ankoraŭ tenas la staton de la antaŭa provo, kaj la sekva provo kolizias kun ĝi.

En macOS tiu io kutime estas la IKE-demono.

La ŝablono: konekto unufoje, poste tempolimo

Konekto kiu funkcias ekzakte unufoje po lanĉo montras al stato kiu postvivas malkonekton sed ne relanĉon. Profiloj postvivas ambaŭ, do la profilo ne estas la variablo. Akreditaĵoj ankaŭ postvivas ambaŭ, se la servilo ne ŝlosas la konton. Kio ŝanĝiĝas ĉe relanĉo estas la aro de rulantaj demonoj kaj la ingoj kiujn ili tenas.

Tio mallarĝigas la esploradon antaŭ ol vi malfermas eĉ unu protokolon. La demando fariĝas kiu procezo regas la IKE-pordon kaj kion ĝi pensas ke ĝi faras.

Du demonoj, unu pordo

La sistemo rulas racoon kiam konekto parolas IKE-version 1. Nunaj eldonoj ankaŭ alportas iked por IKEv2 kaj la pli nova IPsec-stako. Ambaŭ povas ligi UDP 500 kaj UDP 4500, kaj ambaŭ povas teni duonmalfermitan sekurecan asocion post kiam konekta provo estas nuligita ĉe la pasvorta prompto aŭ interrompita de reta ŝanĝo.

Kiam tio okazas, la sekva provo ne komenciĝas pure. Ĝi provas negocadi dum la malnova asocio ankoraŭ okupas la staton de la kunulo, kaj la interŝanĝo haltas anstataŭ malsukcesi kun klara eraro. La uzanto vidas turniĝantan indikilon, poste tempolimon.

Trovu la posedanton antaŭ ol mortigi ion ajn, ĉar la respondo determinas kiun servon vi restartigas kaj kiun protokolon vi legos poste.

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

Legu la eligon kiel du faktojn: kiu procezo tenas la pordon, kaj ĉu ĉeestas pli ol unu el ili. Du IKE-demono konkurencantaj por la sama ingo klarigas multan intermitan konduton kiu aspektas kiel malstabila servilo.

Restartigu la taskon anstataŭ la procezon

En pli malnovaj sistemoj sufiĉas mortigi la procezon kaj lasi la sekvan konekton restartigi ĝin. En nunaj eldonoj la demonon administras launchd, kaj signali nur la procezon povas lasi la taskon en stato kie ĝi nek rulas nek estas planita por komenciĝi. Haltigu kaj komencu la taskon anstataŭe.

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

Se launchd ne havas registraĵon pri la tasko, mortigi la procezon laŭ nomo ankoraŭ devigas freŝan negocadon ĉe la sekva provo. La testo estas la sama en ambaŭ kazoj: neniu procezo devus teni la pordon kiam vi provas konektiĝi denove. Konfirmu tion per la sama komando lsof anstataŭ supozi ke la restartigo funkciis.

Poste konektiĝu unufoje kaj legu la klientan protokolon de la komenco. Negocado kiu pasas preter fazo 1 kaj poste raportas send-eraron ripetas la lokan ingan problemon; negocado malakceptita de la kunulo estas tute alia bileto.

Kiam la servilo estas tiu kiu malakceptas

Ne ĉiu dua konekto malsukcesas loke. Servilo povas malakcepti novan ensaluton dum fiksa fenestro post malkonekto, kaj la tempolimo de la kliento aspektas idente al ŝtopiĝinta demono. La distingilo estas malmultekosta: se restartigi la demonon ne helpas sed alia konto konektiĝas tuj, la fenestro estas ĉe la servila flanko kaj la Mac neniam estis la problemo.

Politiko de dividita tunelo produktas la saman formon el la alia direkto. Servilo kiu postulas la tutan trafikon en la tunelo forĵetos klienton agorditan por dividita tunelo dum la negocado, kaj la kliento raportas tempolimon anstataŭ politikan malakcepton. Ŝanĝi la profilon por sendi ĉion tra la tunelo povas igi ĝin konektiĝi, sed tio estas politika decido farota kun la retposedanto, ne riparo aplikota silente.

Legu la protokolon de la kunulo antaŭ ol ŝanĝi la klienton denove. Malakcepto, politika malkongruo kaj silenta forĵeto estas tri malsamaj kaŭzoj kiuj ĉiuj aspektas kiel “konektado” sur la ekrano de la Mac.

Pli malnovaj klientoj kaj la 64-bita kerno

La malnova Cisco IPSec-kliento ŝargas kernan etendaĵon konstruita por 32-bitaj kaj PowerPC-sistemoj. Sur Mac lanĉita en la 64-bita kerno, tiu etendaĵo ne povas ŝargiĝi, kaj la kliento frue malsukcesas kun eraro 51 ĉar ĝi tute ne atingas la VPN-subsistemon. Neniu kvanto da demona restartigo riparas kernan etendaĵon kun la malĝusta arkitekturo.

Reŝargi la etendaĵon povas funkcii dum tempo kaj poste denove malsukcesi ĉe la sekva lanĉo. La daŭraj respondoj estas ruli la pli malnovan kernon kie tio ankoraŭ subteniĝas, aŭ transiri al la enkonstruita kliento kiu venas kun la sistemo. Kontrolu la arkitekturon antaŭ ol pasigi vesperon kun triaparta kliento kiu ne povas ŝargiĝi.

• Riproduktu unufoje, poste kontrolu kiu demono regas UDP 500 antaŭ ol tuŝi la profilon.
• Legu la unuan malsukceson post fazo 1: send-eraro montras al la loka ingo.
• Restartigu la launchd-taskon, ne nur la procezon, kaj konfirmu ke la pordo estas libera.
• Provu duan konton por apartigi servilan reaŭtentigan fenestron de klienta difekto.
• Notu la kernan arkitekturon antaŭ ol kulpigi la klienton.

VPN kiu funkcias ekzakte unufoje estas stata problemo ĝis pruvite alie. Purigi la demonon estas pli rapide ol relanĉi, kaj ĝi konservas la protokolajn pruvojn kiujn relanĉo estus forĵetinta.