Ekzekutoni një detyrë kur VPN lidhet: ngjarje, sondim apo kredencial?
Një skript hyrjeje ekzekutohet përpara se tuneli të ekzistojë. Krahasoni një shkaktues ngjarjeje rrjeti, një sondim burimi dhe kredencialet e ruajtura sipas asaj që garanton secili.
Një skript hyrjeje që harton një disk ose nis një punë sinkronizimi ekzekutohet përpara se tuneli të ketë adresë, kështu që dështon në heshtje dhe përdoruesi e rregullon me dorë çdo mëngjes. Windows nuk u ofron shumicës së klientëve asnjë kthim thirrjeje lidhjeje për çdo VPN, por regjistron ndryshimin e rrjetit, dhe ai regjistrim mund ta nisë punën në momentin e duhur. Zgjedhja qëndron mes reagimit ndaj atij regjistrimi, sondimit të burimit dhe heqjes së nxitjes që e bëri dështimin të dukshëm.
Krahasimi i tre mekanizmave sipas asaj që garantojnë është më mirë se renditja e tyre sipas elegancës. Secili dështon ndryshe, dhe mënyra e dështimit është ajo me të cilën jetoni më pas.
Pse hyrja niset shumë herët
Hyrja dhe nisja ekzekutohen përpara se përshtatësi VPN të marrë adresën e tij, kështu që një hartëzim disku, një URL e brendshme ose një lidhje me bazën e të dhënave e provuar në atë moment nuk kanë as rrugë as zgjidhës. Kërkesa dështon, dhe sesioni mbetet në një gjendje që përdoruesi duhet ta rregullojë manualisht. Zhvendosja e të njëjtit skript në dosjen e nisjes nuk ndryshon asgjë, sepse problemi i rendit udhëton me të. Shkaktuesi duhet të jetë një ndryshim rrjeti dhe jo një ngjarje sesioni.
Një detyrë e planifikuar në hyrje me një vonesë arbitrare duket si rregullim dhe në të vërtetë është një hamendësim. Funksionon në një lidhje të shpejtë dhe dështon në një të ngadaltë, që është lloji më pak i dobishëm i besueshmërisë.
Tre grepa të krahasuar
Mekanizmat ndryshojnë në atë që vëzhgojnë, sa shpejt reagojnë dhe çfarë bëjnë për një rilidhje më vonë gjatë ditës. Tabela i krahason në këto tre pika dhe jo në sa i zgjuar tingëllon secili.
| Mechanism | Reacts to | Covers a mid-session reconnect | Typical failure |
|---|---|---|---|
| Network profile event | A network connect record | Yes, when the event repeats | Runs on the wrong network |
| Resource poll with backoff | The resource becoming reachable | Yes | Log noise and a wasted window |
| Stored credentials alone | Nothing; it removes a prompt | No | Still fires before the tunnel |
Lexoni tabelën rresht pas rreshti. Grepi i ngjarjes është më i shpejti dhe më i zhurmshmi, pasi Windows regjistron çdo rrjet duke përfshirë Wi-Fi-n e kafenesë, kështu që veprimi duhet ta verifikojë burimin përpara se të bëjë çdo gjë. Sondimi është më i ngadaltë dhe më i saktë, sepse ka sukses pikërisht kur përgjigjet ndarja ose emri i hostit, dhe nuk ka nevojë të dijë cili klient është instaluar. Kredencialet e ruajtura nuk janë aspak një opsion konkurrues: ato heqin nxitjen e fjalëkalimit, që është një arsye e dytë dhe e pavarur pse një hartëzim në hyrje dështon.
Zgjedhja mes dy të parëve varet nga fakti nëse ekziston një ngjarje e përdorshme në klient. Aty ku ekziston, një ngjarje plus një kontroll burimi është parazgjedhja më e mirë.
Ndërtoni saktë shkaktuesin e ngjarjes
Regjistrimi ndodhet në regjistrin Microsoft-Windows-NetworkProfile/Operational, dhe ID 10001 shënon një rrjet që sapo është lidhur. Krijoni detyrën me një shkaktues Në një ngjarje të drejtuar nga ai regjistër, ai emër ofruesi dhe ai identifikues. Çdo rrjet të cilit i bashkohet makina do ta aktivizojë atë, kështu që veprimi ka nevojë për një klauzolë mbrojtëse dhe jo për një supozim, dhe duhet të ekzekutohet vetëm sa kohë përdoruesi është i hyrë nëse puna prek disqet e hartëzuara.
Klauzola mbrojtëse duhet të testojë atë që detyra ka vërtet nevojë, si një rrugë ndarjeje ose një port shërbimi, dhe të dalë në heshtje kur nuk është e arritshme. Testimi i emrit të përshtatësit nuk mjafton, sepse një klient mund të ripërdorë një përshtatës në disa profile. Dalja në heshtje e mban regjistrin të lexueshëm dhe parandalon një stuhi ritentimesh kundër një rrjeti që nuk do ta shërbejë kurrë burimin.
Testoni që detyra ekzekutohet në momentin e duhur
Provoni momentin dhe jo konfigurimin. Komandat më poshtë tregojnë përkufizimin e detyrës, ngjarjet e fundit të profilit të rrjetit dhe nëse burimi është i arritshëm nga llogaria nën të cilën ekzekutohet detyra. Ekzekutoni ato pas një rilidhjeje të vërtetë dhe jo pas një nisjeje manuale.
schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoami
Një zë në historikun e detyrave që ekziston ndërsa asnjë ngjarje rrjeti nuk përputhet do të thotë që shkaktuesi është i gabuar dhe jo veprimi. Nëse ngjarjet shfaqen dhe detyra nuk ekzekutohet, detyra mund të ekzekutohet nën një llogari që nuk e sheh burimin, dhe dalja e llogarisë është të dhëna. Një kontroll burimi që kalon ndërsa hartëzimi mungon ende tregon kontekstin e sesionit dhe jo lidhshmërinë. Secili prej këtyre tre vëzhgimeve të çon në një rregullim tjetër.
Shkruani një rresht regjistri për çdo ekzekutim me adresën, rezultatin e burimit dhe përfundimin. Dështimi i radhës do të tregojë atëherë nëse detyra ekzekutohej herët, ekzekutohej në rrjetin e gabuar apo nuk ekzekutohej fare.