NAT નક્કી કરે છે કે તમારો VPN સર્વર ખરેખર કયું સ્રોત સરનામું જુએ છે

તમારા લેપટોપનું સરનામું ક્યારેય VPN સર્વર સુધી પહોંચતું નથી. NAT છેલ્લા હોપ પર તેને ફરીથી લખે છે, અને ટનલનું IP પછી ફાળવવામાં આવે છે. બંને છેડાની સરખામણી કેવી રીતે કરવી.

તમે વિચારો છો કે VPN સર્વર પેકેટમાંથી તમારા લેપટોપનું સરનામું વાંચે છે અને લોગમાં લખે છે. તે જે વાંચે છે તે છેલ્લા NAT હોપે બહારના હેડરમાં મૂક્યું છે, અને હોટસ્પોટ તરીકે વપરાતા ફોન પર તે ઘણી વાર સેંકડો અન્ય ગ્રાહકો સાથે વહેંચાયેલું સરનામું હોય છે. તમારા મશીનનું પોતાનું 192.168.x.x તે હેડરમાં ક્યારેય ઇન્ટરનેટ પાર કરતું નથી, અને ટનલનું સરનામું સર્વર કનેક્શન પહેલેથી સ્થપાયા પછી આપે છે. તેથી જ્યારે સર્વરનો લોગ અને લેપટોપ પરનું ip addr મળતાં નથી, ત્યારે બંનેમાંથી કોઈ ખોટું નથી; તે એક જ સેશનના જુદા જુદા સ્તરોનું વર્ણન કરે છે.

ત્રણ સરનામાં, અને લોગમાં ફક્ત એક જ છે

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

AddressWho assigns itWhere it sitsVisible to the VPN server
Device address, e.g. 192.168.1.24Your router via DHCPOuter header, before translationNo, rewritten in place
Translated address and portRouter, ISP CGNAT, or bothOuter header, after translationYes, this is the tuple it logs
Tunnel address, e.g. 10.8.0.6The VPN server itselfInner header, after decapsulationYes, but it chose it

કનેક્શનના સમયે ફક્ત વચ્ચેની હરોળ અજાણી હોય છે. સર્વર તેને ડેમન પ્રમાણે પોતાના પીઅર ટેબલ, સ્ટેટસ ફાઇલ કે ફ્લો લોગમાં લખે છે: WireGuard તેને એન્ડપોઇન્ટ કહે છે, OpenVPN સ્ટેટસ ફાઇલ તેને Real Address તરીકે ઓળખાવે છે, અને strongSwan તેને IKE_SAના દૂરસ્થ હોસ્ટ તરીકે જણાવે છે. તે મૂલ્ય જ્યારે પણ જુદા સ્રોતથી પેકેટ આવે ત્યારે તાજું થાય છે, તેથી કોઈ કંઈ પણ પુનઃપ્રારંભ કર્યા વિના તે બદલાય છે.

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

ટનલ ચાલુ રહેતી હોય ત્યારે લોગ કરેલ ટ્યુપલ કેમ બદલાય છે

સરનામા અનુવાદ એ ટાઇમરવાળું ટેબલ છે, કાયમી બંધન નહીં. ઘરનું રાઉટર છેલ્લા પેકેટ પછી થોડા સમય સુધી તેનું UDP મેપિંગ રાખે છે, ઓપરેટરનું ગેટવે પોતાના સમયપત્રક મુજબ પોર્ટ ફરી વાપરે છે, અને Wi-Fi થી LTE પર જતો ફોન સાવ જુદા સ્રોત સાથે પાછો આવે છે. લિનક્સમાં conntrackના ડિફોલ્ટ મૂલ્યો અહીં ઉપયોગી માપદંડ છે: nf_conntrack_udp_timeout 30 સેકન્ડ છે અને સ્ટ્રીમિંગ વેરિઅન્ટ 120 છે, તેથી શાંત ટનલ વપરાશકર્તાને ધ્યાનમાં આવે તે પહેલાં ઘણું પહેલાં તેનું મેપિંગ ગુમાવી શકે છે.

