WireGuard મોબાઇલ ડેટા પર ચાલે છે, પણ એ જ Wi-Fi પર ચાલતું નથી
LANની અંદરથી રાઉટરના જાહેર સરનામે જતી વિનંતી મોબાઇલ ડેટાની વિનંતી કરતાં જુદો રસ્તો લે છે. પહેલાં બહારથી પરીક્ષણ કરો, પછી સ્થાનિક રસ્તો પસંદ કરો.
મોબાઇલ ડેટા પર ટનલ ઊપર આવે છે અને પછી ઘરે એ જ પ્રોફાઇલ, એ જ પીઅર કી અને વચ્ચે કોઈ કન્ફિગરેશન ફેરફાર વગર તે કનેક્ટ થઈ રહ્યું છે એ સ્થિતિમાં બેસી રહે છે. ફરક મુસાફરીમાં છે: LANની અંદરથી રાઉટરના જાહેર સરનામે જતી વિનંતી ઇન્ટરનેટ પરથી આવતી વિનંતી જેવી એ જ સફર નથી. મોટા ભાગના ઘરેલું ગેટવે ક્યાં તો પરત માર્ગ અમલમાં મૂકતા નથી, ક્યાં તો તેને ફક્ત અમુક પ્રોટોકોલ માટે જ અમલમાં મૂકે છે. એથી લક્ષણ તૂટેલી કી જેવું લાગે છે, જ્યારે કી વિશે કંઈ જ બદલાયું નથી. કી, પોર્ટ ફોરવર્ડ કે ક્લાઇન્ટ પ્રોફાઇલને અડકતા પહેલાં નક્કી કરો કે કયો રસ્તો નિષ્ફળ ગયો.
એક સરનામું, બે જુદા રસ્તા
બહારથી પેકેટ રાઉટરના જાહેર સરનામે પહોંચે છે અને પોર્ટ-ફોરવર્ડ નિયમ તેને આંતરિક હોસ્ટ પરના WireGuard લિસનરને સોંપે છે. અંદરથી ક્લાઇન્ટ એ જ જાહેર સરનામું ડાયલ કરે છે, તેથી પેકેટ ક્લાઇન્ટમાંથી નીકળે છે, રાઉટરે પહોંચે છે અને પાછું LAN તરફ વાળવું પડે છે. એ પરત વળાંક પર જ બે રસ્તા અલગ પડે છે, કારણ કે રાઉટરે એવો ફ્લો અનુવાદિત કરવો પડે છે જે એક જ ઇન્ટરફેસમાંથી નીકળે અને ફરી એમાં જ પ્રવેશે. ઘણા અમલીકરણો અનુવાદ કરવાને બદલે તેને છોડી દે છે, અને પછી ક્લાઇન્ટ એવા હેન્ડશેકની રાહ જુએ છે જે કદી મોકલાયો જ નહોતો.
આ વર્તનને સામાન્ય રીતે NAT લૂપબેક કે હેરપિનિંગ કહેવાય છે, અને એ WireGuardનું નહીં, રાઉટરનું લક્ષણ છે; RFC 4787 એ અનુવાદના કેસ ગણાવે છે જેમાં ગેટવે તેને ટેકો આપી શકે કે નહીં. WireGuard પોતે માર્ગ વિશે કોઈ મત ધરાવતું નથી, કારણ કે તે ફક્ત એ જ પેકેટ જુએ છે જે તેના ઇન્ટરફેસ સુધી પહોંચે છે. રાઉટર ફ્લો છોડી દે ત્યારે ડીમનને કંઈ જ મળતું નથી, ક્લાઇન્ટ હેન્ડશેક ટાઇમઆઉટ જણાવે છે અને સર્વર લોગ ખાલી રહે છે. તેથી ખાલી લોગ એ પેકેટ ક્યાં અટક્યું તેની ચાવી છે, સર્વર બંધ છે તેનો પુરાવો નહીં. એટલે જ ફરી ઇન્સ્ટોલ કરવાથી કંઈ બદલાતું નથી.
ઊલટું પણ મહત્વનું છે: LAN સરનામેથી હેન્ડશેકનો પ્રયાસ દર્શાવતો સર્વર લોગ સાબિત કરે છે કે પેકેટ પહોંચ્યું અને માર્ગ બરાબર છે, જે તપાસને કી અને માન્ય સરનામાં તરફ લઈ જાય છે. લોગ એ સાબિત કરવા માટે વાંચો જે તે સાબિત કરે છે, તમે જોવાની આશા રાખી હતી તે માટે નહીં.
કંઈ બદલતા પહેલાં તેને ફરી ઉત્પન્ન કરો
એ જ ઉપકરણ અને એ જ પ્રોફાઇલ સાથે અધિકૃત બાહ્ય નેટવર્કથી પરીક્ષણ કરો, પછી કંઈ પણ બદલ્યા વગર LANની અંદર પરીક્ષણનું પુનરાવર્તન કરો. બહાર પૂર્ણ થયેલો હેન્ડશેક અને અંદર ઉપકરણ છોડ્યા વગરનો ક્લાઇન્ટ અનુમાનને બદલે સ્થિતિનું પુનરુત્પાદન કરે છે. બંને પ્રયાસે એક જ પ્રોફાઇલ વાપરવું પડે, નહીં તો સરખામણી કંઈ સાબિત કરતી નથી.
પછી જુઓ કે આ ઉપકરણ માટે એન્ડપોઇન્ટ નામ કયા સરનામે રિઝોલ્વ થાય છે. આ ત્રણ આદેશ એ પણ દર્શાવે છે કે ક્લાઇન્ટ ખરેખર કયું સરનામું ડાયલ કર્યું:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netપહેલો આદેશ જણાવે છે કે ઇન્ટરફેસ હાલ કયો એન્ડપોઇન્ટ વાપરે છે, અને બાકીના બે દર્શાવે છે કે આ મશીન પર નામ કયા સરનામે રિઝોલ્વ થાય છે. સર્વરની જ નેટવર્ક પર બેસીને જાહેર સરનામું ડાયલ કરતો ક્લાઇન્ટ હેરપિન માર્ગ વાપરે છે. LAN સરનામું ડાયલ કરતો ક્લાઇન્ટ એમ કરતો નથી, અને ત્યાંની નિષ્ફળતા બીજી તપાસની બાબત છે. એ ભેદ જ નક્કી કરે છે કે આગળનો વિભાગ અહીં લાગુ પડે છે કે નહીં.
નજીકના સર્વર સુધી પહોંચવાના ટેકાવાળા રસ્તા
સૌથી સ્વચ્છ ગોઠવણ સ્પ્લિટ-હોરાઇઝન જવાબ છે: જાહેર નામ ઇન્ટરનેટ માટે જાહેર સરનામે અને અંદરના ક્લાઇન્ટ માટે સર્વરના LAN સરનામે રિઝોલ્વ થાય છે. પ્રોફાઇલ એક એન્ડપોઇન્ટ નામ રાખે છે અને રિઝોલ્વર રસ્તો પસંદ કરે છે. એ માટે આંતરિક DNS જવાબનું નિયંત્રણ જોઈએ, જે ઘરેલું રાઉટર સામાન્ય રીતે આપે છે અને સંસ્થા જાણી જોઈને ગોઠવી શકે છે. એ નિયંત્રણ વગર બાકીના વિકલ્પો રાઉટરનું કોઈ લક્ષણ કે બીજું પ્રોફાઇલ છે.
રાઉટરનું લક્ષણ રિફ્લેક્શન છે: ગેટવે અંદર-થી-જાહેર ફ્લોનું અનુવાદ કરીને તેને પાછો અંદર મોકલે છે. જ્યાં તે કામ કરે છે ત્યાં ક્લાઇન્ટમાં કોઈ ફેરફાર જરૂરી નથી, અને જ્યાં કામ કરતું નથી ત્યાં કોઈ ક્લાઇન્ટ સેટિંગ તેને બચાવી શકતું નથી. રાઉટરની લક્ષણ-યાદી વાંચવાને બદલે આંતરિક પ્રયાસ દરમિયાન સર્વર લોગ જોઈને તેનું પરીક્ષણ કરો.
પ્રોફાઇલને ખાનગી સરનામે બદલવું નિદાન છે, રચના નહીં. તે સાબિત કરે છે કે સર્વર LAN પર જવાબ આપે છે, અને લેપટોપ ઘરની બહાર નીકળે તે ક્ષણે એ જ પ્રોફાઇલ તૂટી પડે છે.
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
ઘરથી દૂર પણ પ્રોફાઇલ વાપરી શકાય તેવું રાખો
કોઈ પણ રસ્તો પસંદ કરો, ઓળખ-ચકાસણીને અડકો નહીં. એન્ડપોઇન્ટ સરનામું પીઅર ઓળખ નથી, અને સરનામું બદલાવું એ કદી એવી અસંબંધિત જાહેર કી સ્વીકારવાનું વાજબીપણું નથી જે યોગાનુયોગ જવાબ આપતી હોય. WireGuard કી દ્વારા જ ઓળખ ચકાસે છે, તેથી ખોટો હોસ્ટ હેન્ડશેક નિષ્ફળ કરે છે, અણધારી વસ્તુમાં પ્રવેશ આપતું નથી.
જાહેર સરનામું ખસે તો ડાયનેમિક DNS જ નામને ઉપયોગી રાખે છે, અને ક્લાઇન્ટનું રિફ્રેશ વર્તન નક્કી કરે છે કે ફેરફાર કેટલો જલદી લાગુ પડે છે. સરનામું બદલાયા પછી બહારથી તેનું પરીક્ષણ કરો, કારણ કે LANનો કિસ્સો તેને ચકાસી શકતો નથી. એવા રિઝોલ્વર પ્રત્યે ધ્યાન રાખો જે રેકોર્ડની આયુ પૂરી થયા પછી પણ જૂનો જવાબ કૅશમાં રાખે છે. પહેલાના સરનામે હજી ઇશારો કરતું નામ બરાબર બંધ પડેલા સર્વર જેવું જ દેખાય છે.
પ્રોફાઇલ કયું નામ વાપરે છે અને સીમાની બંને બાજુએ તે કયા સરનામે રિઝોલ્વ થાય છે તે લખી રાખો. કોઈએ નોંધ ન કરેલા રાઉટર લક્ષણ પર આધારિત પ્રોફાઇલ એ આગલા ફર્મવેર અપડેટની રાહ જોતો સપોર્ટ કૉલ છે. એ નોંધ જ આગલી વ્યક્તિને કહે છે કે આંતરિક નિષ્ફળતા જાણીતો હેરપિન કિસ્સો છે કે કંઈક નવું.