Linux ичинде багыттоону күйгүзгөндөн кийин IPv6 демейки маршруту жоголду
IPv6 багыттоо күйгүзүлгөндө ядро uplink боюндагы router advertisements терди этибарга албайт, ошондуктан үйрөнгөн демейки маршрут бүтөт. Муну accept_ra менен оңдогула.
VPN кардарларынын трафигин өткөрүшү үчүн Debian шлюзине net.ipv6.conf.all.forwarding=1 койдум, ал эми жарым сааттай убакыттан кийин машинада IPv6 демейки маршруту такыр калбады. Жогорку маршрутизатор иштеп жаткан, link-local кошунасы дагы деле жооп берип жаткан, ал эми uplink өзүнүн глобалдык дарегин сактап турган. Токтогону ядронун ошол интерфейсте router advertisements кабыл алууну улантууга болгон ышкысы эле. Мен sysctl киргизген учурда маршрут жоголгон жок; ал RA аркылуу үйрөнгөн демейки маршруттун өмүрү бүткөндө жоголду жана аны эч нерсе жаңырткан жок.
Бир караганда эч нерсе бузулгандай көрүнгөн жок. Багыттоо иштеди, эски маршрут кэште турганда кардарлар өтүп турду, ал эми бузулуу аны пайда кылган өзгөртүүдөн кийин келди. Так ушул кечигүү бул көйгөйдү жогорку тарапка же эч качан катышпаган firewall эрежесине жабууга себеп болот.
Каалаган sysctl'ге тийүүдөн мурун маршрут таблицасын окуңуз
ip -6 route show default менен баштап, атрибуттарды окуңуз, шлюзду гана эмес. RA аркылуу үйрөнгөн демейки маршрут proto ra деп белгиленген, артыкчылык алып жүрөт жана expires артка эсебин көрсөтөт. Кол менен кошулган маршрутта экөө тең жок, жана бул айырма маршрутка кайсы механизм ээ экенин айтып берет.
$ ip -6 route show default
default via fe80::1 dev eth0 proto ra metric 1024 expires 1432sec hoplimit 64 pref mediumАндан кийин дарекке караңыз: ip -6 addr show dev eth0. Саат менен өлчөнгөн артыкчылыктуу жана жарактуу өмүрү бар глобалдык дарек, маршрутизатор өмүрү мүнөт менен өлчөнгөн демейки маршруттан узак жашайт. Дарек бар, демейки маршрут жок, бул жарыялоо көйгөйүнүн белгиси. Дарек да жок болсо, эң оболу байланышты, префикс жөнүндө маалыматты же кайталанган даректерди аныктоону кароо керек.
Эмне үчүн багыттоо RA иштетүүнү өчүрөт
RA дегенибиз 134 тибиндеги ICMPv6 пакети, ал 255 секирүү чеги менен link-local булактан жөнөтүлөт. Ядро аны колдонуудан мурун интерфейстин accept_ra маанисин текшерет. Демейки маани 1, ал эми 1 «ооба» дегенди билдирбейт. Ал: ушул хост багыттабаганча кабыл ал дегенди билдирет. forwarding=1 маанисин койсоңуз, бул шарт аткарылбайт, ошондуктан жарыялоо ичиндеги каалаган префикс же демейки маршрутизатор каралбастан эле ташталат.
Үч маани бар, багыттоодон үчүнчүсү гана аман калат:
accept_ra | forwarding=0 | forwarding=1 |
|---|---|---|
| 0 | ignored | ignored |
| 1 (default) | accepted | ignored |
| 2 | accepted | accepted |
Дагы эки желек эмне чындап орнотуларын чечет. accept_ra_defrtr жарыялоодогу демейки маршрутизатордун маршрутка айланышын башкарат, ал эми accept_ra_pinfo префикс жөнүндө маалыматтын дарек конфигурациясына колдонулушун башкарат. accept_ra_defrtr өчүрүү — багыттап жаткан хостто демейки маршрутту үйрөнбөстөн SLAAC даректерин сактоонун кадимки жолу. Бул accept_ra ден башка рычаг, жана дарек керек, маршрут керек болбогондо ошого кайрыласыз. Ядронун IP sysctl боюнча колдонмосу үчөөнү тең тизет.
Муну үч буйрук менен ырастаңыз
Алгач жүктөлдү деп ойлогон файлдын ордуна тирүү маанилерди окуңуз:
sysctl net.ipv6.conf.eth0.forwarding net.ipv6.conf.all.forwarding \
net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_defrtrЭкинчиден, жарыялоолор дагы деле келерин далилдеңиз. ICMPv6 тип байты боюнча чыпкалоо жетиштүү жана кошуналарды аныктоо трафигинин дубалын окуудан сактайт:
tcpdump -ni eth0 'icmp6 and ip6[40] == 134'Эгер бир нече мүнөттүн ичинде эч нерсе көрүнбөсө, accept_ra сиздин көйгөйүңүз эмес. Жогорку тарап жарыялоону токтотту, жолдогу бир нерсе ICMPv6 чыпкалайт же бул интерфейс чындыгында сиз ойлогон сегментте эмес. Үчүнчүдөн, жарыялоону өзүңүз сурап, анын талааларын окуңуз:
rdisc6 eth0rdisc6 Debian жана Ubuntu'да ndisc6 пакетинде келет. Чыгуудан маршрутизатор өмүрүн жана артыкчылыкты караңыз, башка нерсени өзгөртүүдөн мурун. Маршрутизатор өмүрү 0 болгон жарыялоо демейки маршрутизаторду алып салуу жөнүндө буйрук, жана эч бир accept_ra мааниси аны пайдалуу маршрутка айландырбайт. Ошентип көпүрө режиминдеги жогорку CPE'ни да кармайсыз, ал префикстерди таратат, бирок өзүн маршрутизатор катары сунуштабайт.
Uplink'ти жалгыз уруксат берүүчү интерфейс кыл
Эгер жогорку тарап демейки маршрутизатор болушу керек болсо, багыттоого карабастан жарыялоолорду ошол жерде кабыл алыңыз, башка жерде эмес:
# /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Чектөө маанилүү, анткени Linux'те IPv6 багыттоо бир глобалдык которгуч, ар бир байланышка бир эмес. net.ipv6.conf.wg0.forwarding ичине 1 жазып, анан net.ipv6.conf.all.forwarding окуңуз: глобалдык маани оодарылат жана ар бир интерфейс багыттай баштайт. Сиз туннелде маршрутизатор, ал эми LAN'да жөнөкөй хост боло албайсыз. Чектесе боло турганы — кабыл алуу. accept_ra=2 маанисин uplink'те кармап, туннель жана LAN интерфейстерин 1 же 0'до калтырыңыз, ошондо туннель аркылуу келген адашкан жарыялоо ага багытталган демейки маршрутту орното албайт.
Убактылуу sysctl -w кийинки кайра жүктөөдөн аман калбайт, ал эми systemd-networkd да, NetworkManager да бул маанилерди өз конфигурациясынан жазышат. networkd'те uplink'тин .network файлында IPv6Forwarding=yes жана IPv6AcceptRA=yes орнотуңуз; networkd IPv6Forwarding'ди ядродогу ошол эле себептен глобалдык деп сүрөттөйт. NetworkManager'де uplink'теги ipv6.method=auto accept_ra маанисин башкарат, ошондуктан nmcli connection up кийин sysctl'ди кайра окуңуз, биринчи текшерүүгө ишенбей.
Статикалык балама, ip -6 route add default via fe80::1 dev eth0, чын эле иштейт жана жогорку маршрутизатордун туруктуу link-local дареги болгондо акылга сыярлык жооп. Эмнеден баш тартканыңызды так билиңиз. Статикалык демейки маршрут эч качан жаңыртылбайт жана эч качан кайтарылбайт, ошондуктан жогорку тарап алмаштырылгандан кийин да өлүк кошунага көрсөтө берет. RA маршруту коопсуз түрдө иштебей калат; статикалык маршрут үнсүз иштебей калат.
Шлюздун өз пакетин эмес, багытталган пакетти текшериңиз
Шлюздун өз пинглери эч бир кардар колдона албаган маршрут менен ийгиликтүү өтүшү мүмкүн, жана шлюз булак болгондуктан да ийгиликтүү болушу мүмкүн. Туташкан кардардан текшериңиз, анан шлюзден ошол кардардын дареги үчүн эмне кыларын сураңыз:
# 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Анан бир маршрутизатор өмүрүн күтүп, кайра караңыз. Сиз каалаган туруктуу абал — proto ra деп белгиленген демейки маршрут, анын expires мааниси тынымсыз калыбына келет, кошумча all.forwarding=1. Эгер expires эсепти гана артка жүргүзсө, жарыялоолор дагы деле бир жерде ташталып жатат, ал эми кадимки күнөөлүү — жүктөө учурундагы sysctl аткарылып бүткөндөн кийин accept_ra маанисин кайра жаза турган тармак менеджери.
Муну жаппас мурда төрт нерсени ырастаңыз: демейки маршрут proto ra жана жаңырып турат, accept_ra=2 uplink'ке гана тиешелүү, багыттоо кайра жүктөөдөн кийин да, менеджер кайра иштетилгенден кийин да 1, жана IPv6 пингди шлюз эмес, кардар бүтүрөт. Эгер кардар соо маршрут менен дагы деле ийгиликсиз болсо, кийинки шектүү — кайтаруу жолу же жогорку firewall, жарыялоо эмес.