જ્યારે બે અપલિંક એક જ fe80::1 વહેંચે ત્યારે IPv6 નીતિ રૂટિંગ

તમારી પાસે બે અપલિંક છે, અને ip -6 route show બંને પર એક જ આગળનો હોપ છાપે છે: default via fe80::1 dev uplink0 અને default via fe80::1 dev uplink1. એ ડુપ્લિકેટ સરનામાનો સંઘર્ષ નથી, અને ફક્ત આગળનો હોપ fe80::1 નીતિ ટેબલમાં કૉપિ કરવાથી કર્નલને એ નથી કહેવાતું કે તમારો અર્થ કઈ લિંક હતી. સાચો પ્રશ્ન લક્ષણ કરતાં વધુ સાંકડો છે: બીજા ટેબલને એક લિંક જોઈએ કે બંને, અને રીબૂટ પછી એ રૂટને કોણ જીવંત રાખે છે. ત્રણ શરતો, ક્રમમાં ચકાસાયેલી, મોટા ભાગનું નિરાકરણ કરે છે.

એક જ fe80::1 બે જુદા પડોશી છે

લિંક-લોકલ સરનામાં એક જ લિંક પૂરતાં મર્યાદિત હોય છે, તેથી fe80::1 બે વાર છપાયેલું એક સરનામું નથી; તે બે પડોશી છે જે સંયોગથી એક સમાન પ્રત્યય વહેંચે છે. ઝોન ઇન્ડેક્સ એ રીત છે જેમાં યજમાન કહે છે કે તે કયું ધારે છે, તેથી fe80::1%uplink0 અને fe80::1%uplink1 કર્નલ માટે જુદા ગંતવ્યો છે, અને એ પ્રત્યય ક્યારેય દૂરના રાઉટર સુધી જતો નથી. RFC 4007 આ પાછળના ઝોન મોડેલનું વર્ણન કરે છે, અને તેથી જ નીતિ ટેબલે દરેક લિંક-લોકલ આગળના હોપ સાથે એક ઉપકરણ રાખવું પડે છે.

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

ઉપકરણ દૂર કરો તો રૂટ લખી શકાય તેવો રહેતો નથી. ip -6 route add default via fe80::1 table 200 ગેટવે ઉકેલી શકતું નથી, અને iproute2 તેને Error: Nexthop has invalid gateway. સાથે નકારે છે dev uplink0 ઉમેરો અને આદેશ સફળ થાય છે, કારણ કે ઉપકરણ જ આગળના હોપને એ બે પડોશીમાંથી એક સાથે પિન કરે છે. ઉપકરણ તમને એ કહી શકતું નથી કે uplink0 આ ટેબલ માટે સાચી લિંક છે કે નહીં, અને બીજા યજમાનમાંથી નકલ કરેલો રૂટ એ યજમાનનાં ઇન્ટરફેસ નામ સાથે લાવે છે, જ્યાંથી સાચી ભૂલો આવે છે.

શરત એક: ટેબલમાં એક લિંક કે બે

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

એ બીજા કિસ્સામાં નિયમ નક્કી કરે છે કે ટેબલ ક્યારે જોવું, અને રૂટ નક્કી કરે છે કે પેકેટ જ્યારે જાય ત્યારે ક્યાં જાય:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

બંને પદાર્થો એકબીજાના વિકલ્પ નથી, અને ફક્ત ડિફૉલ્ટ ધરાવતું ટેબલ પણ તેનો ગેટવે ઉકેલવામાં નિષ્ફળ જઈ શકે છે. જો add નકારાય, અથવા રૂટ હાજર હોય પણ વાપરી ન શકાય, તો એ ઇન્ટરફેસનું કનેક્ટેડ પ્રીફિક્સ એ જ ટેબલમાં મૂકો, અથવા જ્યારે એ પ્રીફિક્સ બીજે રૂટ થતું હોય ત્યારે હોપને onlink તરીકે ચિહ્નિત કરો. ઉપરના બ્લોકમાં, 2001:db8:100::/48 uplink1 પરના એ કનેક્ટેડ પ્રીફિક્સ માટે ઊભું છે, કોઈ મનસ્વી ગંતવ્ય માટે નહીં. fwmark નિયમ ફક્ત એ માર્કનો ઉપયોગ કરે છે જે બીજું કંઈક સેટ કરે, ફોર્વર્ડિંગ પાથ પરના nftables કે iptables નિયમમાંથી અથવા સોકેટ પરના SO_MARK માંથી, તેથી માર્ક સ્રોત વગર નકલ કરેલો બ્લોક કંઈ જ મેળ ખાતો નથી.

શરત બે: મેટ્રિક મૃત પ્રદાતાને શોધી શકતાં નથી

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

ટેબલ બન્યા પછી પસંદગી ચકાસો, અને કર્નલ જે રીતે જોશે તે રીતે ચકાસો. ip -6 route get 2001:db8:100::1 જે રૂટ વપરાશે તે છાપે છે, જેમાં ઉપકરણ અને પસંદ કરેલું સ્રોત સરનામું સામેલ છે, અને તે નીતિ નિયમોનું પાલન કરે છે. ખોટી અપલિંકનું સ્રોત સરનામું એ સામાન્ય સંકેત છે કે નિયમ તમે અપેક્ષા કરતાં વહેલો મેળ ખાધો.

શરત ત્રણ: નક્કી કરો કે ટકાઉપણાનો માલિક કોણ છે

જે રૂટ ip -6 route add સાથે ઉમેરાયું છે તે રીબૂટ સુધી અથવા કંઈક તેને ફ્લશ કરે ત્યાં સુધી ટકે છે. રાઉટર જાહેરાતોમાંથી શીખેલું ડિફૉલ્ટ જીવનકાળ ધરાવે છે અને રાઉટર તેને પાછું ખેંચી શકે છે, જ્યારે જાતે ઉમેરાયેલું ડિફૉલ્ટ પોતાની જાતે ક્યારેય સમાપ્ત થતું નથી. બંનેને એક ટેબલમાં ભેગા કરવાથી જ જૂનું કાયમી રૂટ તાજા જાહેર કરાયેલા રૂટની ઉપર રહી જાય છે, જ્યારે તે જે અપલિંકનું વર્ણન કરતું હતું તે ઘણા પહેલાં અસ્તિત્વમાં નથી રહ્યું.

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

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

જે રાઉટર બીજા યજમાનો માટે ફોર્વર્ડ કરે છે ત્યાં ટેબલને દોષ આપતાં પહેલાં net.ipv6.conf.all.forwarding તપાસો. ફોર્વર્ડિંગ બંધ હોય તો બીજા નેટવર્કને સંબોધિત પેકેટ ગમે તેટલું ટેબલ 201 સાચું હોય તો પણ કાઢી નાખવામાં આવે છે.

ડિઝાઇન એવી નોંધો કે આગલી વ્યક્તિ તેનું ઓડિટ કરી શકે

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

ટેબલ પૂરું કહેતાં પહેલાં, ip -6 neigh show dev uplink0 સાથે પડોશીની પુષ્ટિ કરો, ક્રમની ઘટનાઓ માટે ip -6 rule show ફરી વાંચો, અને ડિફૉલ્ટ રૂટ લેતા પિંગને બદલે નિયમ સાથે મેળ ખાતા ટ્રાફિકથી પરીક્ષણ કરો. પછી જાણી જોઈને એક અપલિંક નીચે ઉતારો અને જુઓ કર્નલ કયા રૂટ પર પાછું જાય છે; જવાબ તમે લખ્યો હતો તેની સાથે મેળ ખાવો જોઈએ.