Netwerkry voor die VPN gereed is? Maak dit van die bediener afhanklik

Die netwerkry verskyn by aanmelding en maak dan oop as ’n leë gids, of met ’n rooi kruis en ’n boodskap oor ’n netwerkbron wat nie beskikbaar is nie. Toestemmings is gewoonlik in orde. Wat gebeur het, is dat die karteeropdrag geloop het in die tydperk waarin die VPN-kliënt bestaan het maar daar geen roete na die lêerbediener was nie, en Windows het daardie mislukking as die toestand van die ry aangeteken. Die oplossing is om op te hou om die kartering as iets te sien wat by aanmelding gebeur, en om dit as die laaste stap van ’n verbindingsreeks te behandel.

Waarom die kartering te vroeg loop

’n Aanmeldskrip begin wanneer die sessie begin. ’n VPN-kliënt wat tydens aanmelding verbind, voeg sy eie tydlyn daarby: die proses kan loop, die virtuele adapter kan bestaan, en die roete na die kantoor-subnet kan steeds ontbreek. Daardie drie toestande lyk dieselfde vanuit ’n skrip se oogpunt, en net een van hulle werk.

Sommige omgewings reageer deur dieselfde mislukkende reël by elke aanmelding te herhaal, wat ’n gebruiker oplewer wat geleer het om die ry twee keer te klik, en ’n skrip wat nog nooit eens op sy eie geslaag het nie.

Die ry self maak dit erger. ’n Gekarteerde ry is ’n sessievoorwerp, en sodra Windows dit as onbeskikbaar gemerk het, kan die ikoon lank nadat die tonnel gesond is, gebreek bly. Dit is waarom herkartering met die hand werk terwyl die skrip niks blyk te doen nie. Die sessie onthou die mislukking, nie die bedoeling daarvan nie.

’n Verbinde status is nie ’n roete nie

Die VPN-ikoon in die taakbalk meld of die tonnel op is. Dit sê niks oor of daar ’n roete na ’n spesifieke bediener bestaan nie, of DNS daardie naam na die tonneladres oplos, of die bediener se eie firewall jou aanvaar nie.

Dit is drie afsonderlike mislukkings met dieselfde sigbare uitkoms, en om op die taakbalk-ikoon te wag, val hulle saam in een onbetroubare sein.

’n Gereedheidskontrole wat die bediener noem wat jy werklik nodig het onderskei hulle, want dit misluk totdat die spesifieke pad werk, eerder as totdat een of ander koppelvlak homself as verbind rapporteer.

Wag op die bediener, nie op die kliënt nie

Kies een gasheer wat net deur die tonnel bereikbaar is, en wag daarvoor voordat jy enigiets karteer. Die fragment hieronder verbind ’n gestoorde Windows VPN-inskrywing, peil die lêerbediener en karteer dan die ry.

@echo off
set server=fileserver.corp.example
rasdial "Office VPN" /disconnect
rasdial "Office VPN"
:wait
ping -n 1 -w 1000 %server% >nul || (
  timeout /t 5 /nobreak >nul
  goto wait
)
net use Z: \\%server%\share /persistent:no

Die ping is ’n gereedheidspeiling, nie ’n toestemmingstoets nie. As ICMP op jou netwerk gefiltreer word, peil eerder die diens wat jy werklik gebruik: net view \\%server% vir ’n vinnige kontrole, of ’n kort TCP-toets teen poort 445 in PowerShell. Enige van die twee wag op die ding wat saak maak.

Voeg ’n begrensde aantal pogings by. ’n Waglus sonder ’n plafon verander ’n stukkende tonnel in ’n sessie wat nooit klaar aanmeld nie, en dit is ’n erger ondersteuningsoproep as ’n ontbrekende netwerkry.

Maak dit herhaalbaar en sessiebewus

Voer dit binne die gebruiker se eie sessie uit. ’n Taak wat as SYSTEM loop, plaas die ry in ’n heeltemal ander sessie, en die aangemelde gebruiker sien nooit die uitslag nie. Dit gee jou ’n skrip wat sukses rapporteer en ’n lessenaar met geen ry daarop nie.

Kontroleer voordat jy karteer, en verwyder net die verouderde inskrywing. net use Z: /delete gee ’n fout terug wanneer die letter ongebruik is, en daardie fout is veilig om te ignoreer eerder as ’n rede om die res van die skrip te laat vaar. Hou /persistent:no sodat ’n mislukte poging nie later in ’n permanente herverbindingspoging ontaard nie.

En moenie ’n wagwoord in die lêer sit nie. rasdial kan geloofsbriewe hergebruik wat vir die VPN-inskrywing gestoor is, en die gedeelde gids moet as die aangemelde gebruiker verifieer. As die gedeelde gids werklik ander geloofsbriewe nodig het, registreer dit een keer per gebruiker met cmdkey eerder as om dit in te sluit in ’n batch-lêer wat op ’n aanmeldgedeelte woon. Enigiemand wat daardie gedeelte kan lees, kan die wagwoord lees, wat ’n gerief in ’n voorval verander.

Om die hele skrip weer te loop behoort skadeloos te wees, want dit is wat gaan gebeur. Gebruikers verbind weer, skootrekenaars word wakker, en dieselfde kodebaan loop weer met ’n ander begintoestand.

Teken genoeg aan om te bewys watter helfte laat was

Skryf die tydstempel, die gereedheidsuitslag en die kartering se uittreekode na ’n lêer onder die gebruiker se profiel. Wanneer die volgende verslag van ’n ontbrekende ry opdaag, beantwoord daardie log die enigste vraag wat saak maak: het die tonnel laat opgedaag, of het die gedeelde gids geweier?

Sonder dit word elke herhaling van nuuts af ondersoek, en die gewone gevolgtrekking is ’n toestemmingsverandering wat niks regmaak nie.

Toets die reeks een keer vanaf ’n koue selfs en een keer vanaf slaap. Die wakkerword-geval is waar die volgorde die meeste breek, want die sessie hervat voordat die netwerk dit doen, en die skrip sien ’n masjien wat al ure lank aangemeld is.