Windows VPN 720-as hiba: címkészlet vagy ügyfél-kötés?
A 720-as hiba azt jelenti, hogy a kapcsolat soha nem kapott használható címet. Válassza szét az egyetlen gazdagépen jelentkező hibákat a sok gazdagépen jelentkező hibáktól, mielőtt újratelepíti az adaptert.
A 720-as hiba a hitelesítő adatok elfogadása után jelenik meg, ezért küldi vissza az embereket a jelszómezőhöz. A kapcsolat eljutott arra a pontra, ahol címet tárgyalnak, és nem kapott egyet sem. Két nagyon különböző hiba eredményezi ugyanazt a párbeszédablakot: a kiszolgálónak nem volt mit kiosztania, vagy éppen ez az ügyfél nem tudta befejezni a tárgyalást. Ennek a kettőnek a szétválasztása bármihez nyúlás előtt a javítás nagy része, és a szétválasztás dokumentálva van a Microsoft 720-as hiba hibaelhárítási oldalán.
Amit a párbeszédablak elhallgat
Az üzenet a PPP-tárgyalás hibáját írja le, és szándékosan homályos, mert az ügyfél nem látja, miért utasított a kiszolgáló. Ez nem hitelesítő adatok hibája, és nem állítás az alagút titkosításáról. Azt jelenti, hogy a cím vagy a tárgyalási paraméterek nem érkeztek meg.
A kiszolgáló oldalán a szokásos ok a kiosztás: egy statikus RRAS-készlet szabad címek nélkül vagy egy DHCP-konfiguráció, amelynek tartománya kimerült vagy elérhetetlen, pontosan ezt a tünetet okozza minden ügyfélnél, amely próbálkozik. Az ügyfél oldalán a szokásos ok egy kötés. A PPP-t hordozó WAN Miniportot a megfelelő összetevőkhöz kell kötni, és egy letiltott kötés vagy egy behelyezett hálózati szűrő megállíthatja a tárgyalást látható eszközprobléma nélkül. A két család különböző bizonyítékokat igényel, és a leggyorsabb mód a köztük való választásra, ha megszámolja, hány ügyfelet érint.
Előbb a populációt ossza szét, aztán a készletet
Számolja meg az érintett ügyfeleket, mielőtt bármilyen konfigurációt olvasna. Az a hiba, amely mindenkit egyszerre ér, kiszolgálóállapot, és az a hiba, amely egy gépet követ a hálózatok között, ügyfélállapot. Ez a számlálás egy üzenetbe kerül egy csevegőcsatornán, és megspórol egy délutánt.
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why the address was not delivered to one specific client |
Ezután kapcsoljon össze egy sikertelen kísérletet a kiszolgáló saját naplójával, mert az RRAS eseményt naplóz, amikor nem tud címet kiosztani, és az az esemény a hibát nevezi meg a tünet helyett. Ha a hiba egy adott ügyfelet követ, a kiszolgálónapló semmit sem mutat arra a kísérletre, ami önmagában is informatív. A kiosztási hiba hiánya arra szűkíti a problémát, hogy az adott ügyfélen folyó tárgyalás a hibás, és megmondja, mely parancsokat futtassa következőként.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Olvassa ki a kiszolgáló címkiosztási állapotát
Az RRAS oldalán erősítse meg, melyik kiosztási módszer van valójában beállítva, és ne azt, amelyet a dokumentáció feltételez. A statikus készlet és a DHCP-n keresztül továbbított konfiguráció különböző módon hibázik, és a javítás ahhoz tartozik, amelyik használatban van. Statikus készletnél számolja meg a szabad címeket, és keressen felhasználónkénti hozzárendeléseket, amelyek olyan bérletet tartanak, amelyre senki sem emlékszik, mert egy nagynak látszó készlet teljesen lefoglalt lehet. DHCP-nél ellenőrizze, hogy a továbbító eléri-e a kiszolgálót, és hogy a tartományban vannak-e szabad bérletek.
A hétköznapi ügyfelek által kimerített tartomány ugyanazt a 720-at adja, mint egy rosszul beállított készlet, és az RRAS-konzol mindkét esetben teljesen egészségesnek látszik. Álljon ellen az örökölt kerülőútnak, hogy a készletet kisebb tartományokra ossza: az eredeti tanács egyetlen rendszergazda eredményét írta le, és nem javítja meg azt a kiosztási hibát, amelyet a kiszolgáló saját eseményei közvetlenül meg tudnak nevezni.
Olvassa ki az ügyfél kötéseit anélkül, hogy eltörné őket
Ha a bizonyítékok egyetlen ügyfélre mutatnak, vizsgálja meg a rejtett adaptert a verem újratelepítése helyett. Az első parancs felsorolja a WAN Miniport felületeket és azok nevét; a második azt a nevet veszi, amelyet visszaadott, nem egy útmutatóból másolt nevet.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsOlvassa át a listát a címfeloldási kötés és a harmadik féltől származó szűrők szempontjából. A letiltott kötés célzott javítás, míg egy szűrő jelenléte kérdés annak a szoftvernek a tulajdonosához, nem pedig engedély egy biztonsági termék kikapcsolására. Az összes adapter törlése az egyetlen lépés, amely megsemmisíti a bizonyítékokat, amelyekre szüksége lenne, ha a hiba visszatér.
A javítás után próbálja újra ugyanazt a profilt, majd ismételje meg a kétügyfeles esetet, ha ez volt az eredeti tünet, mert egy sikeres első kapcsolat elrejti a kiosztási problémát, amelyet egy második ügyfél felfed. Tartsa a feljegyzést négy mezőben: melyik ügyfél, melyik kötés, melyik esemény és mi változott. Kísérletenként egy réteget változtasson, mert az ügyféljavítást és a készletmódosítást együtt alkalmazva nem lehet visszavezetni, és a következő hiba újnak fog látszani, amikor ugyanaz.