VPN રૂટ ip route આઉટપુટમાં કોઈ ગેટવે કેમ દેખાડતું નથી
ઇન્ટરફેસ ધરાવતી પણ ગેટવે વગરની લાઇન સીધો રૂટ છે, તૂટેલો નહીં. લક્ષ્ય, dev અને scope વાંચો, પછી ip route get વડે ખાતરી કરો.
ગેટવે કૉલમ ખાલી દેખાય ત્યારે રૂટિંગ કોષ્ટકોને તૂટેલા તરીકે વાંચવામાં આવે છે, જ્યારે લાઇન સામાન્ય રીતે પોતે જ પૂર્ણ હોય છે. via ક્ષેત્ર ત્યારે જ દેખાય છે જ્યારે કર્નલ પેકેટને આગળના હોપના સરનામે સોંપે છે; ઇન્ટરફેસ સાથે જોડાયેલો રૂટ તેના લક્ષ્યો સુધી લિંક-સ્તરના ઉકેલ દ્વારા અથવા પોઇન્ટ-ટુ-પોઇન્ટ સાથી દ્વારા પહોંચે છે. કૉલમ ડાબેથી જમણે વાંચવાથી ખબર પડે કે તમે કઈ સ્થિતિમાં છો, અને એ વાંચન કોઈ ડિફૉલ્ટ રૂટ સંપાદિત કરે તે પહેલાં જ થવું જોઈએ. ગુમાવેલા ગેટવે વિશેની મોટાભાગની ટિકિટો આ ભેદ પર જ પૂરી થાય છે.
રૂટ લાઇન કૉલમ પ્રમાણે વાંચો
દરેક પ્રવેશ લક્ષ્ય અને તેની પ્રીફિક્સ લંબાઈથી શરૂ થાય છે, પછી નિશ્ચિત શબ્દભંડોળમાં સંશોધકો ઉમેરે છે: via, dev, proto, scope, src અને metric. 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 જેવી લાઇન ગીચ છે પણ સંપૂર્ણ રીતે નિર્દિષ્ટ છે. તેમાં કંઈ ખૂટતું નથી, અને કોઈ રાઉટર સરનામું ધારવામાં આવતું નથી.
via ની ગેરહાજરી એ રસપ્રદ ભાગ છે. આગળના હોપ વિના કર્નલ લક્ષ્યને સીધું જ નામ આપેલા ઇન્ટરફેસ પર ઉકેલે છે, જે ટનલ માટે એનો અર્થ છે કે ફ્રેમ ટનલ ઉપકરણને સોંપવી અને એન્કેપ્સ્યુલેશનને ત્યાંથી સંભાળવા દેવું. proto kernel નોંધે છે કે સરનામું સોંપાયા પર પ્રવેશ આપમેળે સ્થાપિત થયો હતો, વ્યવસ્થાપકે ટાઇપ કરેલો નહીં. scope link કહે છે કે લક્ષ્ય તે લિંક પર રાઉટરમાંથી પસાર થયા વિના પહોંચી શકાય છે, અને src તે સરનામું નામ આપે છે જે કર્નલ મેળ ખાતા ટ્રાફિક માટે સ્રોત તરીકે પસંદ કરશે.
હવે એ જ રીતે ડિફૉલ્ટ રૂટ વાંચો: default via 192.0.2.254 dev eth0 proto static metric 100. અહીં via હાજર છે કારણ કે પેકેટને ખરેખર આગળના હોપની જરૂર છે, અને એ હોપ પોતે eth0 પર પહોંચી શકાય તેવો હોવો જોઈએ. બંને લાઇનો એકબીજાના પ્રકારો નથી; તેઓ ટ્રાફિક ક્યાં જાય છે તે વિશે જુદા પ્રશ્નોના જવાબ આપે છે.
બે રૂટ આકાર જે એકબીજા સાથે ભળી જાય છે
ટનલ સબનેટ રૂટ અને ડિફૉલ્ટ રૂટ સ્ક્રીનશૉટમાં સરખા દેખાય છે અને તદ્દન જુદી રીતે વર્તે છે. નીચેનું કોષ્ટક ક્ષેત્રો વાંચવા માટે સહાય તરીકે વાપરો, પછી માર્ગદર્શિકાના નમૂના પર ભરોસો કરવાને બદલે તમે ડિબગ કરી રહ્યા છો તે મશીન પર વાસ્તવિક આંકડા ખાતરી કરો.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
કોષ્ટક જે તમને કહી શકતું નથી તે છે ઉદ્દેશ. ટનલ દ્વારા ખાનગી શ્રેણી તરફ સીધો રૂટ એ જાણી જોઈને કરેલી સ્પ્લિટ-ટનલ ડિઝાઇન છે; જે હોસ્ટે બધું VPN દ્વારા મોકલવું જોઈએ ત્યાં એ જ આકાર દેખાવો એ લક્ષણ છે. ઉદ્દેશ એ કન્ફિગરેશનમાં રહે છે જેણે પ્રવેશ બનાવ્યો, તેથી કર્નલે કંઈ ખોટું કર્યું છે એવું તારણ કાઢતા પહેલાં જે સાધન તેને સ્થાપિત કર્યું તેને જુઓ.
એ જ રીતે, ગુમાવેલો ગેટવે એ એક શોધી કાઢવાની પરવાનગી નથી. જો રૂટને ખરેખર આગળના હોપની જરૂર હોય, એ હોપ તેને વહન કરતા ઇન્ટરફેસ પર પહોંચી શકાય તેવો હોવો જોઈએ, અને પોઇન્ટ-ટુ-પોઇન્ટ ટનલ માટે સાથીનું સરનામું સ્થાનિક સરનામા જેવી એ જ વસ્તુ નથી. સ્થાનિક ટનલ સરનામાને ઇથરનેટ રાઉટર તરીકે ગણવો એ સાચો દેખાતો પણ કંઈ ફોરવર્ડ ન કરતો રૂટ બનાવવાની સામાન્ય રીત છે.
કર્નલને પૂછો કે તે ખરેખર કઈ લાઇન વાપરશે
કોષ્ટક વાંચવું એ શોધ કરવા જેટલું જ નથી, કારણ કે જવાબ આપતા પહેલાં કર્નલ નીતિ નિયમો, ઘણાં કોષ્ટકો અને કૅશ કરેલા પ્રવેશોની સલાહ લે છે. વાસ્તવિક શોધ કરતું ક્રિયાપદ ip route get છે, અને તે એ રૂટ છાપે છે જે એ ગુણધર્મોવાળું પેકેટ લેશે.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0તમને ખરેખર જે લક્ષ્યની પરવા છે તે મૂકો, પછી જ્યારે ટ્રાફિક સ્રોત પ્રમાણે પસંદ થાય અથવા ફોરવર્ડ થાય ત્યારે from અથવા iif ઉમેરો, કારણ કે સામાન્ય સ્થાનિક શોધ ફોરવર્ડ થયેલા ક્લાઇન્ટ કરતાં જુદો માર્ગ પસંદ કરી શકે છે. જવાબ ઇન્ટરફેસ, પસંદ કરેલું સ્રોત સરનામું અને કોઈપણ આગળનો હોપ નામ આપે છે, જે તે ક્ષણે પેકેટને રૂટ કરવામાં આવતું એ જ માહિતી છે.
જવાબ તમને આશ્ચર્યચકિત કરે તો કંઈપણ બદલતા પહેલાં નિયમો છાપો: ip -4 rule show તેમને અગ્રતા ક્રમમાં સૂચિબદ્ધ કરે છે, અને જે VPN ક્લાઇન્ટ પોતાનું કોષ્ટક અથવા ચિહ્નિત પેકેટો માટે નિયમ સ્થાપિત કરે છે તે મુખ્ય કોષ્ટકમાં બિલકુલ દેખાશે નહીં. દરેક કોષ્ટકની સૂચિ બનાવવાથી એ ખાલી જગ્યા ભરાય છે.
ip -4 route show table all | grep -E 'tun|default'ડિફૉલ્ટ બદલતા પહેલાં અંડરલે તપાસો
ટનલના પોતાના પેકેટોએ દૂરના છેડા સુધી પહોંચવું જોઈએ, અને તેઓ ભૌતિક ઇન્ટરફેસ દ્વારા એ રૂટ વાપરીને પહોંચે છે જે VPN ઉપર આવે તે પહેલાં અસ્તિત્વમાં હતો. એ છેડાને પિન કર્યા વિના આખો ડિફૉલ્ટ રૂટ બદલવાથી એન્કેપ્સ્યુલેટેડ પેકેટો એ ટનલમાં જાય છે જે તેમણે બનાવવાની હોય છે, અને જોડાણ તૂટી પડે છે. પહેલાં ફક્ત છેડાના સરનામા માટે શોધ કરીને છેડાનો માર્ગ ખાતરી કરો.
ફેરફાર કરતી વખતે ત્રણ વસ્તુઓ અલગ રાખો: ભૌતિક ઇન્ટરફેસ પર રહેવો જોઈએ તે છેડાનો રૂટ, ટનલમાં પ્રવેશવા જોઈએ તે ખાનગી શ્રેણીઓ, અને બાકીનું બધું નક્કી કરતો ડિફૉલ્ટ. એ ક્રમમાં તેમને અલગ કરો, એક વખતે એક લાગુ કરો, અને દરેક પગલા પછી શોધ ફરી ચલાવો. પછીનું નિષ્ફળ પિંગ પોતે ખૂબ ઓછું પુરવાર કરે છે, કારણ કે પરવાનગીઓ, જવાબ રૂટિંગ, DNS અને સેવા પોતે બધા સાચા રૂટની નીચેની બાજુએ બેઠા છે.
સંપાદન પહેલાં લાઇને તમને આપેલા ચાર મૂલ્યો લખો: લક્ષ્ય, આગળનો હોપ અથવા તેની ગેરહાજરી, ઉપકરણ, અને પસંદ કરેલો સ્રોત. પછીનો ફેરફાર તેમાંથી કોઈપણ ખસેડે તો તમે જાણો છો કે કયો નિર્ણય ખરેખર બદલાયો, અને આખા કોષ્ટક વિશે અનુમાન કરવાને બદલે એક પ્રવેશ પુનઃસ્થાપિત કરી શકો છો.