WireGuard હેન્ડશેક કામ કરે છે પણ ઇન્ટરનેટ નથી: પેકેટને અનુસરો
હેન્ડશેક ફક્ત કી અને પહોંચની સાબિતી આપે છે. AllowedIPs થી ફોરવર્ડિંગ, NAT અને પરત રૂટ સુધી એક પેકેટને અનુસરો અને જુઓ તે ક્યાં અટકે છે.
ટનલ ચાલુ છે, wg show તાજેતરનો હેન્ડશેક બતાવે છે, તમે સર્વરના ટનલ સરનામાંને પિંગ કરી શકો છો, અને તેની આગળ કંઈ જ જવાબ આપતું નથી. સહજ વૃત્તિ કી ફરી બનાવવાની કે કોન્ફિગ ફરી શેર કરવાની હોય છે. તે બરાબર એ જ ભાગ બદલે છે જે પહેલેથી જ કામ કરતો સાબિત થયો છે.
પૂર્ણ થયેલો હેન્ડશેક કહે છે કે બંને પક્ષો કી પર સહમત છે, UDP એન્ડપોઇન્ટ સુધી પહોંચે છે, અને ક્રિપ્ટો રૂટિંગ પેકેટ સ્વીકારે છે. તે એ કહેતું નથી કે પેકેટ પછી સર્વર છોડી શકે છે કે નહીં.
તેથી અનુમાન કરવાને બદલે એક પેકેટને અનુસરો. તે મરી શકે એવી ચાર જગ્યાઓ છે, અને દરેક અલગ નિશાન છોડે છે.
હેન્ડશેક ખરેખર શું સાબિત કરે છે
WireGuard એ UDP પ્રોટોકોલ છે જે Noise હેન્ડશેક સાથે સત્ર સ્થાપે છે અને પછી સાથી માટે પેકેટ એન્ક્રિપ્ટ કરે છે. જ્યારે wg show થોડી સેકન્ડ જૂનો હેન્ડશેક અને વધતો ટ્રાન્સફર કાઉન્ટર દર્શાવે છે, ત્યારે એન્ડપોઇન્ટ, કી અને સાથીની જાહેર કી બધા સાચા છે.
તે જે સાબિત કરતું નથી તે એ છે કે તમારો ક્લાઇન્ટ ઇન્ટરનેટ તરફનો ટ્રાફિક ઇન્ટરફેસમાં મોકલે છે જ, સર્વર તેને ફોરવર્ડ કરવા તૈયાર છે, અથવા જવાબ પરતનો રસ્તો શોધી શકે છે. એ કર્નલ રૂટિંગ અને ફાયરવોલના નિર્ણયો છે, અને તે ટનલની બહાર લેવાય છે.
એટલે જ સર્વરના ટનલ સરનામાંને પિંગ કરવું એટલી ભ્રામક કસોટી છે. તે પેકેટ સર્વરને જ સંબોધિત છે, તેથી તે સ્થાનિક રીતે પૂરું થાય છે. તેને કદી ફોરવર્ડિંગની, કદી અનુવાદની અને કદી ઇન્ટરનેટથી પરત રૂટની જરૂર પડતી નથી.
AllowedIPs એ રૂટિંગ નિર્ણય છે
ક્લાઇન્ટ પર AllowedIPs બે કામ કરે છે. તે ક્રિપ્ટોકી રૂટિંગ કોષ્ટક છે જે નક્કી કરે છે કે કયા ગંતવ્ય સરનામાં આ સાથીની ટનલમાં મોકલવા, અને તે સ્રોત સરનામાંની યાદી છે જે સાથી તમારી પાસેથી સ્વીકારશે. જો ક્લાઇન્ટ કોન્ફિગમાં ફક્ત 10.8.0.0/24 હોય, તો જાહેર ગંતવ્યો કદી ઇન્ટરફેસમાં પ્રવેશતા નથી અને તમારો સામાન્ય ડિફોલ્ટ રૂટ તેમને ટનલની બહાર લઈ જાય છે. પછી ટનલ સંપૂર્ણ કામ કરે છે અને તમે ઇચ્છ્યું હોય તેમાંથી કંઈ જ કરતી નથી.
કોન્ફિગ ફાઇલ શું કહે છે તેના બદલે ક્લાઇન્ટે ખરેખર શું ઇન્સ્ટોલ કર્યું તે જુઓ:
wg show wg0 allowed-ipsip route get 1.1.1.1
બીજો આદેશ નિર્ણાયક છે. જો જવાબ તમારા ભૌતિક ઇન્ટરફેસ અને સામાન્ય ગેટવેનું નામ આપે, તો પેકેટ ટનલમાંથી જતું નથી અને સર્વર બાજુનો કોઈ પણ ફેરફાર તેને સુધારશે નહીં. IPv4 માટે 0.0.0.0/0 અને IPv6 માટે ::/0 અલગ રીતે ઉમેરો; એક કુટુંબ માટે બધું પકડતો નિયમ બીજાને તેના મૂળ માર્ગ પર છોડે છે, અને તે કામ કરતી IPv4 ટનલ અને અટકેલી IPv6 શોધનું સામાન્ય કારણ છે.
ગેટવે પર પેકેટ ક્યાં મરે છે
જો રૂટ સાચો હોય અને પેકેટ તો પણ ક્યાંય ન જાય, તો તે સર્વર પર પહોંચે છે અને ત્યાં જ અટકે છે. ચાર તપાસ મોટાભાગના ગેટવેને આવરી લે છે.
ફોરવર્ડિંગ. sysctl net.ipv4.ip_forward 0 પરત આપે તે ક્લાસિક જવાબ છે, અને ઘણા વિતરણો હજી ડિફોલ્ટ રીતે 0 પર છે. તે 1 હોવું જોઈએ, અને રીબૂટ પર અદૃશ્ય થઈ જતા આદેશને બદલે sysctl ફાઇલમાં કાયમી રીતે સેટ કરવું જોઈએ. IPv6 ફોરવર્ડિંગ અલગ સ્વિચ છે.
ફિલ્ટર નીતિ. ડિફોલ્ટ ડ્રોપ નીતિવાળી FORWARD ચેન ટનલનો ટ્રાફિક ફેંકી દેશે જ્યારે હોસ્ટ પોતાને જતા ટ્રાફિકને મંજૂરી આપશે, જે લક્ષણ સાથે બરાબર મેળ ખાય છે. સાચવેલી ફાઇલ નહીં, જીવંત નિયમસમૂહ વાંચો: nft list ruleset અથવા iptables -S.
અનુવાદ કે રૂટિંગ. ખાનગી ટનલ સરનામાં વાપરતા ક્લાઇન્ટને કાં તો સર્વરના બહાર જતા ઇન્ટરફેસ પર સ્રોત NAT જોઈએ, કાં તો રૂટ કરેલું પ્રીફિક્સ જે ઉપરનું નેટવર્ક પરત કરવું જાણે. બંને વચ્ચેની પસંદગી સરનામા યોજનાને અનુસરે છે. જે નેટવર્ક પહેલેથી તમારું પ્રીફિક્સ પરત રૂટ કરે છે તેમાં MASQUERADE ઉમેરવું નુકસાનકારક નથી પણ અર્થહીન છે, અને જ્યાં કોઈ રૂટ નથી ત્યાં તેને છોડી દેવાથી જવાબો અપ્રાપ્ય ખાનગી શ્રેણીને સંબોધિત રહે છે.
પરત માર્ગ. રૂટ કરેલી રચનાઓમાં ઉપરના રાઉટરને તમારા સર્વર તરફ ઈશારો કરતો રૂટ જોઈએ. પ્રદાતાનું નેટવર્ક પણ તેને અવરોધી શકે: કેટલાક ક્લાઉડ ઇન્સ્ટન્સ પર સ્રોત અને ગંતવ્ય તપાસ સક્રિય કરે છે, જે સ્રોત ઇન્સ્ટન્સનું પોતાનું સરનામું ન હોય તેવા પેકેટ શાંતિથી ફેંકી દે છે, જ્યાં સુધી તે તપાસ નિષ્ક્રિય ન થાય.
DNS રૂટિંગ કરતાં અલગ રીતે નિષ્ફળ જાય છે
જાણીતા સરનામે પેકેટ અને નામની શોધ બે અલગ નિષ્ફળતાઓ છે, અને ભૂલના સંદેશા વિરોધી દિશામાં ભ્રમિત કરે છે. જો ping 1.1.1.1 કામ કરે અને બ્રાઉઝર કંઈ લોડ ન કરી શકે, તો રૂટ ઠીક છે અને નામ-નિરાકરણ નથી. જો પિંગ પોતે નિષ્ફળ જાય, તો DNS અસંગત છે અને તમે પાછલા વિભાગમાં પાછા આવ્યા છો.
wg-quick કોન્ફિગમાંની DNS = લાઇનમાંથી રિઝોલ્વર સેટ કરી શકે છે, અને systemd-resolvedનું દરેક લિંક માટે પોતાનું વર્તન છે. જે VPN રિઝોલ્વરને ફક્ત ટનલની અંદર પહોંચી શકાય એવા સરનામાથી બદલે છે તે ટનલ પડે તે ક્ષણે દરેક શોધ નિષ્ફળ કરશે, જે એવું લાગે કે ટનલ ઇન્ટરનેટ તોડી રહી છે.
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
એક ક્રમ જે પુરાવા આપે છે
પહેલા ક્લાઇન્ટ બાજુની તપાસ ચલાવો, કારણ કે તે એક આદેશ છે અને અડધી શક્યતાઓ દૂર કરે છે. પછી ખાતરી કરો કે સર્વર ઇન્ટરનેટ આઉટલેટ તરીકે બનાવેલું છે જ; ખાનગી પ્રવેશ માટે બનાવેલો ગેટવે જાહેર ગંતવ્યો નિષ્ફળ જાય ત્યારે તૂટેલો નથી.
સર્વર પર, ક્લાઇન્ટથી પિંગ મોકલતી વખતે ઇન્ટરફેસ તપાસો: tcpdump -ni wg0 icmp વિનંતી બતાવવી જોઈએ, અને tcpdump -ni eth0 icmp તેને નીકળતું બતાવવું જોઈએ, અનુવાદિત હોય કે ન હોય. જો તે પ્રથમ પર દેખાય અને બીજા પર કદી ન દેખાય, તો અટકાવ સર્વર પર સ્થાનિક છે. જો તે નીકળે અને કોઈ જવાબ પરત ન આવે, તો સમસ્યા ઉપર છે, અને તે બીજી વાત છે.
છેલ્લે એવું કરો કે સુધારો રીબૂટ પછી પણ ટકે. ફોરવર્ડિંગ sysctl ફાઇલમાં, ફાયરવોલ નિયમો તેમને લોડ કરતી સેવામાં, અને ક્લાઇન્ટ રૂટ ઇન્ટરફેસ ઉપાડતા કોન્ફિગમાં હોવા જોઈએ, તમે ભૂલી જશો એવા શેલમાં નહીં. ફરી જોડાઓ, એ જ બે કસોટીઓ ફરી કરો અને કાઉન્ટર ખસે છે તેની ખાતરી કરો.