IPv6 noklusējuma maršruts pazuda pēc pārsūtīšanas iespējošanas Linux
Kad iespējo IPv6 pārsūtīšanu, kodols ignorē router advertisements uplink savienojumā, un apgūtais noklusējuma maršruts beidzas. Izlabojiet to ar accept_ra.
Uzstādīju net.ipv6.conf.all.forwarding=1 Debian vārtejā, lai tā varētu pārsūtīt VPN klientu datplūsmu, un apmēram pusstundu vēlāk mašīnai vairs nebija neviena IPv6 noklusējuma maršruta. Augšupējais maršrutētājs darbojās, link-local kaimiņš joprojām atbildēja, un uplink joprojām turēja savu globālo adresi. Apstājās kodola gatavība turpināt pieņemt router advertisements šajā saskarnē. Maršruts nepazuda tajā brīdī, kad ievadīju sysctl; tas pazuda, kad beidzās no RA apgūtā noklusējuma maršruta darbības laiks un nekas to neatjaunoja.
No pirmā acu uzmetiena nekas neizskatījās salūzis. Pārsūtīšana strādāja, klienti joprojām gāja cauri, kamēr vecais maršruts vēl bija kešatmiņā, un kļūme iestājās vēlāk nekā to izraisījušās izmaiņas. Tieši šī aizkave ir iemesls, kāpēc vainu noveļ uz augšupējo pusi vai uz ugunsmūra noteikumu, kas nekad nav bijis iesaistīts.
Izlasiet maršrutu tabulu pirms jebkura sysctl aiztikšanas
Sāciet ar ip -6 route show default un lasiet atribūtus, nevis tikai vārteju. No RA apgūts noklusējuma maršruts ir atzīmēts ar proto ra, nes preferenci un rāda expires atskaiti. Maršrutam, kas pievienots ar roku, nav neviena no tiem, un šī atšķirība pasaka, kurš mehānisms pārvalda maršrutu.
$ ip -6 route show default
default via fe80::1 dev eth0 proto ra metric 1024 expires 1432sec hoplimit 64 pref mediumPēc tam apskatiet adresi: ip -6 addr show dev eth0. Globālā adrese ar vēlamo un derīgo darbības laiku, kas mērīts stundās, pārdzīvos noklusējuma maršrutu, kura maršrutētāja darbības laiks tiek mērīts minūtēs. Adrese ir, bet noklusējuma maršruta nav, tā ir sludinājumu problēmas pazīme. Ja trūkst arī adreses, vispirms jāķeras pie saites, prefiksa informācijas vai dublētu adrešu noteikšanas.
Kāpēc pārsūtīšana izslēdz RA apstrādi
RA ir 134 tipa ICMPv6 pakete, kas nosūtīta no link-local avota ar lēciena ierobežojumu 255. Pirms kodols to izmanto, tas pārbauda saskarnes accept_ra vērtību. Noklusējuma vērtība ir 1, un 1 nenozīmē jā. Tā nozīmē: pieņemt tikai tikmēr, kamēr šis resursdators nepārsūta. Iestatiet forwarding=1, un šis nosacījums vairs neizpildās, tāpēc sludinājums tiek izmests pirms jebkura prefiksa vai noklusējuma maršrutētāja izskatīšanas tajā.
Pastāv trīs vērtības, un pārsūtīšanu pārdzīvo tikai trešā:
accept_ra | forwarding=0 | forwarding=1 |
|---|---|---|
| 0 | ignored | ignored |
| 1 (default) | accepted | ignored |
| 2 | accepted | accepted |
Vēl divi karodziņi nosaka, kas faktiski tiek instalēts. accept_ra_defrtr vada, vai noklusējuma maršrutētājs sludinājumā kļūst par maršrutu, un accept_ra_pinfo vada, vai prefiksa informācija tiek izmantota adreses konfigurācijai. accept_ra_defrtr izslēgšana ir ierastais veids, kā saglabāt SLAAC adreses pārsūtošā resursdatorā, neapgūstot noklusējuma maršrutu. Tas ir cits sviras mehānisms nekā accept_ra, un pie tā ķeras, ja vajag adreses, bet nevis maršrutu. Kodola IP sysctl uzziņa uzskaita visus trīs.
Apstipriniet to ar trim komandām
Vispirms izlasiet dzīvās vērtības, nevis failu, kuru, jūsuprāt, esat ielādējis:
sysctl net.ipv6.conf.eth0.forwarding net.ipv6.conf.all.forwarding \
net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_defrtrOtrkārt, pierādiet, ka sludinājumi joprojām pienāk. Filtrēšana pēc ICMPv6 tipa baita ir pietiekama, un tā ietaupa kaimiņu atklāšanas datplūsmas sienas lasīšanu:
tcpdump -ni eth0 'icmp6 and ip6[40] == 134'Ja vairākas minūtes nekas neparādās, accept_ra nav jūsu problēma. Augšupējā puse pārstāja sludināt, kaut kas ceļā filtrē ICMPv6, vai arī šī saskarne patiešām neatrodas segmentā, par kuru domājat. Treškārt, palūdziet sludinājumu paši un izlasiet tā laukus:
rdisc6 eth0rdisc6 nāk paketē ndisc6 uz Debian un Ubuntu. Izvadā apskatiet maršrutētāja darbības laiku un preferenci, pirms kaut ko citu maināt. Sludinājums ar maršrutētāja darbības laiku 0 ir norādījums noņemt noklusējuma maršrutētāju, un neviena accept_ra vērtība to nepārvērš lietojamā maršrutā. Tā arī noķerat augšupēju CPE tiltveida režīmā, kas izdala prefiksus, bet nekad nepiedāvā sevi kā maršrutētāju.
Padariet uplink par vienīgo pieļāvīgo saskarni
Ja augšupējai pusei jābūt noklusējuma maršrutētājam, pieņemiet tur sludinājumus, neraugoties uz pārsūtīšanu, un nekur citur:
# /etc/sysctl.d/60-ipv6-router.conf
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.eth0.accept_ra_defrtr = 1Ierobežojumam ir nozīme, jo IPv6 pārsūtīšana Linux ir viens globāls slēdzis, nevis viens uz katru saiti. Ierakstiet 1 net.ipv6.conf.wg0.forwarding un pēc tam izlasiet net.ipv6.conf.all.forwarding: globālā vērtība apgriežas, un katra saskarne sāk pārsūtīt. Jūs nevarat būt maršrutētājs tunelī un parasts resursdators lokālajā tīklā. Ierobežot varat pieņemšanu. Turiet accept_ra=2 uz uplink, bet tuneļa un lokālā tīkla saskarnes atstājiet uz 1 vai 0, lai apmaldījies sludinājums, kas pienāk pa tuneli, nevarētu instalēt noklusējuma maršrutu, kas norāda tajā.
Pagaidu sysctl -w nepārdzīvos nākamo palaišanu, un gan systemd-networkd, gan NetworkManager raksta šīs vērtības no savas konfigurācijas. Networkd iestatiet IPv6Forwarding=yes un IPv6AcceptRA=yes uplink .network failā; networkd dokumentē IPv6Forwarding kā globālu tā paša kodola iemesla dēļ. NetworkManager gadījumā tieši ipv6.method=auto uz uplink vada accept_ra vērtību, tāpēc pēc nmcli connection up izlasiet sysctl vēlreiz, nevis uzticieties pirmajai pārbaudei.
Statiskā alternatīva, ip -6 route add default via fe80::1 dev eth0, tiešām darbojas, un tā ir saprātīga atbilde, ja augšupējam maršrutētājam ir stabila link-local adrese. Esiet skaidri par to, no kā atsakāties. Statisks noklusējuma maršruts nekad netiek atjaunināts un nekad netiek atsaukts, tāpēc pēc augšupējās puses nomaiņas tas joprojām rāda uz mirušu kaimiņu. RA maršruts sabrūk droši; statiskais sabrūk klusi.
Pārbaudiet pārsūtīto paketi, nevis pašas vārtejas paketi
Pašas vārtejas ping var izdoties maršrutā, kuru neviens klients nevar izmantot, un var izdoties arī tāpēc, ka vārteja ir avots. Pārbaudiet no pieslēgta klienta un pēc tam pajautājiet vārtejai, ko tā darītu ar šī klienta adresi:
# on the VPN client
ping -6 -c 3 2001:4860:4860::8888
# on the gateway, using a client address
ip -6 route get 2001:4860:4860::8888 from fd42:20::2Pēc tam nogaidiet vienu maršrutētāja darbības laiku un apskatiet vēlreiz. Vēlamais stabilais stāvoklis ir noklusējuma maršruts, kas atzīmēts ar proto ra un kura expires vērtība nepārtraukti atjaunojas, plus all.forwarding=1. Ja expires tikai skaita atpakaļ, sludinājumi joprojām kaut kur tiek izmesti, un ierastais vaininieks ir tīkla pārvaldnieks, kas pārraksta accept_ra pēc tam, kad palaišanas sysctl jau ir izpildījies.
Pirms to noslēdzat, apstipriniet četras lietas: noklusējuma maršruts ir proto ra un atjaunojas, accept_ra=2 attiecas tikai uz uplink, pārsūtīšana pēc pārstartēšanas un pēc pārvaldnieka pārstartēšanas joprojām ir 1, un IPv6 ping pabeidz klients, nevis vārteja. Ja klientam joprojām neizdodas ar veselīgu maršrutu, nākamais aizdomās turamais ir atgriešanās ceļš vai augšupējs ugunsmūris, nevis sludinājums.