ટનલ ચાલુ છે, ઇન્ટરનેટ નથી: ફોરવર્ડિંગ ક્યાં અટકે છે

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

ખાતરી કરો કે ઇન્ટરનેટ નિકાસ ક્યારેય ડિઝાઇન હતી કે નહીં

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

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

એક જાહેર વિનંતીનું અનુસરણ કરો

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

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

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

ફોરવર્ડિંગ, રૂટ અને અનુવાદ ચકાસો

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

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

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

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

જવાબનો માર્ગ અને રિઝોલ્વર બે અલગ જવાબ છે

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

જે સાઇટ HTTP ભૂલ પાછી આપે છે તે પુરાવો છે કે ઇન્ટરનેટ પર ફોરવર્ડિંગ કામ કરે છે. જે નામ ઉકેલાતું નથી જ્યારે સરનામા દ્વારા પહોંચ કામ કરે છે, તે રિઝોલ્વરની સમસ્યા છે, NATની નહીં.

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