GVC vas by Acquiring IP: dit is nie ’n wagwoordprobleem nie

Global VPN Client bly by Acquiring IP staan, en die refleks is om die wagwoord weer te tik of die kliënt te herinstalleer. Nie een raak die stadium wat gefaal het nie. Verifikasie het klaar gebeur voordat die kliënt ooit om ’n adres gevra het, so dit is nie die aanmelding wat jou by daardie reël hou nie. Wat jou daar hou, is ’n DHCP-uitruiling wat nog nie klaargekry het nie, en dit kan op drie verskillende plekke vasval.

Verifikasie en adrestoewysing is aparte stadiums

GVC bewys eers wie jy is en vra dan die instellings vir sy virtuele adapter aan volgens die beleid wat aan jou verbinding toegewys is. Dit is opeenvolgende stappe met verskillende foutprofiele. ’n Slegte aanmelding misluk gewoonlik vroeër, met ’n verifikasie- of onderhandelingsboodskap eerder as die adresreël.

Daardie volgorde verduidelik waarom ’n wagwoordherstel, ’n nuwe plaaslike gebruiker of ’n herinstallering hier niks verander nie. Die kliënt is reeds gemagtig; hy wag nou op ’n lease wat die gateway of sy DHCP-vennoot moet lewer. Selfs ’n beleid wat die gebruiker toelaat maar geen adresreeks toeken nie, lewer presies hierdie skerm.

Die eerste nuttige vraag is dus nie of die aanmelding reg is nie, maar watter beleid toegewys is en wat daardie beleid oor virtuele-adapteradressering sê. Lees die effektiewe konfigurasie vir daardie verbinding eerder as ’n kollega se werkende skermskoot.

Waar die lease werklik vandaan kom

Twee modelle is algemeen. Die firewall kan self ’n DHCP-omvang vir VPN-kliënte bedryf, of hy kan die versoek na ’n eksterne DHCP-bediener op die interne netwerk deurstuur. Die model bepaal watter logs saak maak en wie jy moet bel.

Kontroleer in die interne model dat die omvang nog bestaan, aan die regte koppelvlak behoort en vry leases het. ’n Uitgeputte omvang lewer ’n kliënt wat perfek verifieer en nooit ’n adres ontvang nie, en die gateway-log wys miskien net die versoek. In die deurstuurmodel moet die deurstuurteiken, die roete terug na die VPN-kliëntreeks en enige interne DHCP-magtiging almal in lyn wees.

Skryf neer watter model jou ontplooiing gebruik voordat jy enigiets toets. Die helfte van die teenstrydige raad aanlyn aanvaar die ander een.

’n Tonnel kan op wees en tog die lease laat val

’n Gevestigde beheerverbinding bewys dat die onderhandeling gewerk het, nie dat tonneldata beide kante toe gaan nie. Die DHCP-uitruiling het versoek en antwoord nodig om die datapad te oorleef, en dit is waar enkripsie-instellings, beleid vir die VPN-sone en MTU-probleme sit.

NAT-traversal-raad is die duidelikste voorbeeld van konteks wat saak maak. Sommige paaie het dit nodig, ander werk net daarsonder, en die tussenliggende NAT plus die onderhandelde verbinding besluit watter. Om dit blind te verander terwyl jy ook kliëntinstellings verander, beteken jy sal nie weet watter verandering die resultaat gelewer het nie. Teken die onderhandelde pad en die bewyse aan voordat jy enkapsulering wysig.

Om die tuisroeteerder te herbegin hoort in dieselfde kategorie. Dit verlig soms die simptoom, maar dit identifiseer nie waarom die lease gefaal het nie, en die probleem kom terug by die volgende verbinding.

Volg die lease-pad in volgorde

Begin by die adapter en werk uitwaarts, sodat elke stap net om een rede kan faal:

> 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

’n Adres van 169.254.x.x beteken die adapter bestaan en het glad geen antwoord ontvang nie, wat na die lease-bron of die datapad wys. ’n Korrekte adres in die VPN-reeks met die verkeerde DNS-inskrywings is ’n ander fout: die lease het gewerk en die beleid het onvolledige instellings gelewer. ’n Adapter wat nooit verskyn nie, beteken die kliënt het nie so ver gekom om dit te skep nie.

Sodra ’n lease verskyn, probeer die werklike hulpbron eerder as om oorwinning by die adresreël aan te kondig. As toegang tot lêers of die intranet steeds misluk, hou die suksesvolle lease as bewys en gaan oor na naamresolusie of beleid, want jy het die oorspronklike fout agtergelaat.

SonicWall se nota oor die virtuele adapter lys verskeie aparte vertakkings, en sy ouer skermskote moet nie as die huidige spyskaartkaart gelees word nie. Gebruik dit om die stadium te bevestig wat jy bereik het, nie as ’n kontrolelys om in die geheel toe te pas nie.