RDP માટે મંજૂરીનો નિયમ ઉમેરવાથી તમારી VPN ઍક્સેસ સાંકડી થતી નથી

યોજના વાજબી લાગે છે: હાલની રિમોટ ડેસ્કટોપ મંજૂરીને જેમ છે તેમ રહેવા દો અને જે એકમાત્ર VPN ક્લાયન્ટને ઍક્સેસ હોવો જોઈએ તેના માટે નાની મંજૂરી ઉમેરો. Windows Firewall એ રીતે કામ કરતું નથી. નિયમો એ ક્રમમાં ગોઠવેલી યાદી નથી જેમાં સૌથી ચોક્કસ પ્રવેશ જીતે છે, અને પહોળી મંજૂરીની બાજુમાં સાંકડી મંજૂરી કંઈ બદલતી નથી, કારણ કે પહોળી મંજૂરી હજી પણ જેમને પહેલેથી પ્રવેશ આપતી હતી તેમને આપે છે. સેવાને સાંકડી કરવાનો અર્થ એ છે કે જે મંજૂરી પહેલેથી કામ કરી રહી છે તેને સંપાદિત કરવી.

તમે ઉમેરો છો તે નિયમ મહત્ત્વનો નિયમ નથી

Windows Firewall મશીન પર લાગુ પડતા પોલિસી સ્ટોરમાંના બધા લાગુ પડતા ઇનબાઉન્ડ નિયમોનું મૂલ્યાંકન કરે છે, પછી નક્કી કરે છે કે કોઈ મંજૂરી મેળ ખાય છે કે નહીં અને કોઈ બ્લોક તેને વટાવે છે કે નહીં. નિયમ ઉમેરવાથી મંજૂરી ઉમેરાય છે; તે પહેલેથી હાજર મંજૂરીઓને દૂર કરતું નથી કે મર્યાદિત કરતું નથી.

તેથી પ્રશ્ન ક્યારેય એ નથી કે તમે શું ઉમેર્યું. પ્રશ્ન એ છે કે અસરકારક પોલિસીમાં શું છે સ્થાનિક પોલિસી, ડોમેન પોલિસી અને પ્રોફાઇલના ડિફૉલ્ટ એકઠા થયા પછી. એક સ્થાનિક નિયમ ધરાવતું વર્કસ્ટેશન સમજવું સરળ છે; ડોમેન સાથે જોડાયેલ સર્વર નહીં.

એટલે જ વ્યવસ્થાપક યોગ્ય દેખાતો ફેરફાર કરી શકે છે, તેને ખોટા મશીનથી ચકાસી શકે છે અને નિષ્કર્ષ કાઢી શકે છે કે તે કામ કરી ગયો. બાકાત કરેલા સ્રોતની ક્યારેય ચકાસણી થઈ નહોતી. જે પરીક્ષણ ફક્ત સફળતા સાબિત કરે છે તે ફેરફાર જેના માટે હતો તેના અડધાથી પણ ઓછું સાબિત કરે છે.

સર્વર કયું સરનામું જુએ છે તે શોધો

કંઈપણ મર્યાદિત કરતાં પહેલાં, Windows હોસ્ટ પર એક મંજૂર સત્રનું નિરીક્ષણ કરો અને સર્વર જે સ્રોત સરનામું જણાવે છે તે નોંધો. તે હંમેશા એ સરનામું નથી જે ક્લાયન્ટ માને છે કે તેની પાસે છે.

જો VPN ગેટવે ક્લાયન્ટ સરનામાં જાળવી રાખે છે, તો સર્વર ક્લાયન્ટનું ટનલ સરનામું જુએ છે, અને સરનામાથી મર્યાદિત નિયમ અર્થપૂર્ણ છે. જો ગેટવે અનુવાદ કરે છે, તો દરેક ક્લાયન્ટ ગેટવેના સરનામા તરીકે આવે છે, અને તે સરનામા સુધી મર્યાદિત કરવાથી તેની પાછળના દરેક ક્લાયન્ટને ઍક્સેસ મળે છે. ત્યારે નિયમ ખોટી વસ્તુ વિશે ચોક્કસ છે.

તે બે ડિઝાઇનને જુદા જુદા જવાબોની જરૂર છે. પહેલું ફાયરવૉલ નિયમમાં વ્યક્ત કરી શકાય છે; બીજું ત્યાં લાગુ કરવું પડે જ્યાં ઓળખ હજી અસ્તિત્વમાં છે, એટલે કે VPN પોતે અથવા સેવાની સામેનું પ્રમાણિત ગેટવે.

નેટવર્ક અનુવાદે ફેંકી દીધેલી ઓળખ ફાયરવૉલ ફિલ્ટર પાછી લાવી શકતું નથી, સરનામું ગમે તેટલી કાળજીથી લખાયું હોય.

