VPN ક્લાયન્ટ પાછળનો સર્વર ટનલ દ્વારા કેમ જવાબ આપે છે

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

જવાબ રૂટ થાય છે, યાદ રખાતો નથી

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

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

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

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

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

પરત માર્ગ રાખવાની ત્રણ રીતો

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

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

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

પ્રથમ બે કમાન્ડ સાર્વજનિક સરનામા પરથી આવતા જવાબો માટે વૈકલ્પિક માર્ગ બનાવે છે. ત્રીજું કર્નલને પૂછે છે કે એ જ સ્રોત અને ગંતવ્ય કયો માર્ગ લેશે, અને એમ જ તમે પુષ્ટિ કરો છો કે નિયમની કોઈ અસર છે.

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

જ્યારે બોક્સ LAN માટે પણ રૂટ કરે છે

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

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

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

કારણોને અલગ કરતી ત્રણ પ્રોબ

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

પહેલાં રૂટિંગ પ્રશ્ન સુધારો, પછી નામો જુઓ. બંને મિશ્ર કરવા એ જ રીતે કામ કરતા સર્વરને તૂટેલા રિઝોલ્વર માટે દોષિત ઠેરવવામાં આવે છે.

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