VPN ઉપકરણ સ્થિતિ તપાસ અવરોધતી નથી? પહેલા રિપોર્ટને અનુસરો
તમારો એન્ડપોઇન્ટ એજન્ટ સ્વસ્થ હોવાનું જણાવે છે, તેમ છતાં આંતરિક એપ્લિકેશન ખૂલે છે. સંગ્રાહક, ચુકાદો અને અવરોધમાંથી પસાર થાઓ, પછી એક વિનંતીથી નકાર સાબિત કરો.
જો લેપટોપ, જેની એન્ટીવાયરસ સહીઓ અઠવાડિયા પહેલા અપડેટ થવાનું બંધ થઈ ગઈ હતી, હજી પણ તમારી આંતરિક એપ્લિકેશન ખોલી શકે છે, તો નીતિ દસ્તાવેજ ભાગ્યે જ એ વસ્તુ હોય છે જે ખોટી છે. ઍક્સેસ નકારવામાં આવે તે પહેલાં ત્રણ અલગ સિસ્ટમોએ સંમત થવું પડે છે: કંઈક એન્ડપોઇન્ટને માપે છે, કંઈક તે માપને મંજૂરી કે નકારના ચુકાદામાં ફેરવે છે, અને કંઈક ખરેખર ટ્રાફિકને પડતો મૂકે છે. જ્યારે અનુપાલન ન કરતું ઉપકરણ તેમ છતાં અંદર આવે છે, ત્યારે તેમાંથી બરાબર એક કડી ગેરહાજર હોય છે અથવા એવા પુરાવા પર ભરોસો કરે છે જે ન કરવો જોઈએ. નીચેની તપાસો તે ક્રમમાં ચાલે છે, અને દરેકનો એક અટકવાનો મુદ્દો છે.
અવરોધ છેલ્લું પગલું છે, પહેલું નહીં
પ્રમાણીકરણ અને ઉપકરણની સ્થિતિ જુદા જુદા પ્રશ્નોના જવાબ આપે છે. સફળ લોગિન સાબિત કરે છે કે ઓળખપત્ર રજૂ થયું હતું; તે રજૂ કરનાર મશીન પર ચાલતા સૉફ્ટવેર વિશે કંઈ કહેતું નથી. આ ગેપને કારણે જ નકલ કરેલી ક્લાયન્ટ પ્રોફાઇલ સ્વસ્થ દેખાતું સેશન અસ્વસ્થ હોસ્ટ પર લઈ જઈ શકે છે.
એન્ડપોઇન્ટ અનુપાલન કાર્ય પાસે આ સાંકળ માટે પહેલેથી શબ્દભંડોળ છે. RFC 5209 માંનું NEA સંદર્ભ મોડેલ કાર્યને સંગ્રાહક, મૂલ્યાંકન પગલું અને અમલીકરણ બિંદુમાં વિભાજિત કરે છે અને સ્પષ્ટ કહે છે કે જે ક્લાયન્ટ પોતાની સ્થિતિ વિશે ખોટું બોલે છે તે મોડેલની બહાર છે. આ ચેતવણી આકૃતિ કરતાં વધુ મહત્ત્વની છે: વિશ્વસનીય પ્લેટફોર્મ મોડ્યુલ પોતે જાહેર કરેલા માપને હકીકતમાં ફેરવતું નથી.
સંગ્રાહકને વ્યાપ અંગે પ્રામાણિક રાખો. તમારી નીતિ જે લક્ષણોનાં નામ આપે છે તે તે ઍક્સેસ માંગતા ઉપકરણ પર જાહેર કરવા જોઈએ, અને બહુ ઓછું બીજું. દરેક સ્થાપિત પેકેજની યાદી કરતો ઇન્વેન્ટરી એજન્ટ ઉપકરણ-સ્થિતિ સંગ્રાહકથી અલગ સાધન છે, અને તફાવત એકસાથે જાળવણી અને ચોકસાઈની સમસ્યા છે. જો રિપોર્ટ એક ઉપકરણ ઓળખ સાથે જોડી શકાય નહીં, તો મૂલ્યાંકનકર્તા અનુમાન કરી રહ્યો છે કે તેણે કયું મશીન હમણાં મંજૂર કર્યું.
લાલ સ્થિતિ દર્શાવતું ડેશબોર્ડ નિયંત્રણ નથી. પૂછો કે નકારાયેલ વપરાશકર્તા હજી શું સુધી પહોંચી શકે: વિકિ, ફાઇલ શેર, ડેટાબેઝ પોર્ટ? સુધારણાને એક સાંકડી સપાટીની જરૂર છે, અને બાકીનું બધું અવરોધની પાછળ આવે છે.
નિયમ વાંચતા પહેલા રિપોર્ટ વાંચો
ક્લાયન્ટના લીલા ટિકથી નહીં, સ્રોતથી શરૂ કરો. Windows માં સ્થાનિક માપ Defender તરફથી આવે છે અથવા જે ઉત્પાદને પોતાને Security Center માં નોંધ્યું છે તેનાથી, અને બંને વેન્ડર કન્સોલ વિના વાંચી શકાય છે:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productStateબીજો આદેશ productState નામનો પૂર્ણાંક પરત કરે છે. તેના બિટ્સ ઢીલા રીતે દસ્તાવેજીકૃત છે અને વેન્ડરો સક્ષમતા અને તાજગીના ફ્લેગ અલગ રીતે ગોઠવે છે, તેથી તેનું વિશ્લેષણ કરવાને બદલે તેને ખાતરી કરો. તૃતીય-પક્ષ સ્યુટ પણ અનઇન્સ્ટોલ પછી Security Center એન્ટ્રી છોડે છે, અને તે હવે ડિસ્ક પર ન હોય તેવા સૉફ્ટવેર વિશે જાહેર કરે છે.
ઉંમર એ ક્ષેત્ર છે જે લોકો છોડી દે છે. સહીનો સમયછાપ મૂલ્યાંકન કરતા મશીનની ઘડિયાળ સામે જ અર્થ ધરાવે છે, તેથી તેને આંખે અંદાજવાને બદલે અંતરાલમાં ફેરવો:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHoursહવે નીતિ પાસે વાંચવા માટે એક સંખ્યા છે. જો તમારો નિયમ 72 કલાક કહે છે, તો તે જ સંખ્યા તે વાપરે છે, અને અઠવાડિયું સૂતેલું લેપટોપ કોઈ લેબલનું અર્થઘટન કર્યા વિના નિષ્ફળ જાય છે. આદેશની બાજુમાં થ્રેશોલ્ડ નોંધો, કારણ કે એન્ડપોઇન્ટ સાધન બદલાય ત્યારે બંને દૂર જાય છે.
દરેક ઉપકરણ સ્થિતિને લેખિત ચુકાદામાં ફેરવો
સ્થિતિ વિશેના મોટાભાગના વિવાદો વાસ્તવમાં અજાણ્યી પંક્તિ વિશેના વિવાદો છે. પહેલી ઘટના પહેલાં જ તેનો નિર્ણય કરો, એવા કોષ્ટકમાં જે પુરાવો, ચુકાદો અને માલિકનાં નામ આપે છે, જેથી કોઈ ગેટવે કન્સોલ પર તાત્કાલિક નિર્ણય ન લે.
| Evidence the assessor has | Verdict | What it protects against |
|---|---|---|
| Timestamp inside the policy window, protective service running | Admit to normal applications | Nothing yet; the other checks still apply |
| Timestamp older than the window | Deny, admit remediation page only | Signature rollback and dormant laptops |
| Service disabled or reporting off | Deny, escalate to the endpoint owner | An agent reporting stale success |
| No report at all for this session | Treat as deny, never as healthy | Agents that fail open under load |
નીચેની પંક્તિ એ છે જ્યાં ઉત્પાદનો અલગ પડે છે. કેટલાક ગેટવે કનેક્શન નકારે છે અને કારણ સમજાવે છે; અન્ય ટનલને ઉપર આવવા દઈ મર્યાદિત નીતિ લાગુ કરે છે; થોડા છેલ્લા જાણીતા સારા રિપોર્ટ પર પાછા જાય છે. ફક્ત પહેલા બે જ વાજબી છે, અને તમારું કયું કરે છે તે ચકાસવું યોગ્ય છે.
ઓળખ અને પરવાનગીને પણ તેમની અલગ લેનમાં રાખો. દરેક સ્થિતિ પરીક્ષણ પાસ કરતા લેપટોપને એપ્લિકેશન માટે હજી પણ યોગ્ય માનવ અધિકૃતિની જરૂર છે, અને ઉપકરણ પ્રમાણપત્ર કીના કબજાને સાબિત કરે છે, ફાઇલસિસ્ટમની સ્થિતિને નહીં. ત્રણેયને એક બુલિયનમાં સંકોચવું એ જ રીતે હેલ્પડેસ્ક એકાઉન્ટને ઉત્પાદનમાં કાયમી ઍક્સેસ મળે છે.
અમલીકરણ માર્ગને વિનંતીથી ચકાસો, ડેશબોર્ડથી નહીં
અમલીકરણ વિનંતીનું લક્ષણ છે, તેથી તેને એક વિનંતીથી માપો. અનુપાલન ન કરતું મશીન ટનલ પર મૂકો અને વાસ્તવિક વપરાશકર્તા જે કૉલ કરે તે કરો:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/healthજે ઉપકરણને અવરોધવું જોઈએ તેની 200 આવવાનો અર્થ છે કે નિર્ણય ક્યારેય ડેટા માર્ગ સુધી પહોંચ્યો નહીં. બે સામાન્ય કારણો: નીતિ એવા જૂથ સાથે જોડાયેલી છે જેમાં પરીક્ષણ એકાઉન્ટ ક્યારેય જોડાયું નહીં, અથવા એપ્લિકેશન એવા રૂટ પર પહોંચી શકાય છે જે VPN ની માલિકીનો નથી.
પહેલા રૂટિંગ ધારણા ચકાસો. જો આંતરિક નામ એવા સરનામા પર ઉકેલાય જ્યાં ક્લાયન્ટ પહેલેથી સ્થાનિક LAN દ્વારા પહોંચે છે, તો ટનલ અપ્રસ્તુત છે અને કોઈ નીતિ લાગુ નહીં થાય. તે સરનામાને ગેટવે જે રૂટ ધકેલે છે તેની સાથે સરખાવો. OpenVPN પર, દરેક ક્લાયન્ટની નીતિ સામાન્ય નામ દ્વારા કી કરેલી ફાઇલોમાં રહે છે, તેથી તેની તપાસ સરળ છે:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17disable ધરાવતી ફાઇલ તે ક્લાયન્ટને સંપૂર્ણપણે ડિસ્કનેક્ટ કરે છે, જ્યારે push "route ..." લીટી તે ક્યાં પહોંચી શકે તે સાંકડું કરે છે. બંને અમલીકરણ છે, અને બંને રિપોર્ટ ડિબગ કરનારને દેખાય છે.
એક જ ટ્રાયલ એકાઉન્ટ પર ચાર કેસ ચકાસો
અંતિમ તપાસ નાની મેટ્રિક્સ છે, સુખી માર્ગ નહીં. એક પરીક્ષણ એકાઉન્ટને ચાર સ્થિતિઓમાંથી પસાર કરાવો: વર્તમાન, સમાપ્ત સહી, સુરક્ષા નિષ્ક્રિય, એજન્ટ સ્થાપિત નથી. દરેક માટે, મૂલ્યાંકન લોગમાં ચુકાદો, એપ્લિકેશન જે HTTP સ્થિતિ પરત કરે છે, અને સુધારણા પૃષ્ઠ લોડ થયું કે નહીં તે નોંધો.
foreach ($case in 'current', 'stale', 'disabled', 'absent') {
Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusSignatureLastUpdated
curl.exe -sS -o NUL -w "%{http_code}
" --max-time 5 https://app.internal.example/health
}બે વિગતો ચૂકી જવી સરળ છે. પહેલા પુનઃપ્રસારણ: મશીન સ્વસ્થ હતું ત્યારે લીધેલો રિપોર્ટ તે જ ઉપકરણ પર પછીના સેશન માટે સ્વીકારવો ન જોઈએ, તેથી વર્તમાન કનેક્શન સાથે જોડાયેલો સમયછાપ શોધો. પછી દૂર કરવું: એજન્ટ અનઇન્સ્ટોલ કરવાથી જૂના રિપોર્ટ જેવો જ નકાર આવવો જોઈએ, સ્વચ્છ પાસ નહીં, અને આ જ કેસ મોટાભાગે ક્યારેય ચકાસાતો નથી.
જ્યારે મેટ્રિક્સ કોષ્ટક સાથે મેળ ખાય, ત્યારે જે વ્યક્તિ આગળ ગેટવે ચલાવશે તેને ત્રણ વસ્તુઓ આપો: આદેશો, થ્રેશોલ્ડ અને ચાર અપેક્ષિત પરિણામો. એ જ સોંપણી સાચી ડિલિવરેબલ છે, કારણ કે ફક્ત નીતિ દસ્તાવેજમાં જીવતી સ્થિતિ-રચના એન્ડપોઇન્ટ સાધન તેનું રિપોર્ટિંગ ક્ષેત્ર બદલે ત્યારે પહેલી વાર ભટકી જાય છે.