SMB ફાયરવોલ નિયમમાં LocalSubnet VPN ક્લાયન્ટને આવરી લેતું નથી
LocalSubnet પરવાનગી નિયમ સર્વરની પોતાની સબનેટને આવરે છે, રૂટ કરેલા VPN પૂલને નહીં. અવકાશ પહોળું કરતા પહેલા સર્વર જે સ્રોત સરનામું જુએ છે તેની સરખામણી કરો.
ઓફિસના ડેસ્કટોપ શેર સુધી પહોંચે છે, VPN વપરાશકર્તાઓનો સમય સમાપ્ત થાય છે, અને એ જ ખાતું મોબાઇલ હોટસ્પોટથી કામ કરે છે. શેર પરવાનગીઓ ભાગ્યે જ ફરક પાડે છે; ફાઇલ સર્વર પર પહોંચતું સરનામું સામાન્ય રીતે ફરક પાડે છે. LocalSubnet સુધી મર્યાદિત નિયમ સર્વરની પોતાની જોડાયેલી સબનેટને પ્રવેશ આપે છે, અને અલગથી રૂટ કરેલો VPN પૂલ તેમાંનો એક નથી. બે ડિઝાઇન આ અંતર ભરે છે, અને તે ખૂબ જ અલગ રેકોર્ડ પાછળ છોડે છે.
બે ડિઝાઇન, એક લક્ષણ
પ્રથમ ડિઝાઇન નિયમની રિમોટ સરનામા શરતમાં VPN પૂલ ઉમેરે છે. પછી સર્વર દરેક ક્લાયન્ટનું ટનલ સરનામું જુએ છે, તેથી તેના લોગ એક રિમોટ વપરાશકર્તાને બીજાથી અલગ કરી શકે છે. બીજી ડિઝાઇન VPN ટ્રાફિકને એવા ગેટવે દ્વારા રૂટ કરે છે જે તેને સર્વર જોતા પહેલા LAN સરનામામાં અનુવાદિત કરે છે. તે કનેક્ટિવિટી પુનઃસ્થાપિત કરે છે અને એ જ પગલામાં ભેદ દૂર કરે છે.
કોષ્ટક સરનામાંને બદલે ભૂમિકાઓનું વર્ણન કરે છે, અને તમારા પોતાના પ્રીફિક્સ નક્કી કરે છે કે કઈ પંક્તિ લાગુ પડે છે. બ્લોગ પોસ્ટમાંથી ઉદાહરણ કોપી કરવાને બદલે સર્વરના વાસ્તવિક મૂલ્યો છાપો:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthકોષ્ટક નિર્ણય માટેની સહાય છે, દરેક જમાવટ વિશેનું નિવેદન નથી. વધારાના ઇન્ટરફેસ, બીજી સાઇટ લિંક અથવા અલગ માસ્ક ધરાવતા હોસ્ટનો સ્થાનિક સમૂહ અલગ હોય છે.
| Path the packet takes | Address the server records | Filter scope that admits it | What the log can still tell you |
|---|---|---|---|
| Desktop on the server LAN | Its own LAN address | LocalSubnet or the LAN prefix | Which workstation connected |
| Client on the routed VPN pool | Its tunnel address | The VPN pool as a remote address | Which VPN account connected, if the pool is logged |
| Client behind source NAT at the gateway | The gateway's LAN address | The gateway address | Only that some VPN user connected |
| Site-to-site gateway | The remote gateway's tunnel address | The remote site's prefix | Which site connected, not which user |
Microsoftનું New-NetFirewallRule સંદર્ભ રિમોટ સરનામા શરતો અને LocalSubnet કીવર્ડનું દસ્તાવેજીકરણ કરે છે. કીવર્ડનો અર્થ બધા ખાનગી સરનામાં એમ નક્કી કરતા પહેલા તેને વાંચો, કારણ કે તેનો અર્થ એ નથી.
સર્વર ખરેખર શું મેળવે છે તેની સરખામણી કરો
કોઈએ બનાવ્યું હોવાનું યાદ રાખેલા નિયમને બદલે અસરકારક નિયમ વાંચો. તે સક્ષમ છે, સક્રિય પ્રોફાઇલ પર લાગુ પડે છે, અને તેની રિમોટ સરનામા શરત સર્વર જે સ્રોત જુએ છે તેની સાથે મેળ ખાય છે તેની ખાતરી કરો. ફક્ત Domain પ્રોફાઇલ પર સક્ષમ નિયમ ત્યારે કંઈ કરતું નથી જ્યારે નેટવર્ક ફેરફાર પછી એડેપ્ટર Public પર ખસી ગયું હોય.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionપ્રથમ આદેશ ફાઇલ શેરિંગ નિયમો સાથે જોડાયેલા સરનામા ફિલ્ટર છાપે છે, અને બીજો બતાવે છે કે કઈ પ્રોફાઇલ સક્રિય છે અને ન મળતા ઇનબાઉન્ડ ટ્રાફિક સાથે કેવી રીતે વ્યવહાર થાય છે. બ્લોકિંગ નિયમ અને કેન્દ્રીય રીતે સંચાલિત નીતિ પણ શોધો. બ્લોક નિયમો પરવાનગી નિયમો પર પ્રાધાન્ય ધરાવે છે, અને સ્થાનિક નિયમ મર્જિંગ બંધ કરતી નીતિ નવા સ્થાનિક અપવાદને નિષ્ક્રિય બનાવી શકે છે.
એ એવો કિસ્સો છે જ્યાં નિયમ કન્સોલમાં સાચો દેખાય છે અને ટ્રાફિક પર કોઈ અસર થતી નથી. તે જ સમયે પ્રોફાઇલ સોંપણી તપાસો, કારણ કે બીજા નેટવર્કમાં જોડાયેલું લેપટોપ કોઈ ફાયરવોલને સ્પર્શ્યા વિના Public પ્રોફાઇલ પર જઈ શકે છે.
લોગિન પહેલાં ટ્રાન્સપોર્ટની કસોટી કરો
પહોંચને ઓથેન્ટિકેશનથી અલગ કરો. TCP 445 પરનો લિસ્ટનર સાબિત કરે છે કે સેવા પોર્ટ સાથે બંધાયેલી છે; તે સાબિત કરતું નથી કે રિમોટ પેકેટ તે સુધી પહોંચી શકે છે. પૂર્ણ થયેલું TCP કનેક્શન, બીજી બાજુ, SMB સત્ર સેટઅપ કે શેર પરવાનગીઓ વિશે હજી કંઈ કહેતું નથી. નિયમ સંપાદિત કરતા પહેલા બંને બાજુથી હેન્ડશેકની કસોટી કરો.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailedપ્રથમ આદેશ જણાવે છે કે જે મશીન પર તમે તેને ચલાવો છો ત્યાંથી TCP હેન્ડશેક સફળ થાય છે કે નહીં, અને બીજો ઉકેલાયેલું સરનામું અને ઇન્ટરફેસ વિગતો ઉમેરે છે. તેને VPN ક્લાયન્ટ અને ઓફિસ ડેસ્કટોપથી ચલાવો, પછી સરખામણી કરો. Ping બંને પ્રશ્નોનો જવાબ આપતું નથી, કારણ કે SMB ખુલ્લું હોય ત્યારે ICMP બ્લોક થઈ શકે છે, અથવા ફાયરવોલ 445 ડ્રોપ કરે ત્યારે તેને પરવાનગી હોઈ શકે છે.
જો હેન્ડશેક ફક્ત VPNથી નિષ્ફળ જાય, તો સ્રોત અવકાશ મુખ્ય શંકાસ્પદ છે. જો તે સફળ થાય અને શેર હજી પણ તમને નકારે, તો ફાયરવોલ નિયમો સંપાદિત કરવાને બદલે SMB સત્ર અને પરવાનગી નિદાન તરફ આગળ વધો.
જ્યારે સ્રોત NAT ભેદ દૂર કરે છે
માર્ગમાં અનુવાદ હોય ત્યારે સર્વર વ્યક્તિગત VPN ક્લાયન્ટને સરનામા દ્વારા અલગ કરી શકતું નથી. દરેક રિમોટ વપરાશકર્તા ગેટવે તરીકે આવે છે. તેમને અલગ પાડવા પર આધારિત કોઈપણ અધિકૃતતા ત્યાં લાગુ થવી જોઈએ જ્યાં તેમની ઓળખ હજી દેખાય છે, જેનો સામાન્ય અર્થ VPN કોન્સન્ટ્રેટર અથવા ઓથેન્ટિકેટિંગ પ્રોક્સી છે. ફાયરવોલ નિયમ ટ્રાફિકને પ્રવેશ આપી શકે છે; અનુવાદે દૂર કરેલો ભેદ તે પુનઃસ્થાપિત કરી શકતું નથી.
એ ગેટવે સરનામું મંજૂર થયા પછી, દરેક રિમોટ વપરાશકર્તા એક જ સરનામા હેઠળ નોંધાય છે, તેથી નિયમ ગેટવે સુધી પહોંચી શકતા દરેકને આખો પૂલ આપે છે. જો પ્રતિ-વપરાશકર્તા નિર્ણય મહત્વનો હોય, તો મૂળ સરનામાં દૃશ્યમાન રાખો અથવા નિર્ણયને એવા સ્તર પર ખસેડો જે હજી વપરાશકર્તાને ઓળખે છે. અન્યથા દરેક રિમોટ વપરાશકર્તા સર્વર જોઈ શકે તે એક જ સરનામાની પરવાનગીઓ વારસામાં મેળવે છે, અને ઓડિટ ટ્રેલ તેમને પછીથી અલગ કરી શકતું નથી. તે ડિઝાઇન નિર્ણય છે, ફાયરવોલની વિગત નથી.
બે ડિઝાઇન વચ્ચે જાણી જોઈને પસંદ કરો. જ્યારે સર્વરને જોવું હોય કે કોણ જોડાયું છે ત્યારે નિયમને વાસ્તવિક VPN પૂલ સુધી મર્યાદિત કરો, અને અનુવાદિત માર્ગ ત્યારે જ સ્વીકારો જ્યારે સર્વરને ખરેખર તે માહિતીની જરૂર ન હોય. પસંદ કરેલી સ્રોત શ્રેણી નિયમની બાજુમાં નોંધો, કારણ કે આને ડિબગ કરનાર આગળની વ્યક્તિ પહેલાં સરનામા કોષ્ટક જોશે.