ટનલ ટકી રહે છે કારણ કે પ્રોટોકોલ પીઅરને પ્રમાણિત કરે છે, સરનામાને નહીં. હેન્ડશેક પછી WireGuard સ્થિતિરહિત છે, તેથી કોઈ પણ પ્રમાણિત પેકેટ સંગ્રહિત એન્ડપોઇન્ટને અપડેટ કરે છે અને પુનઃબંધન આગલા પેકેટ પર સુધરે છે; એટલે જ persistent-keepalive = 25 છે, નિષ્ક્રિય સમયે મેપિંગ ગરમ રાખવા માટે. OpenVPNનું --float એ જ કામ કરે છે, પ્રમાણિત ક્લાયંટને નવા સરનામા અને પોર્ટથી ચાલુ રાખવા દે છે. 2.4 અને 2.5 બિલ્ડમાં જ્યાં float ડિફોલ્ટ રૂપે બંધ છે, પુનઃબંધન સેશન રીસેટ કરે છે અને ક્લાયંટ ફરી જોડાય છે.

IPsec ત્યાં વધુ ગતિશીલ ભાગો સાથે પહોંચે છે. IKEv2 NAT ડિટેક્શન પેલોડમાં સ્રોત અને લક્ષ્યના હેશની સરખામણી કરીને અનુવાદ જુએ છે, UDP 4500 એન્કેપ્સ્યુલેશન પર જાય છે, અને keepaliveને નવા ટ્યુપલ સુધી અનુસરે છે. જ્યારે keepalive અવરોધાય છે ત્યારે SA કાગળ પર ચાલુ રહે છે જ્યારે એક દિશામાં ટ્રાફિક શાંતિથી અટકી જાય છે.

સર્વર શું આરોપી શકે છે અને શું નહીં

જે દંતકથા મારવા લાયક છે તે એ છે કે અનુવાદ તમને ઓપરેટરથી છુપાવે છે. તે લેબલ બદલે છે, અવલોકન નહીં. ઓપરેટર NAT પાછળનું ગેટવે 100.64.0.0/10 જગ્યા કે ઘણા ગ્રાહકો વચ્ચે વહેંચાયેલું એક જાહેર સરનામું જુએ છે, અને તો પણ પ્રવાહને પ્રમાણપત્રના સબ્જેક્ટ, WireGuard જાહેર કી, ફાળવેલ ટનલ સરનામું, બાઇટ કાઉન્ટર અને સમય-વિન્ડો સાથે જોડી શકે છે. એમાંથી કંઈને પણ તમારા LAN સરનામાની જરૂર નથી.

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

અનુમાન કરવાને બદલે બંને છેડાની સરખામણી કરો

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

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

પછી રાઉટર કે CGNAT ગેટવે પરની અનુવાદ એન્ટ્રી વાંચો, અને છેવટે સર્વર પર શું પહોંચે છે તે:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

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

ફરક ક્યાં વસ્તુઓ તોડે છે

સર્વર ખામી જેવા દેખાતા વિક્ષેપ સામાન્ય રીતે અહીંથી શરૂ થાય છે. તમારા ઘરના સરનામા પર પિન કરેલો ઍક્સેસ નિયમ ISP લીઝ બદલાયા પછી નિષ્ફળ જાય છે. અનુવાદિત સરનામા સાથે મળતો fail2ban નિયમ તે ગેટવે પાછળના બધા ગ્રાહકોને એકસાથે પ્રતિબંધિત કરે છે. નિશ્ચિત દૂરસ્થ સરનામાવાળો સાઇટ-થી-સાઇટ પીઅર મોબાઇલ લિંક બદલાયા પછી કી નવીકરણ બંધ કરે છે. ટનલ પ્રોટોકોલ ઠીક હતો; બહારના ટ્યુપલ વિશેની ધારણા નહોતી.

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

આ ચાર તપાસ ક્રમમાં કરો અને પહેલી નિષ્ફળ જાય ત્યાં થોભો:

  • બંને છેડે એક જ સમયે કેપ્ચર કરો; સ્રોત પોર્ટ, લક્ષ્ય પોર્ટ અને ટાઇમસ્ટેમ્પ મળે છે તેની ખાતરી કરો.
  • તમે ધારેલું સરનામું નહીં, સર્વર હાલમાં ધરાવતું સરનામું પીઅર યાદીમાં વાંચો.
  • એન્ટ્રી અને તેની બાકીની આયુ માટે conntrack કે NAT ટેબલ તપાસો.
  • ક્લાયંટ પરના ટનલ ઇન્ટરફેસનું સરનામું LAN સરનામા સાથે નહીં, સર્વરે ફાળવેલા સરનામા સાથે મળે છે તેની ખાતરી કરો.

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

સંબંધિત લેખો