MSCHAPv2 není VPN protokol: nejdřív se ptejte na tunel
Heslo a slovo MSCHAPv2 ještě nedělají spojení. Zeptejte se, který tunel výměnu nese, a potom k němu přizpůsobte profil klienta.
Uživatelská jména a hesla cestují uvnitř nosiče a MSCHAPv2 pojmenovává jen metodu, která cestuje. Než vyberete profil klienta, zeptejte se, který tunel to nese, protože stejný řetězec účtu se objevuje v uspořádáních, která nesdílejí ani řádek kódu. Každý profil, který dostanete, kóduje obě rozhodnutí, i když instruktážní list tiskne jen jedno z nich. Pořadí níže je to, na co operátor umí odpovědět bez hádání a co vy můžete ověřit bez zachytávání paketů.
Autentizace jede uvnitř tunelu
VPN dělá dvě rozhodnutí, která vypadají jako jedno: jak strany postaví chráněný kanál a jak v něm člověk prokáže totožnost. Druhé je vytištěné na instruktážním listu, protože ho zadává člověk. První rozhoduje, zda bude vůbec nějaký klient fungovat, a právě to lidé přeskakují. Požádejte operátora, aby nejprve pojmenoval nosič a potom metodu, v tomto pořadí. Dvě spojení mohou vyžadovat stejné jméno účtu i stejné heslo, a přitom pod přihlašovacím polem nesdílet žádnou implementaci.
Proto nastavení zkopírovaná z kolegova fungujícího telefonu mohou na vašem selhat, i když server přijímá oba přihlašovací údaje. Rozdílem nikdy nebyl údaj; byl jím profil, který ho obaluje. obě strany mají pravdu a nic se nepřipojí bývá právě tenhle zmatek a zmizí, jakmile se nosič pojmenuje.
Tři místa, kde se stejná metoda objevuje
V PPP autentizační krok čeká, dokud nevznikne spojení, a RFC 2759 definuje MS-CHAPv2 jako tento krok, proto se metoda objevuje v L2TP a ve starších nasazeních PPTP. Tunel se ukončuje první a PPP vyjednávání probíhá uvnitř něj, takže neúspěšná fáze PPP může v logu serveru nechat tunel vypadat jako navázaný. Čtěte ty dvě fáze odděleně, než usoudíte, že byly přihlašovací údaje odmítnuty. Klient nastavený pro L2TP tedy může být naprosto správný a přesto špatný klient pro bránu, která mluví jen IKEv2.
IKEv2 naopak vkládá EAP-MSCHAPv2 do výměny klíčů, takže stejný údaj selže v jiném okamžiku a projeví se jako chyba autentizace, nikoli jako chyba relace. Platformní profil IKEv2 v Androidu je každodenní příklad a žádá certifikát nebo identifikátor serveru, ne volby PPP. Jméno účtu je v obou uspořádáních stejné, takže vám neřekne, které máte. Rozhodne to jen operátorův seznam podporovaných protokolů.
VPN postavená na TLS přidává třetí uspořádání, s vlastními poli pro jméno a heslo a bez MS-CHAPv2 kdekoli ve výměně. Vidět pole pro heslo tedy není důkaz o protokolu za ním, protože formulář je stavěný tak, aby vypadal známě. Protokol potvrďte z dokumentace serveru, ne z tvaru okna klienta.
Odpovědi, které skutečně potřebujete
Pošlete žádost jako seznam, protože na seznam se těžko odpovídá napůl. Žádejte protokol tunelu, metodu v něm a klienta, kterého operátor podporuje na vaší platformě. Potom žádejte identitu brány a nastavení důvěry, formát účtu a co má být dostupné, až spojení poběží.
První tři rozhodují, zda vůbec získáte funkční profil. Poslední tři rozhodují, zda ten profil dělá, co práce potřebuje. Držte odpověď u tiketu, protože další člověk se zeptá na stejných šest otázek. Kde odpověď chybí, berte mezeru jako rozhodnutí, které operátor ještě neudělal, ne jako něco, co můžete odvodit.
| What you ask for | If it is wrong, the symptom shows up as |
|---|---|
| Tunnel protocol | No profile can be built at all |
| Method inside the tunnel | Credentials typed, then rejected |
| Gateway identity | The client refuses the server certificate |
| Account format | Authentication fails only for some staff |
| Routes and DNS | The tunnel is up and nothing resolves |
Nezmírňujte ověřování brány
Server dokazuje svou totožnost i klientovi a tato polovina výměny není dekorace. Vypnutí ověřování certifikátu, aby se tvrdošíjný profil připojil, přijímá jakýkoli koncový bod, který odpoví, včetně toho, kam se nikdo nechtěl dostat. Také skrývá skutečný nesoulad místo toho, aby ho vyřešilo, což posouvá selhání do pozdějšího a méně zřejmého okamžiku. Profil, který potřebuje ověření vypnout, je profil mířící na něco, co ověřit nedokáže.
Nesoulad bývá v názvu, protože certifikát vydaný pro jedno jméno hostitele selže, když profil volá adresu. Volejte jméno, místo abyste ověřování vypínali. Soukromá certifikační autorita selže, když zařízení nikdy nedostalo kořen, a opravou je ten kořen rozšířit schválenou cestou. Spravovaná prostředí očekávají, že operátor dodá identitu i kořen důvěry a profil na obojí odkáže. Když pole chybí, žádejte artefakt, místo abyste z ověřování ustoupili.
Přizpůsobte profil a pak dokažte každou fázi
Jakmile je nosič znám, postupujte podle dokumentovaného procesu toho klienta a zadávejte jen pole, která si vyžádá. Pole navíc vyplněná proto, že existují, jsou pořád špatné hodnoty a selžou později než povinná. Po prvním úspěšném připojení profil uložte beze změny, aby se pozdější úprava dala srovnat s něčím, o čem je známo, že funguje.
Pak ověřujte po fázích: tunel se naváže, uživatel se autentizuje, objeví se přidělená adresa a trasy a jedna povolená služba odpoví. Každá fáze nechává na serveru svůj řádek logu a čtení v pořadí mění vágní stížnost v konkrétní zjištění. Pokud platforma už uspořádání, které operátor popisuje, nepodporuje, je to rozhovor o migraci, ne důvod zapnout na zařízení všechny starší volby. Nosič, metoda a profil jsou tři oddělené odpovědi a spojení, které funguje, má všechny tři ve shodě.