WireGuard હેન્ડશેક કામ કરે છે, સેવા નહીં

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

જે પહેલું ન મળે ત્યાં થોભો, અને બાકીનાના માટે નિયમો ઉમેરશો નહીં.

હેન્ડશેક ફક્ત ટનલ સાબિત કરે છે

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

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

શ્રોતા અને માર્ગ વાંચો

ક્લાયન્ટ પર ખાતરી કરો કે સર્વરનું ટનલ સરનામું ટનલમાં રૂટ થાય છે. સર્વર પર ખાતરી કરો કે ક્લાયન્ટ જે સરનામું વાપરે છે ત્યાં સોકેટ અસ્તિત્વમાં છે, અને તેની પાછળની પ્રક્રિયા તમે ઇચ્છતા હતા તે જ છે.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

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

ક્લાયન્ટ જે સરનામું વાપરે છે તેની સરખામણી સર્વર ટનલ ઇન્ટરફેસ પર ખરેખર ધરાવતું સરનામું સાથે કરો. કોઈપણ બાજુની જૂની ગોઠવણી એવી વિનંતી બનાવે છે જે યોગ્ય રીતે એવા પીઅર તરફ રૂટ થાય છે જેની પાસે એ સરનામું નથી.

સ્થાનિક ઇનપુટ માટે નિયમો લાગુ કરો, ફોરવર્ડિંગ માટે નહીં

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

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

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

નામ, કદ અને ઓળખની નિષ્ફળતા અલગ કરો

જે સેવા સરનામા પર કામ કરે છે પણ નામ પર નિષ્ફળ જાય છે તે DNS સમસ્યા છે, અને સુધારો ફાયરવોલમાં નહીં, ક્લાયન્ટને મોકલાતી રિઝોલ્વર ગોઠવણીમાં છે. જે સેવા નાની વિનંતીઓનો જવાબ આપે છે પણ મોટા પ્રતિભાવો પર અટકે છે તે પેકેટ કદ અને MTU તરફ ઇશારો કરે છે, જે સંપૂર્ણપણે અલગ તપાસ છે.

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

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