VPN સરનામાં સાથે બંધાયેલી એપ્લિકેશન હજુ પણ ખોટો રૂટ વાપરે છે

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

આ રનબુકનો બાકીનો ભાગ એ તપાસનો ક્રમ છે જે હું વાપરું છું, દરેક નિરીક્ષણ આપતી કમાન્ડ સાથે.

બાઇન્ડ ખરેખર શું નક્કી કરે છે

બાઇન્ડ સોકેટને સ્થાનિક સરનામું સોંપે છે. પછી કર્નલ એ જ રૂટ લુકઅપ ચલાવે છે જે તે અન્યથા ચલાવત, સિવાય કે નીતિ નિયમ બદલે કે એ લુકઅપ કયું ટેબલ વાંચે છે.

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

Linux IP સોકેટ સંદર્ભ બાઇન્ડની અર્થશાસ્ત્રનું દસ્તાવેજીકરણ કરે છે. રાઉટિંગનો અડધો ભાગ ip-rule અને ip-route માં રહે છે, અને તે એક કારણસર અલગ મેન્યુઅલ છે.

ખાતરી કરો કે સરનામું આ નેમસ્પેસનું છે

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

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

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

એ સ્રોત અને ગંતવ્ય માટેનું લુકઅપ વાંચો

એક કમાન્ડ એ પ્રશ્નનો જવાબ આપે છે જે બાઇન્ડે આપ્યો નહોતો:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

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

પછી ip rule show કહે છે કે કોઈ નિયમ બીજું ટેબલ પસંદ કરતું કે નહીં. અહીં પ્રાથમિકતા મહત્વની છે, કારણ કે પહેલો મેળ ખાતો નિયમ જીતે છે, અને તમારા નિયમની ઉપર રહેલો સર્વગ્રાહી નિયમ તમારા નિયમને અદૃશ્ય કરી દે છે.

નીતિ નિયમ ત્યારે જ મૂકો જ્યારે એ જ ડિઝાઇન હોય

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

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

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

ip rule del અને ip route flush table 100 થી પાછું વાળો. આ રીતે ઉમેરાયેલું બધું રીબૂટ પર અદૃશ્ય થાય છે, સિવાય કે કોઈ મેનેજર તેને લખે; આ એક તરફ સુરક્ષા-ગુણ છે અને બીજી તરફ એકમાત્ર નકલ તમારા શેલ ઇતિહાસમાં ન રાખવાનું કારણ.

ત્રણ નિરીક્ષણોથી ચકાસો

એપ્લિકેશને માંગેલો સ્રોત, લુકઅપે પસંદ કરેલો રૂટ, અને સર્વરે ખરેખર જોયેલો સ્રોત — ત્રણેય નોંધો.

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

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