IPv6-oletusreitti katosi, kun edelleenlähetys otettiin käyttöön Linuxissa

Asetin net.ipv6.conf.all.forwarding=1 Debian-yhdyskäytävään, jotta se voisi välittää VPN-asiakkaiden liikennettä, ja noin puolen tunnin kuluttua koneella ei ollut enää yhtään IPv6-oletusreittiä. Ylävirran reititin oli käynnissä, link-local-naapuri vastasi edelleen ja uplink säilytti globaalin osoitteensa. Se mikä oli lakannut, oli ytimen halukkuus ottaa edelleen vastaan router advertisements -viestejä kyseisellä liitännällä. Reitti ei kadonnut sillä hetkellä, kun kirjoitin sysctlin; se katosi, kun RA:sta opitun oletusreitin elinaika päättyi eikä mikään uusinut sitä.

Ensilmmäisellä katsomisella mikään ei näyttänyt rikki olevalta. Edelleenlähetys toimi, asiakkaat pääsivät läpi niin kauan kuin vanha reitti oli välimuistissa, ja vika tuli myöhemmin kuin sen aiheuttanut muutos. Juuri tämä viive saa syyn menemään ylävirralle tai palomuurisäännölle, joka ei ollut koskaan mukana.

Lue reititystaulu ennen kuin kosket mihinkään sysctliin

Aloita komennolla ip -6 route show default ja lue määritteet, älä vain yhdyskäytävää. RA:sta opittu oletusreitti on merkitty proto ra, sillä on preferenssi ja se näyttää expires-laskurin. Käsin lisätyssä reitissä ei ole kumpaakaan, ja tuo ero kertoo, mikä mekanismi omistaa reitin.

$ ip -6 route show default
default via fe80::1 dev eth0 proto ra metric 1024 expires 1432sec hoplimit 64 pref medium

Katso sitten osoitetta: ip -6 addr show dev eth0. Globaali osoite, jonka suositellut ja voimassa olevat elinajat mitataan tunneissa, elää pidempään kuin oletusreitti, jonka reitittimen elinaika mitataan minuuteissa. Osoite on olemassa ja oletusreitti puuttuu, se on ilmoitusongelman allekirjoitus. Jos myös osoite puuttuu, ensin on selvitettävä linkki, prefiksitieto tai päällekkäisten osoitteiden tunnistus.

Miksi edelleenlähetys kytkee RA-käsittelyn pois

RA on tyypin 134 ICMPv6-paketti, joka lähetetään link-local-lähteestä hyppylimitillä 255. Ennen kuin ydin käyttää sitä, se tarkistaa liitännän accept_ra-arvon. Oletusarvo on 1, eikä 1 tarkoita kyllä. Se tarkoittaa: hyväksy vain niin kauan kuin tämä isäntä ei välitä edelleen. Aseta forwarding=1, niin tämä ehto ei täyty, joten ilmoitus hylätään ennen kuin siinä olevaa prefiksiä tai oletusreititintä harkitaan.

Arvoja on kolme, ja edelleenlähetyksestä selviää vain kolmas:

Kaksi muuta lippua päättävät, mitä itse asiassa asennetaan. accept_ra_defrtr ohjaa, tuleeko ilmoituksen oletusreitittimestä reitti, ja accept_ra_pinfo ohjaa, käytetäänkö prefiksitietoa osoitteen konfigurointiin. accept_ra_defrtr-kohdan poiskytkeminen on tavallinen tapa pitää SLAAC-osoitteet edelleen välittävässä isännässä oppimatta oletusreittiä. Se on eri vipu kuin accept_ra, ja siihen tartutaan, kun halutaan osoitteita mutta ei reittiä. Ytimen IP sysctl -viite luettelee kaikki kolme.

Vahvista se kolmella komennolla

Lue ensin elävät arvot sen sijaan, että luottaisit tiedostoon, jonka luulet olevan ladattu:

sysctl net.ipv6.conf.eth0.forwarding net.ipv6.conf.all.forwarding \
       net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_defrtr

Toiseksi osoita, että ilmoituksia tulee edelleen. Suodatus ICMPv6:n tyyppitavun perusteella riittää, ja se säästää naapureiden etsintäliikenteen seinän lukemiselta:

tcpdump -ni eth0 'icmp6 and ip6[40] == 134'

