Azure VPN Client: die VPN-platform het nie die verbinding begin nie

Die statuslyn sê die VPN-platform het nie die verbinding begin nie, die profiel voer sonder klag in, en die poort is gesond vir almal anders. Daardie boodskap beskryf ’n oorhandiging binne Windows, nie ’n verwerpte geloofsbrief nie, dus loop die nuttige volgorde van die goedkoopste toestandsverandering na die mees vernietigende. Om ’n profiel weer in te voer kos ’n minuut, om die pakket te herstel kos ’n herbegin, en om dit terug te stel kos elke profiel op die masjien. Om in die verkeerde volgorde te werk vernietig die bewyse wat jy nodig het om daardie gevalle te onderskei.

Herinvoer, herstel, terugstel: drie verskillende koste

Die drie aksies is nie uitruilbaar nie, en net een van hulle is sonder werk omkeerbaar. Herinvoer verfris die profiel en hou die app-installasie. Herstel hou die ingevoerde profiele en herskryf die pakketlêers. Terugstel verwyder die profiele saam met die app-toestand, so jy voer daarna alles weer in.

Begin met ’n vars aflaai van azurevpnconfig.xml wanneer die poort, adrespoel of verifikasiemetode verander het. ’n Profiel wat ’n geskrapte poort noem, lewer presies hierdie statuslyn, en geen mate van kliëntherstel maak ’n lêer reg wat na iets wys wat nie meer bestaan nie.

Kontroleer voor enige vernietigende stap dat die app in die agtergrond mag loop: Instellings, Programme, Geïnstalleerde programme, Azure VPN Client, Gevorderde opsies. ’n Opgeskorte kliënt kan nie die platform-oordrag voltooi nie.

RasMan is die diens waaraan die kliënt oorhandig

Die Remote Access Connection Manager is wat ’n kliëntversoek in ’n Windows-verbinding omskakel. Herbegin dit uit ’n verhoogde opdrag met net stop rasman en daarna net start rasman, en koppel weer voordat jy iets anders verander.

As dit die verbinding herstel, stel die outo-starttipe sodat die regstelling ’n herbegin oorleef: sc.exe config rasman start= delayed-auto. ’n Diens wat nou loop maar by die selflaai gedeaktiveer is, lewer môreoggend dieselfde fout.

Let op ’n diens wat begin en dan uit sigself stop. Daardie patroon wys na ’n afhanklikheid of ’n beleid, en herbegin sal telkens minute lank werk, wat slegter is as ’n skoon fout omdat dit soos ’n ongereelde netwerkprobleem lyk. Kyk in die System-log vir die diensnaam rondom die poging, en bevestig dat die afhanklikhede ook loop.

Huidige gebruiker of plaaslike masjien: twee sertifikaatstore

As die kliënt met ’n leë sertifikaatlys oopmaak, is die profiel nie die skuld nie en die diens ook nie. Die kliënt lees die huidige gebruiker se persoonlike stoor: maak certmgr.msc oop, vou Certificates, Current User, Personal, Certificates uit, en bevestig die sertifikaat is daar met ’n privaat sleutel.

Die plaaslike masjien-stoor wat met certlm.msc oopgemaak word, is ’n ander stoor, en om daar te installeer bevredig nie ’n kliënt wat in die gebruikerstoor kyk nie. Met sertifikaatverifikasie hou die poort net die wortel se publieke sleutel, en elke toestel het sy eie sertifikaat nodig wat uit daardie wortel uitgereik is. ’n Sertifikaat wat van ’n ander masjien gekopieer is, kom gewoonlik sonder sy privaat sleutel, wat ’n inskrywing lewer wat jy kan kies maar steeds nie kan verifieer nie.

’n Leë keuseveld is ’n stoorprobleem, nie ’n tonnelprobleem nie.

Sertifikaatverifikasie of Azure AD: verskillende foutvorms

Vir Azure AD-verifikasie het die punt-na-punt-konfigurasie die huurder-URL, die Azure VPN Client-toepassing-ID as die gehoor, en die STS-uitreiker nodig, met ’n administrateur wat toestemming aan die Azure VPN-toepassing gee. Stoor daardie konfigurasie, laai die pakket weer af, en voer die nuwe lêer in eerder as om ’n ouer kopie te hergebruik.

Bevestig ook dat die kliënt-adrespoel nie die virtuele netwerk of ’n plaaslike reeks oorvleuel nie, en dat die teikemasjien se netwerksekuriteitsgroep die poel toelaat. Daardie twee foute oorleef elke kliënt-kant herstel.

Skootrekenaar-kant of poort-kant

Moenie die tonnel aan ’n publieke adres-toets beoordeel nie. ’n Punt-na-punt-verbinding stuur nie alle internetverkeer na Azure nie, so ’n onveranderde publieke adres is te wagte terwyl die tonnel korrek werk. Toets eerder ’n private adres binne die virtuele netwerk en lees die effektiewe roetes op die masjien.

Skryf neer watter stap die verbinding herstel het, die kliëntweergawe, die aflaaidatum van die profiel en of ’n sertifikaat of die identiteitsverskaffer die geloofsbrief gelewer het. Daardie rekord maak die volgende geval ’n kontrole van twee minute, en dit wys of die foute na die poort toe dryf eerder as om op die skootrekenaar te bly.

Volgorde van werk: voer ’n huidige profiel weer in, herbegin RasMan, laat agtergronduitvoering toe, herstel die pakket, en stel eers terug as die sertifikaatstoor bevestig is as ongeskonde.