શા માટે VPN સ્થિતિ સાથે જોડાયેલ ફાયરવોલ ગેટ ફક્ત ping નો નિયમ નથી

એક ફાયરવોલ નિયમની કલ્પના કરો જે નામ આપેલ VPN પ્રોફાઇલ જોડાયેલ હોય ત્યારે સર્વરના જાહેર સરનામા માટે ICMP echo ચાલુ કરે છે. તે “ફક્ત ટનલ દ્વારા ping” જેવું વંચાય છે, અને તે વાંચન એવી રીતે ખોટું છે જે મહત્વનું છે. નિયમ એ મર્યાદિત કરતું નથી કે કોણ હોસ્ટ સુધી પહોંચી શકે; તે બદલે છે કે જાહેર ઇન્ટરફેસ શાનો જવાબ આપે છે, જ્યારે બીજું કનેક્શન કોઈ સમયે ચાલુ હોય. આ બે અલગ નીતિઓ છે, અને તેમાંથી એક શાંતિથી જોખમ વધારે છે.

તમે લખ્યો હોવાનું માનો છો તે નિયમ

ઇચ્છિત જરૂરિયાત સામાન્ય રીતે સાંકડી હોય છે: મોનિટરિંગ સિસ્ટમ, અથવા VPN પરનો એકમાત્ર વ્યવસ્થાપક, ખાતરી કરી શકે કે સર્વર જીવંત છે. વાક્ય તરીકે લખાય ત્યારે તે ટનલ પર પ્રવેશ નિયંત્રણ જેવું સંભળાય છે. ફાયરવોલ ઑબ્જેક્ટ તરીકે લખાય ત્યારે તે જાહેર પ્રોફાઇલ પરની શરત બની જાય છે, કારણ કે echo વિનંતી ત્યાં જ આવે છે.

શરત સ્રોત સરનામા કરતાં કનેક્શનની સ્થિતિ બની જાય પછી, મંજૂર પ્રેષકોનો સમૂહ હવે VPN સાથીઓનો સમૂહ નથી. જે કોઈ જાહેર સરનામા સુધી પહોંચી શકે તે ગેટ ખુલ્લું હોય ત્યારે echo વિનંતી મોકલી શકે છે. ટનલ માર્ગ ન બની; ટનલ સ્વિચ બની ગઈ.

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

ગેટ ખરેખર શું નિયંત્રિત કરે છે

આ રચના બે સ્વતંત્ર બાબતોને ભેગી કરે છે, અને તેમને અલગ કરવું એ સુધારાનો મોટો ભાગ છે. પ્રથમ છે વ્યાપ્તિ: કયું સ્થાનિક સરનામું, કયા દૂરસ્થ સરનામાં, કયો પ્રોટોકોલ અને કયો ICMP પ્રકાર. બીજું છે શરત: આ ક્ષણે નિયમનું ઑબ્જેક્ટ સક્ષમ છે કે નહીં. વ્યાપ્તિ એ છે જે ફાયરવોલ દરેક પેકેટ માટે મૂલ્યાંકન કરે છે; શરત એ છે જે સ્ક્રિપ્ટ નીતિ ભંડારમાં લખે છે, અને બંને સંપૂર્ણપણે જુદી ઘડિયાળો પર સમન્વયિત થાય છે.

જો જરૂરિયાત ખરેખર ફક્ત VPN સાથીઓની હોય, તો વ્યાપ્તિ કોઈ પણ કનેક્શન-સ્થિતિ તર્ક વિના તેનો જવાબ આપે છે: નિયમને ટનલ ઇન્ટરફેસ અથવા ટનલ સરનામા શ્રેણી સાથે જોડો, દૂરસ્થ સરનામાંને ક્લાયન્ટ પૂલ સુધી મર્યાદિત કરો, અને “ICMP”ને બદલે echo પ્રકાર નિર્દિષ્ટ કરો. કોઈ VPN ચાલુ ન હોય ત્યારે પણ તે નિયમ સાચો રહે છે અને અસંબંધિત પ્રોફાઇલ તેને ખોલી શકતું નથી.

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

ઑબ્જેક્ટ એક વાર બનાવો, પછી તેને ટૉગલ કરો

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

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

નામ એ ટકાઉ ઓળખકર્તા છે; દર્શાવેલ નામ એ દસ્તાવેજીકરણ છે જે માણસ સંપાદિત કરી શકે. -Name પર સમન્વય કરો અને સ્ક્રિપ્ટ નકલો બનાવવાનું બંધ કરશે. એ જ આદેશ આકાર IPv6 કિસ્સાને -Protocol ICMPv6 -IcmpType 128 સાથે આવરી લે છે, પરંતુ તે અલગ નિયમ છે કારણ કે echo પ્રકારની સંખ્યાઓ બે કુટુંબો વચ્ચે અલગ છે.

સરનામા કુટુંબ અને ICMP પ્રકાર સ્પષ્ટ રાખો બીજા કારણસર: -Protocol ICMPv4 પ્રકાર વિના પ્રોફાઇલ મંજૂર કરે તેવા દરેક ICMPv4 સંદેશને મંજૂર કરે છે, જેમાં તે પણ છે જે તમે ક્યારેય સ્વીકારવા માંગ્યા ન હતા. પ્રકાર 8 નું નામ આપવું નિયમને echo વિનંતી સુધી સાંકડો કરે છે, અને પહોંચ-તપાસ ફક્ત તે જ મોકલે છે.

જ્યાં સ્વયંસંચાલન ઇરાદાનો વિરોધ કરે છે

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

સ્થિતિ-તપાસમાં જ વ્યાપ્તિનો સપાટો છે. Get-VpnConnection મશીન પર ગોઠવાયેલા ક્લાયન્ટ પ્રોફાઇલની જાણ કરે છે, મૂળભૂત રીતે વર્તમાન વપરાશકર્તા માટે અને -AllUserConnection સાથે બધા વપરાશકર્તાઓ માટે. તે RRAS સર્વર પર અત્યારે ડાયલ-ઇન કરેલા દૂરસ્થ વપરાશકર્તાઓની જાણ કરતું નથી; તે બીજા આદેશ સાથેનું બીજું અવલોકન છે. ખોટા પર બનેલો ગેટ કોઈની સાથે જોડાયેલો નથી.

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

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