Rruga e parazgjedhur IPv6 u zhduk pas aktivizimit të përcjelljes në Linux

Vendosa net.ipv6.conf.all.forwarding=1 në një portë Debian që të mund të përcillte trafikun e klientëve VPN, dhe rreth gjysmë ore më vonë makina nuk kishte më asnjë rrugë të parazgjedhur IPv6. Routeri i sipërm ishte aktiv, fqinji link-local ende përgjigjej dhe uplink-u mbante ende adresën e tij globale. Ajo që ishte ndalur ishte gatishmëria e kernel-it për të vazhduar të pranonte router advertisements në atë ndërfaqe. Rruga nuk u zhduk kur shkrova sysctl-in; u zhduk kur mbaroi jetëgjatësia e rrugës së parazgjedhur të mësuar nga RA dhe asgjë nuk e rinovoi atë.

Në shikim të parë asgjë nuk dukej e prishur. Përcjellja funksiononte, klientët vazhdonin të kalonin sa kohë rruga e vjetër ishte ende në cache, dhe dështimi erdhi më vonë se ndryshimi që e shkaktoi. Pikërisht ky vonesë është arsyeja pse fajin e marrin ana e sipërme ose një rregull firewall-i që nuk ishte përfshirë kurrë.

Lexoni tabelën e rrugëve përpara se të prekni çdo sysctl

Filloni me ip -6 route show default dhe lexoni atributet, jo vetëm portën. Një rrugë e parazgjedhur e mësuar nga RA shënohet me proto ra, mbart një preferencë dhe tregon një numërim mbrapsht expires. Një rrugë e shtuar me dorë nuk ka asnjërën, dhe ky ndryshim ju tregon se cili mekanizëm zotëron rrugën.

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

Pastaj shikoni adresën: ip -6 addr show dev eth0. Një adresë globale me jetëgjatësi të preferuar dhe të vlefshme të matura në orë do të mbijetojë një rrugë të parazgjedhur, jetëgjatësia e routerit të së cilës matet në minuta. Adresa ekziston dhe rruga e parazgjedhur mungon, ky është nënshkrimi i një problemi me njoftimet. Nëse mungon edhe adresa, së pari duhet ndjekur lidhja, informacioni i prefiksit ose zbulimi i adresave të dyfishta.

Pse përcjellja e fik përpunimin e RA

Një RA është një paketë ICMPv6 e tipit 134, e dërguar nga një burim link-local me kufi hop-i 255. Përpara se kernel-i ta përdorë, ai konsulton accept_ra e ndërfaqes. Vlera e parazgjedhur është 1, dhe 1 nuk do të thotë po. Do të thotë: prano vetëm sa kohë ky host nuk përcjell. Vendosni forwarding=1 dhe ai kusht nuk plotësohet, kështu që njoftimi hidhet poshtë përpara se të merret parasysh ndonjë prefiks ose router i parazgjedhur në të.

Ekzistojnë tre vlera, dhe vetëm e treta i mbijeton përcjelljes:

Dy flamuj të tjerë vendosin se çfarë instalohet në të vërtetë. accept_ra_defrtr kontrollon nëse routeri i parazgjedhur në njoftim bëhet rrugë, dhe accept_ra_pinfo kontrollon nëse informacioni i prefiksit përdoret për konfigurimin e adresës. Fikja e accept_ra_defrtr është mënyra e zakonshme për të mbajtur adresat SLAAC në një host që përcjell pa mësuar një rrugë të parazgjedhur. Është një levë tjetër nga accept_ra, dhe është ajo që përdoret kur dëshironi adresa por jo rrugë. Referenca e kernel-it për IP sysctl i liston të treja.

Konfirmojeni me tre komanda

Së pari, lexoni vlerat e gjalla në vend të skedarit që mendoni se është i ngarkuar:

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

Së dyti, provoni se njoftimet ende vijnë. Filtrimi sipas bitit të tipit ICMPv6 mjafton, dhe ju kursen leximin e një muri trafiku zbulimi fqinjësh:

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

Nëse asgjë nuk shfaqet për disa minuta, accept_ra nuk është problemi juaj. Ana e sipërme ndaloi së njoftuari, diçka në rrugë filtron ICMPv6, ose ajo ndërfaqe nuk është vërtet në segmentin që mendoni. Së treti, kërkoni vetë një njoftim dhe lexoni fushat e tij:

