Diflannodd y llwybr diofyn IPv6 ar ôl galluogi anfon ymlaen ar Linux

Gosodais net.ipv6.conf.all.forwarding=1 ar borth Debian fel y gallai anfon traffig cleientiaid VPN ymlaen, a rhyw hanner awr yn ddiweddarach nid oedd gan y peiriant unrhyw lwybr diofyn IPv6 ar ôl. Roedd y llwybrydd uwchrif yn fyw, roedd y cymydog link-local yn dal i ateb, ac roedd yr uplink yn dal i gadw ei gyfeiriad byd-eang. Y peth a oedd wedi stopio oedd parodrwydd y cnewyllyn i ddal i dderbyn router advertisements ar y rhyngwyneb hwnnw. Ni ddiflannodd y llwybr pan deipiais y sysctl; diflannodd pan ddaeth oes y llwybr diofyn a ddysgwyd gan RA i ben ac ni wnaeth unrhyw beth ei adnewyddu.

Nid oedd unrhyw beth yn edrych yn doredig ar yr olwg gyntaf. Roedd yr anfon ymlaen yn gweithio, roedd cleientiaid yn dal i ddod trwodd tra oedd yr hen lwybr yn y storfa, ac fe gyrhaeddodd y methiant yn hwyrach na'r newid a achosodd ef. Yr oedi hwnnw yw'r rheswm pam y beïir yr uplink neu reol wal dân na fu erioed yn rhan o'r mater.

Darllenwch y tabl llwybrau cyn cyffwrdd ag unrhyw sysctl

Dechreuwch gyda ip -6 route show default a darllenwch y priodoleddau, nid y porth yn unig. Mae llwybr diofyn a ddysgwyd gan RA wedi'i farcio â proto ra, yn cario ffafriaeth ac yn dangos cyfrif i lawr expires. Nid oes gan lwybr a ychwanegwyd â llaw y naill na'r llall, ac mae'r gwahaniaeth hwnnw'n dweud wrthych pa fecanwaith sy'n berchen ar y llwybr.

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

Yna edrychwch ar y cyfeiriad: ip -6 addr show dev eth0. Bydd cyfeiriad byd-eang ag oesau ffafriol a dilys a fesurir mewn oriau yn goroesi llwybr diofyn y mae ei oes llwybrydd yn cael ei mesur mewn munudau. Cyfeiriad yn bresennol a'r llwybr diofyn ar goll yw llofnod problem hysbysebu. Os yw'r cyfeiriad hefyd ar goll, y cysylltiad, y wybodaeth ragddodiad neu'r canfod cyfeiriadau dyblyg sydd i'w hela yn gyntaf.

Pam mae anfon ymlaen yn diffodd prosesu RA

Mae RA yn becyn ICMPv6 o fath 134, a anfonir o ffynhonnell link-local â therfyn naid 255. Cyn i'r cnewyllyn ei ddefnyddio, mae'n ymgynghori â accept_ra y rhyngwyneb. Y gwerth diofyn yw 1, ac nid yw 1 yn golygu ie. Mae'n golygu: derbyn dim ond tra nad yw'r gwesteiwr hwn yn anfon ymlaen. Gosodwch forwarding=1 ac mae'r amod hwnnw'n methu, felly mae'r hysbysiad yn cael ei ollwng cyn i unrhyw ragddodiad neu lwybrydd diofyn ynddo gael ei ystyried.

Mae tri gwerth yn bodoli, a dim ond y trydydd sy'n goroesi anfon ymlaen:

Mae dau faner arall yn penderfynu beth sy'n cael ei osod mewn gwirionedd. Mae accept_ra_defrtr yn rheoli a yw'r llwybrydd diofyn yn yr hysbysiad yn dod yn llwybr, ac mae accept_ra_pinfo yn rheoli a yw gwybodaeth ragddodiad yn cael ei defnyddio ar gyfer ffurfweddu cyfeiriad. Diffodd accept_ra_defrtr yw'r ffordd arferol o gadw cyfeiriadau SLAAC ar westeiwr sy'n anfon ymlaen heb ddysgu llwybr diofyn. Mae'n lifer gwahanol i accept_ra, a dyma'r un i'w defnyddio pan fyddwch am gyfeiriadau ond nid llwybr. Mae cyfeirlyfr IP sysctl y cnewyllyn yn rhestru'r tri.

Cadarnhewch hyn gyda thri gorchymyn

Yn gyntaf, darllenwch y gwerthoedd byw yn lle'r ffeil y credwch ei bod wedi'i llwytho:

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

Yn ail, profwch fod yr hysbysiadau'n dal i gyrraedd. Mae hidlo ar faeit math ICMPv6 yn ddigon ac mae'n arbed darllen wal o draffig canfod cymdogion:

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

Os na ddaw dim i'r golwg dros sawl munud, nid accept_ra yw eich problem. Mae'r ochr uwchrif wedi rhoi'r gorau i hysbysebu, mae rhywbeth ar y llwybr yn hidlo ICMPv6, neu nid yw'r rhyngwyneb hwnnw mewn gwirionedd ar y segment rydych yn ei feddwl. Yn drydydd, gofynnwch am hysbysiad eich hun a darllenwch ei feysydd:

rdisc6 eth0

Mae rdisc6 yn dod yn y pecyn ndisc6 ar Debian ac Ubuntu. Yn yr allbwn, edrychwch ar oes y llwybrydd a'r ffafriaeth cyn newid unrhyw beth arall. Mae hysbysiad ag oes llwybrydd o 0 yn gyfarwyddyd i ddileu'r llwybrydd diofyn, ac nid oes unrhyw werth accept_ra yn troi hynny'n llwybr defnyddiadwy. Dyma hefyd sut i ddal CPE uwchrif mewn modd pont sy'n dosbarthu rhagddodiadau ond nad yw byth yn cynnig ei hun fel llwybrydd.

Gwnewch yr uplink yr unig ryngwyneb caniatäol

Os dylai'r ochr uwchrif fod y llwybrydd diofyn, derbyniwch hysbysiadau yno er gwaethaf anfon ymlaen, ac yn unman arall:

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

Mae'r cwmpasu yn bwysig oherwydd bod anfon ymlaen IPv6 yn Linux yn un swits byd-eang, nid un fesul cysylltiad. Ysgrifennwch 1 i net.ipv6.conf.wg0.forwarding ac yna darllenwch net.ipv6.conf.all.forwarding: mae'r gwerth byd-eang yn gwrthdroi ac mae pob rhyngwyneb yn dechrau anfon ymlaen. Ni allwch fod yn llwybrydd ar y tiwnel ac yn westeiwr cyffredin ar y LAN. Yr hyn y gallwch ei gwmpasu yw'r derbyniad. Cadwch accept_ra=2 ar yr uplink a gadewch ryngwynebau'r tiwnel a'r LAN ar 1 neu 0, fel na all hysbysiad crwydrol sy'n cyrraedd dros y tiwnel osod llwybr diofyn sy'n pwyntio iddo.

Ni fydd sysctl -w dros dro yn goroesi'r ailgychwyn nesaf, ac mae systemd-networkd a NetworkManager ill dau yn ysgrifennu'r gwerthoedd hyn o'u ffurfweddiad eu hunain. Yn networkd, gosodwch IPv6Forwarding=yes a IPv6AcceptRA=yes yn ffeil .network yr uplink; mae networkd yn dogfennu IPv6Forwarding fel un byd-eang am yr un rheswm cnewyllyn. Gyda NetworkManager, ipv6.method=auto ar yr uplink sy'n gyrru gwerth accept_ra, felly darllenwch y sysctl eto ar ôl nmcli connection up yn lle trystio'r archwiliad cyntaf.

Mae'r dewis statig, ip -6 route add default via fe80::1 dev eth0, yn gweithio, ac mae'n ateb rhesymol pan fo gan lwybrydd yr ochr uwchrif gyfeiriad link-local sefydlog. Byddwch yn glir ynghylch yr hyn a ildiwch. Nid yw llwybr diofyn statig byth yn cael ei adnewyddu na'i dynnu yn ôl, felly mae'n parhau i bwyntio at gymydog marw ar ôl i'r ochr uwchrif gael ei disodli. Mae llwybr RA yn methu'n ddiogel; mae'r un statig yn methu'n dawel.

Profwch becyn a anfonwyd ymlaen, nid un y porth ei hun

Gall ping y porth ei hun lwyddo ar lwybr na all unrhyw gleient ei ddefnyddio, a gallant lwyddo hefyd oherwydd mai'r porth yw'r ffynhonnell. Profwch o gleient sydd wedi'i gysylltu, ac yna gofynnwch i'r porth beth a wnâi ar gyfer cyfeiriad y cleient hwnnw:

# 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

Yna arhoswch un oes llwybrydd ac edrychwch eto. Y cyflwr sefydlog rydych ei eisiau yw llwybr diofyn wedi'i farcio â proto ra y mae ei werth expires yn ailosod yn barhaus, ynghyd â all.forwarding=1. Os mai dim ond cyfrif i lawr y mae expires yn ei wneud, mae hysbysiadau'n dal i gael eu gollwng yn rhywle, a'r tramgwyddwr arferol yw rheolwr rhwydwaith sy'n ailysgrifennu accept_ra ar ôl i'r sysctl ar amser cychwyn fod wedi rhedeg yn barod.

Cyn i chi gau hyn, cadarnhewch bedair peth: mae'r llwybr diofyn yn proto ra ac yn adnewyddu, mae accept_ra=2 yn berthnasol i'r uplink yn unig, mae anfon ymlaen yn dal i fod yn 1 ar ôl ailgychwyn ac ar ôl ailgychwyn y rheolwr, a chleient yn hytrach na'r porth sy'n cwblhau ping IPv6. Os yw'r cleient yn parhau i fethu gyda llwybr iach, y sawl a amheuir nesaf yw'r llwybr dychwelyd neu wal dân uwchrif, nid yr hysbysiad.