અસરકારક નિયમનો માલિક બદલો

અસરકારક ઇનબાઉન્ડ પોલિસીની તપાસ કરો અને હાલમાં RDP ટ્રાફિક મંજૂર કરતો દરેક નિયમ શોધો, જેમાં એવા નિયમોનો પણ સમાવેશ થાય છે જેમના દર્શાવેલા નામમાં ક્યારેય પોર્ટ 3389નો ઉલ્લેખ નથી. સેવા-મર્યાદિત અને એપ્લિકેશન-મર્યાદિત નિયમો પણ ગણાય છે, અને કેટલીક RDP જમાવટ સક્ષમ કરે તેવું UDP પરિવહન પણ.

પછી હાલના નિયમોને જે સ્ટોર તેમનો માલિક છે તેના દ્વારા સંપાદિત કરો. ડોમેન પોલિસી પણ વ્યાખ્યાયિત કરે તેવા નિયમમાં સ્થાનિક સંપાદન ભેગું થઈ શકે, અવગણાઈ શકે અથવા ફરી લખાઈ શકે, અને તેના પર આધાર રાખતા પહેલાં કયું બને છે તે જાણવું યોગ્ય છે.

આ આદેશો સક્રિય નિયમો શોધે છે, તેમાંથી એક સાથે જોડાયેલ સરનામા ફિલ્ટર બતાવે છે અને અવકાશના ફેરફારનું પૂર્વાવલોકન કરે છે:

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

અહીંના નિયમના નામો સમીક્ષામાં જે મળ્યું તેના પ્લેસહોલ્ડર છે, અને પૂર્વાવલોકન ફ્લેગ એટલા માટે છે કે સરનામામાં ટાઇપો તમને તમે સંપાદિત કરી રહ્યા છો તે સર્વરની બહાર ન કરી દે.

પહેલાં બ્લોક પછી મંજૂરી એ જુદું મોડેલ છે

બીજા ફાયરવૉલની ટેવ પહોળો બ્લોક લખવાની અને પછી તેની ઉપર સાંકડી મંજૂરી આપવાની છે. Windows માં સ્પષ્ટ બ્લોક સામાન્ય રીતે મંજૂરી પર જીતે છે, તેથી આ ક્રમ એક ક્લાયન્ટ માટે અપવાદને બદલે એવી સેવા બનાવે છે જ્યાં કોઈ પહોંચી શકતું નથી. પરિણામ એ વિક્ષેપ છે જે તૂટેલી RDP સેવા જેવો લાગે છે. તે વાસ્તવમાં અગ્રતાની ભૂલ છે, અને ઉપાય બીજી મંજૂરી ઉમેરવાનો નહીં પણ બ્લોક દૂર કરવાનો છે.

સક્રિય પ્રોફાઇલ પર ડિફૉલ્ટ ઇનબાઉન્ડ બ્લોક વર્તન રાખો અને તેના બદલે ચોક્કસ મંજૂરીઓ સાંકડી કરો. તે મશીનને બે વિરોધાભાસી નિયમોને બદલે એક સમજી શકાય તેવી સ્થિતિમાં રાખે છે, જેમની પરસ્પર ક્રિયા અગ્રતાની વિગતો પર આધાર રાખે છે.

બીજા સ્રોતથી સાબિત કરો

મંજૂર ક્લાયન્ટથી અને હવે નિષ્ફળ થવો જોઈએ તેવા સ્રોતથી પરીક્ષણ કરો. એક જ સફળ જોડાણ ફક્ત એ સાબિત કરે છે કે મંજૂર માર્ગ કામ કરે છે; તમે હમણાં જે બાકાત કર્યું તેના વિશે તે કંઈ કહેતું નથી.

જો સર્વર પર તે સક્ષમ હોય તો IPv6 પર પરીક્ષણનું પુનરાવર્તન કરો, કારણ કે ફક્ત IPv4 માટેનો ઇરાદો પહોળી IPv6 મંજૂરી સાથે સહઅસ્તિત્વ ધરાવી શકે છે જેને કોઈએ જોઈ નથી.

અંતે, પ્રમાણીકરણને પહોંચશક્તિથી અલગ રાખો. નેટવર્ક સ્તરનું પ્રમાણીકરણ, ખાતાના અધિકારો અને લોગિન મર્યાદાઓ હજી પણ નક્કી કરે છે કે કોણ સત્રનો ઉપયોગ કરી શકે, અને ફાયરવૉલ ફક્ત નક્કી કરે છે કે કોણ પૂછી શકે. પછીથી ઉપકરણ દૂર કરવાથી તેની VPN નોંધણી અને આ નેટવર્ક પરવાનગી બંને દૂર થવી જોઈએ, નહીંતર તમે મર્યાદિત કરેલું સરનામું એક દિવસ બીજા કોઈનું થઈ જશે.