પિંગ ફક્ત એક જ દિશામાં કામ કરે છે: Windows સર્વરનો ઇકો કેમ કાઢી નાખે છે

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

બે દિશાઓ, બે અલગ નિર્ણયો

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

જ્યારે સર્વર પહેલા વિનંતી મોકલે છે, ત્યારે કોઈ સ્થિતિ તેની સાથે મેળ ખાતી નથી. Windows પેકેટને નવા આવતા જોડાણ તરીકે ગણે છે અને આવતી નીતિને પૂછે છે, જે મૂળભૂત રીતે મનસ્વી સ્રોતોમાંથી આવતી ઇકો વિનંતીઓ માટે કોઈ જોગવાઈ ધરાવતી નથી.

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

પેકેટ અદૃશ્ય થાય ત્યાં સુધી અનુસરો

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

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

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

ICMP ખોલવાને બદલે એક નિયમ મર્યાદિત કરો

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

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

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

નિયમ શું આવરી લેતો નથી

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

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

પરિણામ સાચી દિશામાં વાંચો

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

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

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