A Mac VPN egyszer kapcsolódik, aztán időtúllépés: tisztítsa meg az IKE-démont

Az újraindítás utáni első kapcsolat működik. Minden további kísérlet a kapcsolódási fázisban akad és végül időtúllépésbe fut, és az egyetlen megbízható gyógymód egy újabb újraindítás. Ez a minta nem profilprobléma és nem hitelesítő adatok problémája. Valami a háttérben még mindig tartja az előző kísérlet állapotát, és a következő kísérlet ütközik vele.

macOS-en ez a valami általában az IKE-démon.

A minta: egy kapcsolódás, aztán időtúllépés

Az a kapcsolat, amely bootonként pontosan egyszer működik, olyan állapotra utal, amely túléli a bontást, de az újraindítást nem. A profilok mindkettőt túlélik, tehát a profil nem a változó. A hitelesítő adatok is túlélik mindkettőt, hacsak a kiszolgáló nem zárja le a fiókot. Ami újraindításkor változik, az a futó démonok halmaza és az általuk tartott socketek.

Ez szűkíti a vizsgálatot, mielőtt egyetlen naplót megnyitna. A kérdés az lesz, melyik folyamat birtokolja az IKE-portot, és mit hisz éppen csinálni.

Két démon, egy port

A rendszer futtatja racoon amikor egy kapcsolat IKE 1-es verziót beszél. A jelenlegi kiadások hozzák a iked IKEv2 és az újabb IPsec-verem számára. Mindkettő lefoglalhatja az UDP 500-at és az UDP 4500-at, és mindkettő megtarthat egy félig nyitott biztonsági társítást, miután egy kapcsolódási kísérletet a jelszókérdésnél megszakítanak vagy egy hálózatváltás félbeszakít.

Amikor ez megtörténik, a következő kísérlet nem tisztán indul. Tárgyalni próbál, miközben a régi társítás még mindig foglalja a partner állapotát, és az egyeztetés megakad ahelyett, hogy világos hibával meghiúsulna. A felhasználó pörgő jelzőt lát, majd időtúllépést.

Keresse meg a tulajdonost, mielőtt bármit megöl, mert a válasz határozza meg, melyik szolgáltatást indítja újra, és melyik naplót olvassa utána.

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

Olvassa a kimenetet két tényként: melyik folyamat tartja a portot, és van-e egynél több jelen. Két IKE-démon, amely ugyanazért a socketért verseng, sok ingadozó viselkedést magyaráz, amely instabil kiszolgálónak látszik.

A feladatot indítsa újra, ne a folyamatot

A régebbi rendszereken elég megölni a folyamatot, és hagyni, hogy a következő kapcsolat újraindítsa. A jelenlegi kiadásokon a démont a launchd kezeli, és ha csak a folyamatnak küld jelzést, a feladat olyan állapotban maradhat, amelyben sem nem fut, sem nincs ütemezve az indulásra. Állítsa le és indítsa el inkább a feladatot.

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

Ha a launchd-nek nincs bejegyzése a feladatról, a folyamat név szerinti megölése akkor is friss tárgyalást kényszerít ki a következő kísérletnél. A teszt mindkét esetben ugyanaz: egyetlen folyamatnak sem szabadna tartania a portot, amikor újra kapcsolódni próbál. Erősítse meg ugyanazzal a paranccsal lsof ahelyett, hogy feltételezné, hogy az újraindítás működött.

Ezután kapcsolódjon egyszer, és olvassa a kliensnaplót az elejétől. Az a tárgyalás, amely túljut az 1. fázison, majd átviteli hibát jelent, a helyi socketproblémát ismétli; a partner által elutasított tárgyalás egészen más jegy.

Amikor a kiszolgáló az, amely elutasít

Nem minden második kapcsolat hibásodik meg helyben. A kiszolgáló egy bontás után rögzített ablakig elutasíthatja az új bejelentkezést, és a kliens időtúllépése pontosan úgy néz ki, mint egy beragadt démoné. A megkülönböztető olcsó: ha a démon újraindítása nem segít, de egy másik fiók azonnal kapcsolódik, az ablak a kiszolgáló oldalán van, és a Mac soha nem volt a probléma.

Az osztott alagút szabályzata ugyanezt a formát hozza létre a másik irányból. Az a kiszolgáló, amely az összes forgalmat az alagútban követeli, a tárgyalás során eldobja az osztott alagútra beállított klienst, és a kliens időtúllépést jelent szabályzatelutasítás helyett. A profil átállítása, hogy minden az alagúton menjen, segíthet a kapcsolódásban, de ez szabályzati döntés, amelyet a hálózat tulajdonosával kell meghozni, nem pedig csendben alkalmazandó javítás.

Olvassa el a partner naplóját, mielőtt újra módosítja a klienst. Az elutasítás, a szabályzat-eltérés és a csendes eldobás három különböző ok, amelyek a Mac képernyőjén mind „kapcsolódás”-nak látszanak.

Régebbi kliensek és a 64 bites kernel

A régi Cisco IPSec kliens egy 32 bites és PowerPC rendszerekre épített kernelkiterjesztést tölt be. A 64 bites kernelbe bootolt Macen ez a kiterjesztés nem tölthető be, és a kliens korán meghiúsul 51-es hibával, mert egyáltalán nem éri el a VPN alrendszert. A démon semmilyen mennyiségű újraindítása nem javít meg egy rossz architektúrájú kernelkiterjesztést.

A kiterjesztés újratöltése működhet egy ideig, majd a következő bootnál újra meghiúsulhat. A tartós válaszok: a régebbi kernelt futtatni ott, ahol még támogatott, vagy áttérni a rendszerrel érkező beépített kliensre. Ellenőrizze az architektúrát, mielőtt egy estét egy harmadik féltől származó, be nem tölthető kliensre szán.

• Reprodukálja egyszer, majd a profil megérintése előtt ellenőrizze, melyik démon birtokolja az UDP 500-at.
• Olvassa el az első hibát az 1. fázis után: az átviteli hiba a helyi socketre mutat.
• Indítsa újra a launchd feladatot, ne csak a folyamatot, és erősítse meg, hogy a port szabad.
• Próbáljon ki egy második fiókot, hogy elválassza a kiszolgáló oldali újrahitelesítési ablakot a kliens hibájától.
• Jegyezze fel a kernel architektúráját, mielőtt a klienst okolja.

Az a VPN, amely pontosan egyszer működik, állapotprobléma, amíg az ellenkezője be nem bizonyosodik. A démon tisztítása gyorsabb az újraindításnál, és megőrzi azokat a naplóbizonyítékokat, amelyeket egy újraindítás eldobott volna.