GVC henger på Acquiring IP: det er ikke et passordproblem

Global VPN Client blir stående på Acquiring IP, og refleksen er å skrive inn passordet på nytt eller installere klienten på nytt. Ingen av delene berører trinnet som feilet. Autentiseringen var fullført før klienten i det hele tatt ba om en adresse, så det er ikke påloggingsinformasjonen som holder deg på den linjen. Det som holder deg der, er en DHCP-utveksling som ikke er ferdig, og den kan stoppe på tre forskjellige steder.

Autentisering og adressetildeling er separate trinn

GVC beviser først hvem du er, og ber deretter om innstillingene for sin virtuelle adapter i samsvar med policyen som er tildelt tilkoblingen din. Dette er sekvensielle trinn med ulike feilsignaturer. Dårlig påloggingsinformasjon feiler vanligvis tidligere, med en autentiserings- eller forhandlingsmelding i stedet for adresselinjen.

Den rekkefølgen forklarer hvorfor en tilbakestilling av passordet, en ny lokal bruker eller en nyinstallering ikke endrer noe her. Klienten er allerede autorisert; nå venter den på en lease som gatewayen eller DHCP-partneren må levere. Selv en policy som tillater brukeren, men ikke tildeler noe adresseområde, gir nøyaktig denne skjermen.

Så det første nyttige spørsmålet er ikke om påloggingsinformasjonen er riktig, men hvilken policy som ble tildelt, og hva den policyen sier om adressering av den virtuelle adapteren. Les den effektive konfigurasjonen for den tilkoblingen i stedet for et fungerende skjermbilde fra en kollega.

Hvor leasen faktisk kommer fra

To modeller er vanlige. Brannmuren kan selv kjøre et DHCP-område for VPN-klienter, eller videresende forespørselen til en ekstern DHCP-server på det interne nettverket. Modellen avgjør hvilke logger som betyr noe, og hvem du skal ringe.

I den interne modellen må du kontrollere at området fortsatt finnes, tilhører riktig grensesnitt og har ledige leases. Et uttømt område gir en klient som autentiserer perfekt og aldri får en adresse, og gateway-loggen viser kanskje bare forespørselen. I relay-modellen må relay-målet, ruten tilbake til VPN-klientområdet og enhver intern DHCP-autorisasjon stemme overens.

Skriv ned hvilken modell utrullingen din bruker før du tester noe. Halvparten av de motstridende rådene på nettet forutsetter den andre.

En tunnel kan være oppe og likevel miste leasen

En etablert kontrolltilkobling beviser at forhandlingen virket, ikke at tunneldata passerer begge veier. DHCP-utvekslingen trenger forespørsel og svar for å overleve datastien, og det er der krypteringsinnstillinger, policy for VPN-sonen og MTU-problemer bor.

Rådet om NAT-traversal er det tydeligste eksempelet på at kontekst betyr noe. Noen stier trenger det aktivert, andre virker bare med det slått av, og NAT-en imellom sammen med den forhandlede tilkoblingen avgjør hvilken. Å endre det blindt mens du også endrer klientinnstillinger betyr at du ikke vet hvilken endring som ga resultatet. Noter den forhandlede stien og bevisene før du endrer innkapslingen.

Å starte hjemmeruteren på nytt hører i samme kategori. Det fjerner noen ganger symptomet, men det identifiserer ikke hvorfor leasen feilet, og problemet kommer tilbake ved neste tilkobling.

Gå gjennom lease-stien i rekkefølge

Start ved adapteren og arbeid deg utover, slik at hvert trinn bare kan feile av én grunn:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

En adresse som 169.254.x.x betyr at adapteren finnes og ikke fikk noe svar i det hele tatt, noe som peker på lease-kilden eller datastien. En riktig adresse i VPN-området med feil DNS-oppføringer er en annen feil: leasen virket, og policyen ga ufullstendige innstillinger. En adapter som aldri dukker opp, betyr at klienten ikke kom så langt som til å opprette den.

Når en lease dukker opp, test den faktiske ressursen i stedet for å erklære seier på adresselinjen. Hvis fil- eller intranettilgang fortsatt feiler, behold den vellykkede leasen som bevis og gå videre til navneoppslag eller policy, fordi du har lagt den opprinnelige feilen bak deg.

SonicWalls merknad om den virtuelle adapteren lister opp flere separate grener, og de eldre skjermbildene bør ikke leses som dagens menykart. Bruk den til å bekrefte trinnet du nådde, ikke som en sjekkliste som skal brukes i sin helhet.