Miért csatlakozik az Android az otthoni IPsec VPN-hez, a Windows pedig nem
A telefon csatlakozik, a laptop nem, és nem a jelszó a probléma. A router olyan IKEv1 XAUTH profilt kínál, amelyet a Windows soha nem adott ki.
A telefon panasz nélkül belép a router VPN-jébe, míg az ugyanazon a Wi-Fi-n lévő laptop nem tud. Ugyanazok a belépési adatok, ugyanaz a szerver, ugyanaz a perc. A különbség a protokolltámogatás, nem a jelszó: a router olyan profilt tesz elérhetővé, amelyet az egyik operációs rendszer megvalósít, a másik pedig soha nem ismert.
Először azonosítsa a profilt, majd hasonlítsa össze azzal, amit az egyes kliensek valóban beszélnek.
Egy menü, három protokoll
Egyetlen IPsec címsor alatt a fogyasztói firmware három teljesen különböző alagutat rejthet. Az első az IKEv1 XAUTH-sal: közös csoporttitok, felette felhasználónév és jelszó. A második a L2TP/IPsec, ahol a PPP egy közös kulccsal védett IPsec-szállítás belsejében fut. A harmadik az IKEv2, amelyet tanúsítványokkal vagy EAP-val hitelesítenek.
A mezőket olvassa, ne a címkét. Csoporttitok és felhasználói lista IKEv1 XAUTH-ot jelent. Előre megosztott kulcs és PPP-fiók L2TP/IPsec-et jelent. Szervertanúsítvány csoporttitok nélkül IKEv2-t jelent.
A támogatási szakadék a telefon és a laptop között
Az Android beépített IKEv1 XAUTH PSK klienst hoz, és éppen ezért sikerül a telefonnak egy olyan routerrel szemben, amely semmi mást nem kínál. A Windows nem: natív kliense az L2TP/IPsec-et és az IKEv2-t kezeli, és nincs bekapcsolható IKEv1 XAUTH opció. A titok újrabillentyűzése nem segít, mert a hiányzó rész a protokoll, nem a belépési adat.
Az Apple oldala mozgó célpont. Az újabb macOS- és iOS-verziók az IKEv2 felé tartanak, a régi Cisco stílusú profilok egyes buildekben túlélnek, és egy frissítés eltávolíthatja vagy szigoríthatja azt, ami múlt hónapban működött. Egy Mac, amely tegnap csatlakozott és ma nem, a router változtatása nélkül, általában ez.
Két beállítás, amely elrontja az egyébként helyes profilokat
A Synology L2TP/IPsec oldala egy Enable SHA2-256 compatible mode (96 bit) feliratú jelölőnégyzetet kínál. Az Apple kliensei az iOS 14-től és a macOS Big Sur-tól kezdve elutasítják ezt a csonkolt módot, ezért számukra a négyzetet ki kell kapcsolni. Ha bekapcsolva marad, az alagút hitelesít, majd leesik, ami rossz belépési adatoknak látszik, de nem az. A gyártó dokumentálja a kapcsolót, és az operációs rendszer frissítése az a pillanat, amikor ez elkezd számítani.
A Windows két külön tárolóban tartja a tanúsítványokat, és az IKEv2 csak a gépit olvassa. Importálja az ügyféltanúsítványt a privát kulcsával együtt a számítógépfiókba; a saját felhasználói fiókja alatt tárolt tanúsítvány megjelenik a felügyeleti konzolon, de soha nem éri el az IKEv2 szolgáltatást. Az EAP-TLS az egyetlen eset, amikor a felhasználói tanúsítvány használható, és az aláíró CA-nak továbbra is megbízhatónak kell lennie a gép számára. Az itt elkövetett hiba hitelesítési hibaként jelenik meg, nem hiányzó tanúsítvány kéréseként.
Amikor a router úgy marad, ahogy van
Az a router, amely csak XAUTH PSK-t beszél, három utat hagy: a gyártó kliense, egy harmadik fél kliense, amely még megvalósítja a profilt, vagy az alagút végpontjának áthelyezése valamire, ami IKEv2-t beszél. Az AVM például Windows kliensszoftvert és exportált konfigurációs fájlt tesz közzé a routereihez. Ez az út támogatott, és azt jelenti, hogy minden laptopra telepíteni kell a gyártó eszközét.
A támogatás többet számít, mint az elegancia, amikor a laptopok nem a magáéi, hogy újraépítse őket.
Mérje fel a biztonsági költséget is. Egy csoporttitok minden felhasználót lefed, így aki birtokolja, az a szerver helyébe léphet, és elfoghatja a felhasználónevet és a jelszót, amelyet a kliens kínál. Ahol az IKEv2 tanúsítványokkal elérhető, ott ez a migráció többet ér bármilyen kliensoldali kerülőútnál.
Kívülről befelé diagnosztizáljon
Először szerezzen egy működő munkamenetet a telefontól, hogy a szerveroldal bizonyított legyen, mielőtt a laptop képbe kerül. Aztán importálja a router exportált profilját változtatás nélkül, és a router állapotoldala helyett a kliens naplóját olvassa. Ha a napló nem mutat kimenő ajánlatot, a laptop soha nem érte el a válaszadót. Ha az ajánlatok kicserélődnek, majd meghiúsulnak, a nézeteltérés az algoritmusokról, az identitásról vagy a belépési adatokról szól.
Tartsa meg a működő telefonprofilt kontrollként. Amikor egy firmware-frissítés után csak a laptop romlik el, a szerveroldal úgy viselkedik, mint korábban. Amikor mindkettő elromlik, nézze meg a tanúsítványt vagy a figyelőt, mielőtt bármelyik klienshez nyúlna.