રાઉટિંગ કોષ્ટક વિરુદ્ધ વાસ્તવિક શોધ: VPN ટ્રાફિક ક્યાં જાય છે

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

કોષ્ટક ઉમેદવારોનો સમૂહ છે, નિર્ણય નહીં

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

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

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

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

શોધ પહેલા નિયમોમાંથી, પછી કોષ્ટકોમાંથી પસાર થાય છે

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

ip rule show
ip route show table all | head -40
ip route show table 100

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

IPv6 ના પોતાના નિયમો અને કોષ્ટકો છે. બંને કુટુંબો ચલાવતી ડિઝાઇનને બંને શોધની જરૂર છે, અને કાર્યરત IPv4 જવાબ v6 માર્ગ વિશે કંઈ કહેતો નથી જે ડ્યુઅલ-સ્ટેક ક્લાયન્ટ પસંદ કરી શકે.

VPN ક્લાયન્ટ શું ઇન્સ્ટોલ કરે છે

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

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

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

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

બહારનો માર્ગ પણ ટકી રહેવો જોઈએ

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

પીઅરનું સરનામું તે જ રીતે તપાસો જેમ તમે આંતરિક ગંતવ્ય તપાસ્યું હતું, અને ખાતરી કરો કે તે ટનલને બદલે ભૌતિક ઇન્ટરફેસ પર ઉકેલાય છે:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

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

રાઉટિંગ આઉટપુટ તમને શું કહી શકતું નથી

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

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

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