Windows VPN એડેપ્ટર ખાનગી હોવું જોઈએ કે જાહેર?
ત્રણ કસોટીથી નક્કી કરો કે Windows VPN એડેપ્ટર ખાનગી પ્રોફાઇલમાં આવે છે કે નહીં: વિશ્વસનીય માર્ગ, સ્થિર વર્ગીકરણ અને તમને ખરેખર જરૂરી નિયમો.
Windows VPN એડેપ્ટરને ખાનગી પર સેટ કરવું કોર્પોરેટ ટનલ માટે સાચું છે અને વ્યાપારી VPN ક્લાયન્ટ માટે ખોટું છે, અને આ તફાવત દેખાવનો નથી. નેટવર્ક શ્રેણી ફાયરવોલ પ્રોફાઇલ પસંદ કરે છે, તેથી એક ફેરફાર એકસાથે આખો નિયમસમૂહ પ્રવેશ આપે છે. મેં લોગિન સ્ક્રિપ્ટ જોઈ છે જે દરેક અજાણ્યા એડેપ્ટરને ખાનગી બનાવે છે, જેણે હોટેલના વાયરલેસ નેટવર્ક પર ફાઇલ શેરિંગ ચૂપચાપ ખુલ્લું કરી દીધું. ત્રણ શરતો આ જવાબ નક્કી કરે છે, અને સેટિંગને સ્પર્શતા પહેલાં બધી સાચી હોવી જોઈએ.
શ્રેણી ખરેખર શું નક્કી કરે છે
Network Location Awareness દરેક જોડાયેલા નેટવર્ક માટે એડેપ્ટર જે જણાવી શકે તેમાંથી સહી બનાવે છે: ગેટવે સરનામું અને MAC, DNS પ્રત્યય, ડોમેન કંટ્રોલર જવાબ આપે છે કે નહીં, અને નેટવર્ક ઇન્ટરનેટ સુધી પહોંચે છે કે નહીં. Windows એ સહી સાથે પ્રોફાઇલ જોડે છે, અને પછી ફાયરવોલ તે પ્રોફાઇલનો નિયમસમૂહ લાગુ કરે છે. ઓળખ નિષ્ફળ જાય ત્યારે જાહેર એ બેકઅપ છે, તેથી કાર્યરત ટનલ પણ અજાણ્યા નેટવર્ક તરીકે લેબલ થયેલી રહી શકે છે.
TUN અથવા TAP એડેપ્ટર સામાન્ય રીતે ઓળખને ખૂબ ઓછી માહિતી આપે છે. ટનલનો સામેનો છેડો ઘણી વાર ગેટવેને બદલે એક જ સરનામું હોય છે, DNS ફક્ત ટનલની અંદર મોકલાઈ શકે છે, અને એડેપ્ટરનો પોતાનો કોઈ ડિફૉલ્ટ રૂટ હોતો નથી. પરિણામી લેબલ ફાયરવોલના ઇનપુટનું વર્ણન કરે છે, ટનલના સ્વાસ્થ્યનું નહીં, અને એટલે જ VPN કનેક્ટ થાય તે ક્ષણે ખાનગી પ્રોફાઇલના નિયમો મેળ ખાવાનું બંધ કરે છે.
શરત એક: ટનલ એ વિશ્વસનીય માર્ગ છે
ખાનગી પસંદ કરવું એ દાવો છે કે આ ઇન્ટરફેસ દ્વારા પહોંચી શકાય તેવું બધું ઓછામાં ઓછું તમારા પોતાના LAN જેટલું જ વિશ્વસનીય છે, કારણ કે શોધ અને આવક નિયમો તે સબનેટને સ્થાનિક ગણશે. ફાઇલ સર્વર અને પ્રિન્ટરવાળા સંચાલિત સબનેટમાં કોર્પોરેટ ટનલ માટે આ દાવો સામાન્ય રીતે સાચો રહે છે. એડેપ્ટર એ નેટવર્કનું દરવાજો છે જે તમારી સંસ્થા નિયંત્રિત કરે છે, અને બીજી બાજુનું મશીન તે જ નીતિ દ્વારા સ્વીકારાયું છે જેણે તમારું સ્વીકાર્યું.
વ્યાપારી VPN એગ્ઝિટ આ કસોટીમાં પાસ થતું નથી. અન્ય ગ્રાહકો એગ્ઝિટ સબનેટ વહેંચે છે, અને તેને ખાનગી તરીકે ચિહ્નિત કરવાથી નેટવર્ક શોધ, LLMNR અને NetBIOS નામ રિઝોલ્યુશન અજાણ્યાઓથી ભરેલા સેગમેન્ટ પર જાય છે. સ્પ્લિટ ટનલિંગ પણ નિષ્ફળ જઈ શકે છે: જ્યારે એડેપ્ટર એક એપ્લિકેશન માટે એક જ હોસ્ટ રૂટ વહન કરે છે, ત્યારે કોઈ વિશ્વસનીય સબનેટ હોતું નથી, અને શ્રેણી બદલવાથી તમને કંઈ મળતું નથી.
શરત બે: વર્ગીકરણ ફરી કનેક્ટ થવા પર ટકી રહે છે
નવો ગેટવે અથવા DNS પ્રત્યય નવી સહી બનાવે છે, અને Windows તેના માટે નવો પ્રોફાઇલ નિર્ણય લે છે. તેથી એકવારનું Set-NetConnectionProfile આગલા ફરી કનેક્શન સુધી ટકે છે, કાયમ નહીં. પ્રથમ કનેક્શન પછી નહીં, ફરી કનેક્ટ થયા પછી પ્રોફાઇલ તપાસો, કારણ કે ત્યારે જ સેટિંગ જાતે પાછું ફરે છે.
તેને કાયમી બનાવવાની ત્રણ રીતો છે. સૌથી સ્વચ્છ નીતિ છે: secpol.msc ખોલો, Network List Manager Policies પર જાઓ અને નેટવર્ક માટે સ્થાન પ્રકાર સેટ કરો, જેમાં અજાણ્યા નેટવર્કની નીતિ પણ સામેલ છે, જેથી પ્રોફાઇલ આદેશને બદલે નીતિથી લાગુ થાય. બીજી રીત પ્રતિ-કનેક્શન સ્ક્રિપ્ટ અથવા શેડ્યુલ કરેલું કાર્ય છે જે ટનલ ઉપર આવ્યા પછી PowerShell cmdlet ચલાવે છે. ત્રીજી જૂની રૂટ-યુક્તિ છે, જે ઓળખને તપાસવા માટે ગેટવે આપે છે:
route -p add 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 50 IF 24
Get-NetConnectionProfileરૂટ-યુક્તિ એ ઉપાય છે, વર્ગીકરણ નહીં. જ્યારે મેટ્રિક સંબંધ બદલાય અથવા VPN ક્લાયન્ટ ફરી કનેક્ટ થતાં રૂટ ફરી લખે ત્યારે તે તૂટે છે, અને બીજા ડિફૉલ્ટ રૂટ પર પડતી દરેક વસ્તુ માટે માર્ગ-પસંદગી ચૂપચાપ બદલી નાખે છે.
શરત ત્રણ: તમને ખાનગી નિયમસમૂહની જરૂર છે
ખાનગીમાં સામાન્ય રીતે ફાઇલ અને પ્રિન્ટર શેરિંગ, નેટવર્ક શોધ અને દૂરસ્થ વ્યવસ્થાપનના જૂથો આવે છે. જો કાર્ય ટનલ દ્વારા SMB શેર અથવા પ્રિન્ટર સુધી પહોંચવાનું છે, તો શ્રેણી બદલવાનું ખરું કારણ એ જ છે. જો કાર્ય એક વેબ એપ્લિકેશન સુધીની આઉટબાઉન્ડ પહોંચ છે, તો શ્રેણી અપ્રસ્તુત છે: આઉટબાઉન્ડ નિયમ લખો, જાહેર રાખો અને ત્યાં જ અટકો.
| Scenario | Category | Why |
|---|---|---|
| Corporate tunnel to a file server or printer | Private | Private rules carry the sharing you need |
| Commercial VPN for privacy | Public | The exit subnet is shared with strangers |
| Split tunnel with a single host route | Public | No trusted subnet and an unstable signature |
| Site-to-site tunnel to a branch LAN | Private | The far subnet is managed like the local one |
| Lab adapter you control end to end | Private | Discovery helps and nothing else is exposed |
કોષ્ટકને શરૂઆતના બિંદુ તરીકે વાંચો, પછી તપાસો કે તમારા બિલ્ડ પર કયા ખાનગી નિયમો ખરેખર સક્ષમ છે. કઠોર ઇમેજે ખાનગી પ્રોફાઇલમાંથી ફાઇલ શેરિંગ સંપૂર્ણપણે દૂર કર્યું હોઈ શકે, અને તે સ્થિતિમાં નિયમ પાછો ન ઉમેરો ત્યાં સુધી શ્રેણી બદલવાથી કંઈ સધાતું નથી. એ ચકાસણી એક આદેશ લે છે અને લાંબી બપોર બચાવે છે.
બાકી બધું પહોળું કર્યા વિના ફેરફાર કરવો
વાઇલ્ડકાર્ડ નહીં, ઇન્ટરફેસ ઇન્ડેક્સને લક્ષ્ય કરો, અને પહેલાં અને પછી યાદી વાંચો:
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private
Get-NetFirewallProfileસંગ્રહિત પ્રોફાઇલ રજિસ્ટ્રીમાં NetworkList કી હેઠળ રહે છે, જ્યાં Category મૂલ્ય જાહેર, ખાનગી અને ડોમેન નેટવર્કને અલગ કરે છે. તેને સંપાદિત કરવું શક્ય છે અને ભૂલ કરવી સરળ છે: તમારે એડેપ્ટરની વર્તમાન સહી સાથે મેળ ખાતી એન્ટ્રી બદલવી પડશે, અગાઉના સરનામાએ છોડેલી જૂની એન્ટ્રી નહીં. જૂની એન્ટ્રી એડિટરમાં સાચી દેખાય છે અને ફરી કનેક્ટ થવા પર કંઈ કરતી નથી.
તમે ગમે તે કરો, એવી સ્ક્રિપ્ટ શિપ કરશો નહીં જે દરેક અજાણ્યા એડેપ્ટરને ખાનગી બનાવે. તે અવિશ્વસનીય વાયરલેસ પર શોધ ખોલવાની એક-લાઇન આવૃત્તિ છે. જો શેરિંગ ફક્ત ટનલ સબનેટ સાથે જોઈએ, તો પ્રોફાઇલ જાહેર રાખો અને ટનલના દૂરસ્થ સરનામા શ્રેણી સુધી મર્યાદિત આવક નિયમો ઉમેરો; ફાયરવોલ નિયમ શ્રેણી કરતાં સાંકડો છે.
લેબલ નહીં, શેર ચકાસો
ફેરફાર પછી લેબલ પર ભરોસો કરવાને બદલે સંસાધનની જાતને કસોટી કરો:
Test-NetConnection files.corp.example -Port 445
Resolve-DnsName files.corp.exampleજો એડેપ્ટર ખાનગી દર્શાવે છે ત્યારે શેર હજી પણ નિષ્ફળ જાય, તો શ્રેણી હવે તમારી સમસ્યા નથી. નામ રિઝોલ્યુશન, ખૂટતો રૂટ અથવા શેર પરવાનગીઓ એ જ લક્ષણ ઊભું કરશે, અને પ્રોફાઇલ ફરી બદલવાથી તેમાંથી એક પણ સુધરશે નહીં. એક વાર ફરી કનેક્ટ કરો અને સેટિંગ ટક્યું છે તેની ખાતરી કરવા Get-NetConnectionProfile ફરી ચલાવો, પછી બાકીની નિષ્ફળતાને સામાન્ય SMB સમસ્યા તરીકે હલ કરો.
ચેકલિસ્ટ: ખાતરી કરો કે ટનલ સંચાલિત માર્ગ છે, પ્રોફાઇલ ફરી કનેક્ટ પર ટકે છે, જરૂરી ખાનગી નિયમો ઇમેજ પર છે, અને શેર રિઝોલ્વ થઈને પોર્ટ 445 પર જવાબ આપે છે. પહેલા ત્રણમાંથી કોઈ પણ ખોટું હોય તો એડેપ્ટર જાહેર રાખો અને મર્યાદિત નિયમથી પ્રવેશ સમસ્યા હલ કરો.