Nawala ang default na ruta ng IPv6 matapos i-enable ang forwarding sa Linux

Naglagay ako ng net.ipv6.conf.all.forwarding=1 sa isang Debian gateway para makapag-forward ito ng trapiko ng mga VPN client, at mga kalahating oras ang lumipas, wala nang natirang default na ruta ng IPv6 sa makina. Buhay ang upstream router, sumasagot pa rin ang link-local na kapitbahay, at hawak pa rin ng uplink ang global na address nito. Ang tumigil ay ang pagpayag ng kernel na patuloy na tumanggap ng router advertisements sa interface na iyon. Hindi nawala ang ruta noong tinaip ko ang sysctl; nawala ito noong naubos ang lifetime ng default na rutang natutunan mula sa RA at walang nag-refresh nito.

Walang mukhang sira sa unang tingin. Gumagana ang forwarding, nakakalusot pa ang mga client habang nasa cache pa ang lumang ruta, at dumating ang pagkabigo nang mas huli kaysa sa pagbabagong nagdulot nito. Ang pagkaantala na iyon ang dahilan kung bakit ito ibinabaling sa upstream o sa isang firewall rule na hindi naman kailanman nasangkot.

Basahin ang talahanayan ng ruta bago hipuin ang anumang sysctl

Magsimula sa ip -6 route show default at basahin ang mga attribute, hindi lang ang gateway. Ang default na rutang natutunan mula sa RA ay may markang proto ra, may dalang preference at nagpapakita ng countdown na expires. Ang rutang idinagdag mo nang manu-mano ay wala sa dalawa, at ang pagkakaibang iyon ang nagsasabi kung aling mekanismo ang may-ari ng ruta.

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

Tingnan naman ang address: ip -6 addr show dev eth0. Ang global na address na may preferred at valid na lifetime na sinusukat sa oras ay mas matagal pang mabubuhay kaysa sa default na rutang ang router lifetime ay sinusukat sa minuto. May address pero walang default na ruta, iyon ang pirma ng problema sa advertisement. Kung wala rin ang address, ang link, ang prefix information o ang duplicate address detection ang dapat unahing habulin.

Bakit pinapatay ng forwarding ang pagpoproseso ng RA

Ang RA ay isang ICMPv6 packet na type 134, ipinapadala mula sa link-local na pinagmulan na may hop limit na 255. Bago ito gamitin ng kernel, sinasangguni nito ang accept_ra ng interface. Ang default na halaga ay 1, at ang 1 ay hindi nangangahulugang oo. Ibig sabihin: tanggapin lamang habang hindi nagfo-forward ang host na ito. Itakda ang forwarding=1 at nabigo ang kondisyong iyon, kaya itinatapon ang advertisement bago pa isaalang-alang ang anumang prefix o default na router sa loob nito.

May tatlong halaga, at ang pangatlo lamang ang nakakaligtas sa forwarding:

Dalawang iba pang flag ang nagpapasya kung ano talaga ang naka-install. Kinokontrol ng accept_ra_defrtr kung ang default na router sa advertisement ay magiging ruta, at kinokontrol ng accept_ra_pinfo kung gagamitin ang prefix information para sa configuration ng address. Ang pag-off sa accept_ra_defrtr ang karaniwang paraan para mapanatili ang mga SLAAC address sa isang host na nagfo-forward nang hindi natututo ng default na ruta. Ibang lever ito kaysa sa accept_ra, at ito ang ginagamit kapag gusto mo ng address pero hindi ng ruta. Inililista ng reference ng kernel sa IP sysctl ang tatlo.

Kumpirmahin gamit ang tatlong utos

Una, basahin ang live na halaga sa halip na ang file na inaakala mong naka-load:

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

Ikalawa, patunayan na dumarating pa rin ang mga advertisement. Sapat ang pag-filter sa type byte ng ICMPv6, at iniiwasan nito ang pagbasa ng pader ng trapiko ng neighbor discovery:

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

Kung walang lumilitaw sa loob ng ilang minuto, hindi accept_ra ang problema mo. Tumigil sa pag-advertise ang upstream, may nagfi-filter ng ICMPv6 sa daan, o talagang wala ang interface na iyon sa segment na iniisip mo. Ikatlo, humingi ka mismo ng advertisement at basahin ang mga field nito:

