UDP સ્કેન કહે છે ફિલ્ટર કરેલું: શું તમારો WireGuard સાથી ખરેખર બંધ છે?

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

તેના બદલે ક્લાયન્ટમાંથી બહારની તરફ કામ કરો, અને સ્કેનને ઘણા નબળા ડેટા બિંદુઓમાંથી એક ગણો.

સ્કેનર શું જોઈ શકે છે અને શું નહીં

UDP સ્કેનર એક પેલોડ મોકલે છે અને રાહ જુએ છે. જો ICMP port-unreachable પાછું આવે, તો તે પોર્ટને બંધ જાહેર કરી શકે છે. જો કંઈ પણ પાછું ન આવે, તો પરિણામ રચનાથી જ અસ્પષ્ટ છે: ફિલ્ટર કરેલો માર્ગ, ગેરહાજર હોસ્ટ અને ચાલુ સેવા જેણે પેલોડને અવગણ્યું, બધા એક જ મૌન ઉત્પન્ન કરે છે. ત્રણ જુદી જુદી સ્થિતિઓ, એક જ આઉટપુટ સ્ટ્રિંગ.

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

એ જ પોર્ટ નંબર પર TCP કસોટી કંઈ સંબંધિત ચકાસતી નથી. તે બીજા શ્રોતાને ચલાવે છે જે કદાચ અસ્તિત્વમાં ન હોય, અને તેનો ઇનકાર UDP વિશે કંઈ કહેતો નથી.

તેથી ખુલ્લી ફિલ્ટર કરેલી સ્થિતિઓ તમારા સર્વર કરતાં સ્કેનરની અનિશ્ચિતતાને વધુ સચોટ રીતે વર્ણવે છે.

સાચા ક્લાયન્ટને પ્રોફાઇલથી અંદર સુધી ચાલો

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

પછી ત્રીજા સ્થળેથી અલગ સ્કેન ચલાવવાને બદલે, એક અધિકૃત કોશિશ દરમિયાન સર્વરની બાજુ જુઓ:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

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

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

જ્યારે તમે સર્વરનું સંચાલન કરો ત્યારે ત્યાં જ સહસંબંધ જોડો

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

સરનામું પોર્ટ જેટલું જ મહત્વનું છે. ચોક્કસ સરનામા પર સાંભળતું સર્વર બીજા સરનામે આવેલા પેકેટનો જવાબ આપશે નહીં, અને ઘણા ઇન્ટરફેસવાળું હોસ્ટ તપાસ તમારા ઇરાદા ન હોય તેવા ઇન્ટરફેસ પર લઈ શકે છે.

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

સ્કેનના પરિણામને પ્રામાણિકતાથી વાંચવું

સ્કેન એ હોસ્ટ અસ્તિત્વમાં છે અને પોર્ટને કોઈ વચ્ચેનું ઉપકરણ સ્પષ્ટપણે રોકતું નથી તે ચકાસવાનો સસ્તો રસ્તો છે. આ ચકાસાયેલા પ્રોટોકોલ માટે પહોંચનો પુરાવો નથી, અને ચોક્કસપણે કન્ફિગરેશનની કસોટી નથી.

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

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