રાઉટરનું VPN કામ કરે છે, પણ LAN ક્લાયન્ટ્સ પાસે ઇન્ટરનેટ નથી

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

LAN હોસ્ટથી નિષ્ફળતા વાંચો

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

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

સ્થાનિક ટ્રાફિક અને ફોરવર્ડ ટ્રાફિક અલગ છે

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

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

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

પરત માર્ગ પણ હોવો જોઈએ

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

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

ક્લાયન્ટ DNS એ જ સમીક્ષાનો ભાગ છે. રાઉટરનો રિઝોલ્વર જવાબ આપી શકે છે જ્યારે બીજા સર્વર તરફ નિર્દેશિત ક્લાયન્ટને કંઈ જ મળતું નથી.

એક મંજૂર અને એક નકારેલ પ્રવાહ ચકાસો

સુધારા પછી રાઉટરના હાલના સત્રને બદલે ક્લાયન્ટથી નવું જોડાણ ચકાસો. પછી ખાતરી કરો કે જે સેગમેન્ટે ટનલ વાપરવી ન જોઈએ તે હજી પણ વાપરતું નથી.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

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

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