Mac VPN pieslēdzas vienu reizi, tad beidzas laiks: notīriet IKE dēmonu

Pirmā savienojuma pēc pārstartēšanas darbojas. Katrs nākamais mēģinājums iestrēgst savienošanās posmā un beidzot beidzas ar taimautu, un vienīgais uzticamais līdzeklis ir vēl viena pārstartēšana. Šis modelis nav profila problēma un nav arī akreditācijas datu problēma. Kaut kas fonā joprojām tur iepriekšējā mēģinājuma stāvokli, un nākamais mēģinājums ar to saduras.

Sistēmā macOS šis kaut kas parasti ir IKE dēmons.

Modelis: viens savienojums, tad taimauts

Savienojums, kas darbojas tieši vienu reizi katrā palaišanā, norāda uz stāvokli, kas pārdzīvo atvienošanu, bet ne pārstartēšanu. Profili pārdzīvo abus, tāpēc profils nav mainīgais. Akreditācijas dati arī pārdzīvo abus, ja vien serveris nebloķē kontu. Pārstartēšanas laikā mainās darbojošos dēmonu kopa un to turētās ligzdas.

Tas sašaurina izmeklēšanu pirms jebkura žurnāla atvēršanas. Jautājums kļūst, kurš process pārvalda IKE portu un ko tas domā, ka dara.

Divi dēmoni, viens ports

Sistēma palaiž racoon kad savienojums runā IKE 1. versijā. Pašreizējie laidieni arī atnes iked IKEv2 un jaunākajai IPsec kaudzei. Abi var aizņemt UDP 500 un UDP 4500, un abi var noturēt pusatvērtu drošības asociāciju pēc tam, kad savienojuma mēģinājums tiek atcelts paroles uzvednē vai pārtraukts ar tīkla maiņu.

Kad tas notiek, nākamais mēģinājums nesākas tīri. Tas mēģina pārrunāt, kamēr vecā asociācija vēl aizņem partnera stāvokli, un apmaiņa apstājas, tā vietā lai neizdotos ar skaidru kļūdu. Lietotājs redz rotējošu indikatoru, tad taimautu.

Atrodiet īpašnieku pirms kaut ko nogalināt, jo atbilde nosaka, kuru pakalpojumu restartēsiet un kuru žurnālu lasīsiet tālāk.

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

Lasiet izvadi kā divus faktus: kurš process tur portu, un vai ir vairāk nekā viens. Divi IKE dēmoni, kas konkurē par vienu un to pašu ligzdu, izskaidro daudz neregulāras uzvedības, kas izskatās kā nestabils serveris.

Restartējiet uzdevumu, nevis procesu

Vecākās sistēmās pietiek nogalināt procesu un ļaut nākamajam savienojumam to palaist. Pašreizējos laidienos dēmonu pārvalda launchd, un signāls tikai procesam var atstāt uzdevumu stāvoklī, kurā tas ne darbojas, ne ir ieplānots startēt. Tā vietā apturiet un palaidiet uzdevumu.

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

Ja launchd nav uzdevuma ieraksta, procesa nogalināšana pēc nosaukuma tomēr piespiež jaunas pārrunas nākamajā mēģinājumā. Tests abos gadījumos ir viens: nevienam procesam nevajadzētu turēt portu, kad mēģināt pieslēgties vēlreiz. Apstipriniet to ar to pašu komandu lsof tā vietā, lai pieņemtu, ka pārstartēšana nostrādāja.

Tad pieslēdzieties vienu reizi un lasiet klienta žurnālu no sākuma. Pārrunas, kas pāriet 1. fāzei un pēc tam ziņo par pārraides kļūdu, atkārto vietējo ligzdas problēmu; partnera noraidītas pārrunas ir pavisam cita biļete.

Kad atteicas pats serveris

Ne katrs otrais savienojums neizdodas lokāli. Serveris var atteikt jaunu pieteikšanos noteiktu logu pēc atvienošanas, un klienta taimauts izskatās identiski kā iestrēdzis dēmons. Atšķirējs ir lēts: ja dēmona restartēšana nepalīdz, bet cits konts pieslēdzas uzreiz, logs ir servera pusē un Mac nekad nav bijis problēma.

Sadales tuneļa politika rada tādu pašu formu no otras puses. Serveris, kas pieprasa visu satiksmi tunelī, pārrunu laikā izmetīs klientu, kas konfigurēts sadalītajam tunelim, un klients ziņos par taimautu, nevis politikas noraidījumu. Profila maiņa, lai viss ietu pa tuneli, var likt tam pieslēgties, bet tas ir politikas lēmums, kas jāpieņem kopā ar tīkla īpašnieku, nevis klusi piemērojams remonts.

Lasiet partnera žurnālu pirms klienta maiņas vēlreiz. Noraidījums, politikas neatbilstība un klusa nomešana ir trīs dažādi iemesli, kas Mac ekrānā visi izskatās kā „pieslēdzas“.

Vecāki klienti un 64 bitu kodols

Vecais Cisco IPSec klients ielādē kodola paplašinājumu, kas būvēts 32 bitu un PowerPC sistēmām. Mac, kas palaists ar 64 bitu kodolu, šo paplašinājumu nevar ielādēt, un klients agri neizdodas ar 51. kļūdu, jo vispār nesasniedz VPN apakšsistēmu. Nekāds dēmona restartēšanas daudzums neizlabo kodola paplašinājumu ar nepareizu arhitektūru.

Paplašinājuma pārlāde var kādu laiku darboties un tad atkal neizdoties nākamajā palaišanā. Izturīgās atbildes ir palaist vecāko kodolu tur, kur tas vēl tiek atbalstīts, vai pāriet uz iebūvēto klientu, kas nāk kopā ar sistēmu. Pārbaudiet arhitektūru pirms vakara pavadīšanas ar trešās puses klientu, kas neielādējas.

• Reproducējiet vienu reizi, tad pirms profila aizskaršanas pārbaudiet, kurš dēmons pārvalda UDP 500.
• Lasiet pirmo neizdošanos pēc 1. fāzes: pārraides kļūda norāda uz vietējo ligzdu.
• Restartējiet launchd uzdevumu, ne tikai procesu, un apstipriniet, ka ports ir brīvs.
• Izmēģiniet otru kontu, lai atdalītu servera puses atkārtotas autentifikācijas logu no klienta kļūmes.
• Pierakstiet kodola arhitektūru pirms klienta vainošanas.

VPN, kas darbojas tieši vienu reizi, ir stāvokļa problēma, līdz tiek pierādīts pretējais. Dēmona notīrīšana ir ātrāka par pārstartēšanu, un tā saglabā žurnāla pierādījumus, ko pārstartēšana būtu izmetusi.