Jos mitään ei ilmesty useaan minuuttiin, accept_ra ei ole sinun ongelmasi. Ylävirta lakkasi ilmoittamasta, jokin polulla suodattaa ICMPv6:ta tai liitäntä ei oikeasti ole siinä segmentissä, jota luulet. Kolmanneksi pyydä ilmoitus itse ja lue sen kentät:

rdisc6 eth0

rdisc6 tulee ndisc6-paketissa Debianissa ja Ubuntussa. Katso tulosteesta reitittimen elinaika ja preferenssi ennen kuin muutat mitään muuta. Ilmoitus, jonka reitittimen elinaika on 0, on käsky poistaa oletusreititin, eikä mikään accept_ra-arvo tee siitä käyttökelpoista reittiä. Näin saat myös kiinni sillaksi asetetun ylävirran CPE:n, joka jakaa prefiksejä mutta ei koskaan tarjoa itseään reitittimenä.

Tee uplinkista ainoa salliva liitäntä

Jos ylävirran pitäisi olla oletusreititin, hyväksy ilmoitukset siellä edelleenlähetyksestä huolimatta, äläkä missään muualla:

# /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 = 1

Rajaus on tärkeää, koska IPv6-edelleenlähetys on Linuxissa yksi globaali kytkin, ei yksi linkkiä kohden. Kirjoita 1 kohtaan net.ipv6.conf.wg0.forwarding ja lue sitten net.ipv6.conf.all.forwarding: globaali arvo kääntyy ja jokainen liitäntä alkaa välittää. Et voi olla reititin tunnelissa ja tavallinen isäntä lähiverkossa. Rajata voi vain hyväksymisen. Pidä accept_ra=2 uplinkissa ja jätä tunnelin ja lähiverkon liitännät arvoon 1 tai 0, jotta tunnelin kautta tuleva harhailut ilmoitus ei voi asentaa siihen osoittavaa oletusreittiä.

Väliaikainen sysctl -w ei selviä seuraavasta käynnistyksestä, ja sekä systemd-networkd että NetworkManager kirjoittavat nämä arvot omasta konfiguraatiostaan. Aseta networkdissa IPv6Forwarding=yes ja IPv6AcceptRA=yes uplinkin .network-tiedostoon; networkd dokumentoi IPv6Forwardingin globaaliksi samasta ytimen syystä. NetworkManagerissa uplinkin ipv6.method=auto ohjaa accept_ra-arvoa, joten lue sysctl uudelleen nmcli connection up jälkeen sen sijaan, että luottaisit ensimmäiseen tarkistukseen.

Staattinen vaihtoehto, ip -6 route add default via fe80::1 dev eth0, toimii kyllä, ja se on järkevä vastaus, kun ylävirran reitittimellä on vakaa link-local-osoite. Ole selvillä siitä, mistä luovut. Staattista oletusreittiä ei koskaan uusita eikä peruta, joten se osoittaa edelleen kuolleeseen naapuriin sen jälkeen, kun ylävirta on vaihdettu. RA-reitti epäonnistuu turvallisesti; staattinen epäonnistuu hiljaa.

Testaa välitettyä pakettia, älä yhdyskäytävän omaa

Yhdyskäytävän omat pingit voivat onnistua reitillä, jota mikään asiakas ei voi käyttää, ja ne voivat onnistua myös siksi, että yhdyskäytävä on lähde. Testaa kytketystä asiakkaasta ja kysy sitten yhdyskäytävältä, mitä se tekisi kyseisen asiakkaan osoitteelle:

# 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::2

Odota sitten yksi reitittimen elinaika ja katso uudelleen. Haluamasi vakaa tila on oletusreitti, joka on merkitty proto ra ja jonka expires-arvo nollautuu jatkuvasti, sekä all.forwarding=1. Jos expires vain laskee alaspäin, ilmoituksia hylätään edelleen jossain, ja tavallinen syyllinen on verkkohallinta, joka kirjoittaa accept_ra-kohdan yli sen jälkeen, kun käynnistyksen sysctl on jo ajanut.

Ennen kuin suljet tämän, vahvista neljä asiaa: oletusreitti on proto ra ja uusiutuu, accept_ra=2 koskee vain uplinkia, edelleenlähetys on edelleen 1 uudelleenkäynnistyksen ja hallinnan uudelleenkäynnistyksen jälkeen, ja IPv6-pingin suorittaa asiakas eikä yhdyskäytävä. Jos asiakas epäonnistuu silti terveellä reitillä, seuraava epäilty on paluupolku tai ylävirran palomuuri, ei ilmoitus.