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

પહેલા જોડાણની દિશા દોરો

આંતરિક રાઉટરનું સ્થિતિ પૃષ્ઠ ખોલો અને તેનું WAN સરનામું લખો, પછી સાર્વજનિક સેવા તમને જે સરનામું જણાવે છે તેની સાથે સરખાવો. જો બંને અલગ હોય, તો તમારા રાઉટર અને ઇન્ટરનેટ વચ્ચે ઓછામાં ઓછો એક અનુવાદક છે. જો WAN સરનામું 100.64.0.0/10 ની અંદર આવે, તો બહારનો અનુવાદક સંભવતઃ તમારા પ્રદાતાનો છે, અને તમે તેને નિયંત્રિત કરતા નથી. આ બે તથ્યો નક્કી કરે છે કે પછીના પગલાંમાંથી કયું બિલકુલ કામ કરી શકે.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

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

આઉટબાઉન્ડ: ક્લાયન્ટ પૂછે છે, અનુવાદકો મેપ કરે છે

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

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

wg show
ping -c3 10.8.0.1

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

ઇનબાઉન્ડ: ફોરવર્ડિંગ ફક્ત તમારા માલિકીના સાધનોને આવરે છે

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

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

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

જો બહારનું સ્તર પ્રદાતાનું હોય અને તે ફોરવર્ડ ન કરે, તો થોભો. ત્યારે સમર્થિત જવાબો બીજી ઍક્સેસ પદ્ધતિ અથવા રિલે છે, તમારી બાજુએ બીજો નિયમ નહીં.

એક વખતે એક ચલ ચકાસો

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

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

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

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

સંબંધિત લેખો