rdisc6 eth0

Ang rdisc6 ay kasama sa paketeng ndisc6 sa Debian at Ubuntu. Sa output, tingnan ang router lifetime at ang preference bago magbago ng anupaman. Ang advertisement na may router lifetime na 0 ay utos na alisin ang default na router, at walang halaga ng accept_ra ang gagawa nitong magamit na ruta. Ganito rin mahuhuli ang isang upstream CPE sa bridge mode na namimigay ng prefix pero hindi kailanman nag-aalok ng sarili bilang router.

Gawing ang uplink ang tanging pumapayag na interface

Kung ang upstream ang dapat maging default na router, tumanggap ng advertisement doon kahit may forwarding, at wala sa ibang lugar:

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

Mahalaga ang saklaw dahil ang IPv6 forwarding sa Linux ay isang global na switch, hindi isa kada link. Isulat ang 1 sa net.ipv6.conf.wg0.forwarding at pagkatapos basahin ang net.ipv6.conf.all.forwarding: bumabaligtad ang global na halaga at nagsisimulang mag-forward ang bawat interface. Hindi ka maaaring maging router sa tunnel at ordinaryong host sa LAN. Ang maaari mong limitahan ay ang pagtanggap. Panatilihin ang accept_ra=2 sa uplink at iwanan ang tunnel at LAN interface sa 1 o 0, para ang ligaw na advertisement na dumarating sa tunnel ay hindi makapag-install ng default na rutang nakaturo roon.

Ang pansamantalang sysctl -w ay hindi makakaligtas sa susunod na reboot, at parehong systemd-networkd at NetworkManager ay nagsusulat ng mga halagang ito mula sa sarili nilang configuration. Sa networkd, itakda ang IPv6Forwarding=yes at IPv6AcceptRA=yes sa .network file ng uplink; dokumentado ng networkd ang IPv6Forwarding bilang global dahil sa parehong dahilan sa kernel. Sa NetworkManager, ang ipv6.method=auto sa uplink ang nagpapatakbo ng halaga ng accept_ra, kaya basahin muli ang sysctl pagkatapos ng nmcli connection up sa halip na magtiwala sa unang check.

Gumagana talaga ang static na alternatibo, ip -6 route add default via fe80::1 dev eth0, at makatwirang sagot ito kapag ang upstream router ay may stable na link-local address. Maging malinaw sa isinusuko mo. Ang static na default na ruta ay hindi kailanman nire-refresh at hindi kailanman binabawi, kaya patuloy itong nakaturo sa patay na kapitbahay matapos palitan ang upstream. Nabigo nang ligtas ang rutang RA; tahimik na nabigo ang static.

Subukan ang forwarded na packet, hindi ang sarili ng gateway

Ang sariling ping ng gateway ay maaaring magtagumpay sa rutang walang client na makakagamit, at maaari rin itong magtagumpay dahil ang gateway ang pinagmulan. Subukan mula sa konektadong client, pagkatapos tanungin ang gateway kung ano ang gagawin nito para sa address ng client na iyon:

# 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

Pagkatapos maghintay ng isang router lifetime at tumingin muli. Ang stable na kalagayang gusto mo ay isang default na rutang may markang proto ra na patuloy na nagre-reset ang halaga ng expires, kasama ang all.forwarding=1. Kung pababa lang nang pababa ang expires, may itinatapon pa ring advertisement sa isang lugar, at ang karaniwang salarin ay isang network manager na nagsusulat muli ng accept_ra matapos nang maipatupad ang sysctl sa boot.

Bago mo isara ito, kumpirmahin ang apat na bagay: ang default na ruta ay proto ra at nagre-refresh, accept_ra=2 ay para lang sa uplink, 1 pa rin ang forwarding pagkatapos ng reboot at pagkatapos i-restart ang manager, at isang client, hindi ang gateway, ang nagtatapos ng IPv6 ping. Kung nabibigo pa rin ang client na may malusog na ruta, ang susunod na hinala ay ang return path o isang upstream firewall, hindi ang advertisement.