PPP નું peer સરનામું કે VPN એન્ડપોઇન્ટ: via માં કયું જાય છે
PPP ઇન્ટરફેસને સબનેટ તરીકે વાંચવાની સરખામણી તેના inet અને peerને એક જ કડીના બે છેડા તરીકે વાંચવા સાથે કરો, અને જુઓ નીતિ કોષ્ટક કયો આગળનો હોપ સ્વીકારી શકે.
PPP ઇન્ટરફેસ પરની એક લાઇન VPN બોક્સ પરની મોટા ભાગની રાઉટિંગ ચર્ચા નક્કી કરે છે: અંદરનું સરનામું અને તેની બાજુમાં છપાયેલું peer. તે જોડીને નાના સબનેટ તરીકે વાંચો અને તમે એવું ગેટવે શોધશો જે અસ્તિત્વમાં નથી. તેને એક જ કડીના બે છેડા તરીકે વાંચો અને આગળનો હોપ સ્પષ્ટ થાય છે. અહીંની સરખામણી આ બે વાંચન વચ્ચે છે, કારણ કે પછી બનાવેલું દરેક કોષ્ટક તમે પસંદ કરેલું જ વારસામાં લે છે. બહારના VPN એન્ડપોઇન્ટ વિશે આમાંથી કંઈ પણ નક્કી કરતું નથી.
એક ઇન્ટરફેસ લાઇનનાં બે વાંચન
એવું સત્ર લો જેમાં ઇન્ટરફેસ inet 10.64.3.9 peer 10.64.3.1/32 જણાવે છે. સબનેટ વાંચન 10.64.3.9ને /32 ટાપુ પરનું એકલું હોસ્ટ માને છે અને પછી તેની બહાર કંઈ પણ પહોંચવા રાઉટર શોધે છે. કડી પરનું બીજું એકમાત્ર સરનામું peer હોવાથી, તે વાંચન અંતે 10.64.3.9ને જ ગેટવે તરીકે સૂચવે છે, જે ચક્રીય છે.
એન્ડપોઇન્ટ વાંચન એ દસ્તાવેજીકૃત છે. પોઇન્ટ-ટુ-પોઇન્ટ ઇન્ટરફેસ પર peer તે એક જ કડીના દૂરના છેડાને નામ આપે છે, તેથી 10.64.3.1 જ વપરાય તેવો આગળનો હોપ છે અને 10.64.3.9 હંમેશા ફક્ત સ્રોત સરનામું છે.
આ તફાવત નક્કી કરે છે કે via માં શું આવી શકે. ત્યાં સ્થાનિક સરનામું લખવાથી એવો માર્ગ બને છે જે કર્નલ પડોશી સુધી ઉકેલી શકતું નથી, તેથી નોંધ કાં તો ચકાસણીમાં નિષ્ફળ જાય છે કાં તો યાદીમાં સાવ સ્વસ્થ દેખાતાં ટ્રાફિક ગળી જાય છે. peer કાર્ય કરે છે કારણ કે તે કડી પરનું ખરું ગંતવ્ય છે. બંને વાંચન બહારના VPN એન્ડપોઇન્ટ પર સહમત છે, જે સાવ અલગ ઓળખ છે: ત્યાં અંડરલે દ્વારા પહોંચાય છે, જે સુરંગ તે સમાપ્ત કરે છે તેના દ્વારા નહીં.
સત્ર પહેલેથી શું સ્થાપિત કરી ચૂક્યું છે
પોતાનું કોષ્ટક લખતાં પહેલાં કડી સાથે શું આવ્યું તે છાપો. સમર્થિત PPP એકીકરણ સામાન્ય રીતે સત્ર સ્થાપિત કરતી વખતે ઉપકરણ માર્ગ અને peer માર્ગ સ્થાપિત કરે છે, અને આ બંને નોંધો પહેલેથી જ સાચું વાંચન સંકેતિત કરે છે.
ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5
10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 જેવો ઉપકરણ માર્ગ ગેટવે ધરાવતો નથી કારણ કે ઇન્ટરફેસ પોતે જ માર્ગ છે. via થી peerનું નામ લેતો માર્ગ બીજા આયુષ્યની બીજી વસ્તુ છે, અને સત્ર તૂટે ત્યારે તે અદૃશ્ય થાય છે. બંનેમાંથી કોઈ પણ સ્વરૂપ ફરી કેવી રીતે સ્થાપિત થાય તે તપાસ્યા વિના ટકાઉ કોષ્ટકમાં નકલ કરવી એ જ ચાલુ સુરંગ ફરી જોડાણ પછી તેનો માર્ગ ગુમાવવાનું સામાન્ય કારણ છે.
યાદશક્તિ પર ભરોસો કરવાને બદલે બંને યાદીઓ સરખાવો. peer માર્ગ main માં હોવા છતાં તમારું વધારાનું કોષ્ટક ખાલી હોય, તો સરનામાની લાઇને કદી ન કહેલું તમે શીખ્યા.
નિયમ અને કોષ્ટક અલગ નિર્ણયો છે
કોષ્ટક પસંદ કરવું અને તેને ભરવું સ્વતંત્ર પગલાં છે, અને ડિબગ કરતી વખતે આ બંને ઘણી વાર ભળી જતાં હોવાથી અહીં સરખામણી મહત્ત્વની છે. ચિહ્નિત ટ્રાફિકને કોષ્ટક 100 માં મોકલતો નિયમ કોષ્ટક 100 માં મળતો માર્ગ ન હોય તો કંઈ કરતો નથી, અને સારી રીતે ભરેલું કોષ્ટક તેની તરફ ઇશારો કરતો નિયમ ન હોય તો પહોંચી શકાય તેવું નથી.
અડધો ડિફોલ્ટ માર્ગ ડિફોલ્ટ માર્ગ નથી. એક 0.0.0.0/1 IPv4 જગ્યાનો નીચેનો અડધો ભાગ આવરે છે, તેથી બધું પકડવાનો ઇરાદો ધરાવતી નીતિને મળતો 128.0.0.0/1 અથવા સાચો default પણ જરૂરી છે. ચાલુ રૂપરેખા વાંચીને બે અડધામાંથી એક નકલ કરવી એ જ લોકો કેટલાંક ગંતવ્યો પર જ તૂટતા રાઉટિંગ લૂપમાં ફસાવાનો માર્ગ છે.
LAN પર રહેવા જોઈએ તેવા સરનામાં માટે જાણી જોઈને અપવાદ રાખો, અને પસંદ કરેલા કોષ્ટકમાં શોધમાં કંઈ ન મળે ત્યારે શું થાય તે નક્કી કરો. સ્પષ્ટ ફોલબેક માર્ગ ખાલી કોષ્ટક કરતાં વિચારવા સહેલો છે, જે પહોંચી ન શકાય તેવું પરિણામ આપે છે અને એપને ખોટા માર્ગે હોવાને બદલે તૂટેલી દેખાડે છે.
શોધને તમારી એપ જે પ્રશ્ન પૂછે તે પૂછો
ip route get માર્ગ ઉકેલે છે; ip route show સંગ્રહિત નોંધોની યાદી આપે છે, અને બંને કોઈ પણ ખોટું ન હોવા છતાં અસહમત થઈ શકે છે. સ્રોત સંદર્ભ સમાવો, કારણ કે સ્રોત-આધારિત નિયમો ફક્ત ત્યારે જ મળે છે જ્યારે શોધ સ્રોત લઈ જાય.
ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show
પ્રથમ આદેશ હોસ્ટ તરફથી પ્રશ્ન પૂછે છે. બીજો પ્રવેશ ઇન્ટરફેસ ઉમેરે છે, જે આગળ મોકલાયેલા ટ્રાફિકને અનુભવે તેની નજીક છે, અને જવાબ ઘણી વાર બીજા કોષ્ટક તરફ ઇશારો કરે છે. આમાંથી કોઈ ગંતવ્ય જીવંત પરીક્ષણ સેવા નથી; 198.51.100.23 દસ્તાવેજી સરનામું છે, તેથી તપાસવાની પરવાનગી હોય તેવા હોસ્ટથી તેને બદલો.
સાચી શોધ પણ ફક્ત એટલું જ સાબિત કરે છે કે માર્ગ પસંદ થયો. બીજી બાજુ ટ્રાફિક સ્વીકારે છે કે જવાબ એ જ તર્કથી પાછો આવી શકે છે, તે કહેતું નથી.
સરખામણી ક્યાં ઉલટાય છે
હોસ્ટ ટ્રાફિક અને આગળ મોકલાયેલો ટ્રાફિક ફક્ત અલગ શોધ લેતા નથી; પાછા ફરતા માર્ગે તેઓ અલગ ગાળકોને મળે છે. Linux બધા ઇન્ટરફેસ અને સ્વીકારતા ઇન્ટરફેસની ગોઠવણોમાંથી કડક વાળીનો ઉપયોગ કરીને ઉલટા-માર્ગની ચકાસણી લાગુ કરે છે, તેથી એક ઇન્ટરફેસનું મૂલ્ય બદલવાથી દેખાતી અસર ન પણ હોય. ચિહ્ન-આધારિત રાઉટિંગ src_valid_mark સંબંધ ઉમેરે છે, જેમાં સ્રોત માન્ય ગણાય તે માટે ચિહ્ન મેળવવું પડે.
બહાર જતું રાઉટિંગ સાચું દેખાતું હોય ત્યારે પણ જવાબો અદૃશ્ય થાય, તો તેમને અડકતાં પહેલાં અસરકારક મૂલ્યો વાંચો, અને જાહેર કારણ વિના તેમને બદલશો નહીં.
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark
બે રચનાઓમાંથી પુરાવાના આધારે પસંદ કરો: એપ PPP સરનામા સાથે બંધાયેલી હોય તો સ્રોત નિયમ અને peer માર્ગ ધરાવતું કોષ્ટક પૂરતું છે. બોક્સ પાછળના LAN માટે આગળ મોકલતું હોય તો પ્રવેશ સંદર્ભ અને પરત માર્ગ પણ મેળવવા પડે. ન મેળે તો આખા મશીન માટે ચકાસણી ઢીલી કરવાને બદલે માર્ગની માલિકી સુધારો.