Proč se Android připojí k domácí IPsec VPN a Windows ne

Telefon se do VPN routeru přihlásí bez potíží, zatímco laptop na stejné Wi-Fi ne. Stejné přihlašovací údaje, stejný server, stejná minuta. Rozdíl je v podpoře protokolu, ne v heslu: router nabízí profil, který jeden operační systém implementuje a druhý nikdy neměl.

Nejprve profil identifikujte, pak jej porovnejte s tím, co každý klient skutečně umí.

Jedna nabídka, tři protokoly

Pod jednou hlavičkou IPsec může spotřebitelský firmware skrývat tři zcela různé tunely. První je IKEv1 s XAUTH: sdílené skupinové tajemství a nad ním uživatelské jméno a heslo. Druhý je L2TP/IPsec, kde PPP běží uvnitř transportu IPsec chráněného sdíleným klíčem. Třetí je IKEv2, ověřovaný certifikáty nebo EAP.

Čtěte pole, ne označení. Skupinové tajemství a seznam uživatelů znamená IKEv1 XAUTH. Předsdílený klíč a účet PPP znamená L2TP/IPsec. Serverový certifikát bez skupinového tajemství znamená IKEv2.

Mezera v podpoře mezi telefonem a laptopem

Android má vestavěného klienta IKEv1 XAUTH PSK, a právě proto telefon uspěje u routeru, který nenabízí nic jiného. Windows ne: jeho nativní klient zvládá L2TP/IPsec a IKEv2 a žádnou volbu IKEv1 XAUTH nemá. Znovu zadat tajemství nepomůže, protože chybí protokol, ne údaj.

Strana Apple je pohyblivý cíl. Novější verze macOS a iOS tíhnou k IKEv2, staré profily ve stylu Cisco přežívají v některých sestaveních a aktualizace může odebrat nebo zpřísnit to, co minulý měsíc fungovalo. Mac, který se včera připojil a dnes ne, bez změny routeru, je obvykle tohle.

Dvě nastavení, která rozbíjejí jinak správné profily

Stránka L2TP/IPsec v Synology nabízí zaškrtávací pole Enable SHA2-256 compatible mode (96 bit). Klienti Apple od iOS 14 a macOS Big Sur tento zkrácený režim odmítají, takže pole musí být pro ně vypnuté. Pokud zůstane zapnuté, tunel se ověří a potom spadne, což vypadá jako špatné údaje a není. Výrobce přepínač dokumentuje a aktualizace operačního systému je obvykle okamžik, kdy to začne vadit.

Windows drží certifikáty ve dvou oddělených úložištích a IKEv2 čte jen to strojové. Importujte klientský certifikát s privátním klíčem do účtu počítače; certifikát uložený pod vaším uživatelským účtem se v konzoli zobrazí, ale ke službě IKEv2 se nikdy nedostane. EAP-TLS je jediný případ, kdy je uživatelský certifikát použitelný, a podepisující CA přesto musí být strojem důvěryhodná. Chyba se projeví jako selhání ověření, ne jako výzva k chybějícímu certifikátu.

Když router zůstane, jak je

Router, který umí jen XAUTH PSK, nechává tři cesty: klientský software výrobce, klientský software třetí strany, který profil stále implementuje, nebo přesun koncového bodu tunelu na něco, co umí IKEv2. Třeba AVM vydává Windows klienta a exportovaný konfigurační soubor pro své routery. Tato cesta je podporovaná a znamená instalovat nástroj výrobce na každý laptop.

Podpora je důležitější než elegance, když laptopy nejsou vaše na přestavbu.

Zvažte i cenu bezpečnosti. Jedno skupinové tajemství pokrývá všechny uživatele, takže kdokoli je má, může se vydávat za server a zachytit jméno a heslo, které klient nabízí. Kde je dostupné IKEv2 s certifikáty, tam má tato migrace větší cenu než kterékoli obejití na klientu.

Diagnostikujte zvenčí dovnitř

Nejprve získejte jednu funkční relaci z telefonu, aby byla strana serveru prokázaná dřív, než přijde laptop. Pak importujte exportovaný profil routeru beze změn a čtěte klientský log místo stavové stránky routeru. Pokud log neukazuje odchozí nabídku, laptop se k responderu vůbec nedostal. Pokud se nabídky vymění a pak selžou, neshoda je v algoritmech, identitě nebo údajích.

Držte funkční profil telefonu jako kontrolu. Když se po aktualizaci firmwaru rozbije jen laptop, strana serveru se chová jako dřív. Když se rozbijí oba, podívejte se na certifikát nebo listener, než sáhnete na kterýkoli klient.