rdisc6 eth0

rdisc6 vjen në paketën ndisc6 në Debian dhe Ubuntu. Në dalje, shikoni jetëgjatësinë e routerit dhe preferencën përpara se të ndryshoni çdo gjë tjetër. Një njoftim me jetëgjatësi routeri 0 është udhëzim për të hequr routerin e parazgjedhur, dhe asnjë vlerë accept_ra nuk e kthen atë në një rrugë të përdorshme. Kështu kapni edhe një CPE të sipërm në modalitet ura që shpërndan prefikse por nuk e ofron kurrë veten si router.

Bëjeni uplink-un të vetmen ndërfaqe lejuese

Nëse ana e sipërme duhet të jetë routeri i parazgjedhur, pranoni njoftimet atje pavarësisht përcjelljes, dhe askund tjetër:

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

Kufizimi ka rëndësi sepse përcjellja IPv6 në Linux është një ndërprerës global, jo një për çdo lidhje. Shkruani 1 në net.ipv6.conf.wg0.forwarding dhe pastaj lexoni net.ipv6.conf.all.forwarding: vlera globale përmbyset dhe çdo ndërfaqe fillon të përcjellë. Nuk mund të jeni router në tunel dhe host i zakonshëm në LAN. Ajo që mund të kufizoni është pranimi. Mbani accept_ra=2 në uplink dhe lërini ndërfaqet e tunelit dhe të LAN-it në 1 ose 0, që një njoftim i humbur që vjen përmes tunelit të mos mund të instalojë një rrugë të parazgjedhur që tregon brenda tij.

Një sysctl -w i përkohshëm nuk do t'i mbijetojë rindezjes tjetër, dhe si systemd-networkd ashtu edhe NetworkManager i shkruajnë këto vlera nga konfigurimi i tyre. Në networkd, vendosni IPv6Forwarding=yes dhe IPv6AcceptRA=yes në skedarin .network të uplink-ut; networkd e dokumenton IPv6Forwarding si global për të njëjtën arsye të kernel-it. Me NetworkManager, ipv6.method=auto në uplink është ai që drejton vlerën accept_ra, prandaj lexoni përsëri sysctl-in pas nmcli connection up në vend që t'i besoni kontrollit të parë.

Alternativa statike, ip -6 route add default via fe80::1 dev eth0, funksionon vërtet, dhe është një përgjigje e arsyeshme kur routeri i sipërm ka një adresë link-local të qëndrueshme. Jini të qartë për atë që hiqni dorë. Një rrugë e parazgjedhur statike nuk rinovohet kurrë dhe nuk tërhiqet kurrë, kështu që vazhdon të tregojë një fqinj të vdekur pasi ana e sipërme zëvendësohet. Rruga nga RA dështon në mënyrë të sigurt; ajo statike dështon në heshtje.

Testoni një paketë të përcjellë, jo atë të portës vetë

Ping-et e portës vetë mund të kenë sukses në një rrugë që asnjë klient nuk mund ta përdorë, dhe mund të kenë sukses edhe sepse porta është burimi. Testoni nga një klient i lidhur dhe pastaj pyesni portën se çfarë do të bënte për adresën e atij klienti:

# 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

Pastaj prisni një jetëgjatësi routeri dhe shikoni përsëri. Gjendja e qëndrueshme që dëshironi është një rrugë e parazgjedhur e shënuar me proto ra, vlera expires e së cilës riniset vazhdimisht, plus all.forwarding=1. Nëse expires vetëm numëron mbrapsht, njoftimet ende hidhen diku, dhe fajtori i zakonshëm është një menaxher rrjeti që rishkruan accept_ra pasi sysctl-i i nisjes tashmë është ekzekutuar.

Përpara se ta mbyllni, konfirmoni katër gjëra: rruga e parazgjedhur është proto ra dhe rinovohet, accept_ra=2 vlen vetëm për uplink-un, përcjellja është ende 1 pas një rindezjeje dhe pas rindezjes së menaxherit, dhe një klient, jo porta, përfundon një ping IPv6. Nëse klienti ende dështon me një rrugë të shëndoshë, i dyshuari tjetër është rruga e kthimit ose një firewall i sipërm, jo njoftimi.