IPv6 рутирање на политики кога две врски делат fe80::1

Имаш две врски, а ip -6 route show го печати истиот следен скок на двете: default via fe80::1 dev uplink0 и default via fe80::1 dev uplink1. Тоа не е конфликт на дупли адреси, а копирањето на голиот следен скок fe80::1 во табела на политика не му кажува на кернелот на која врска мислеше. Вистинското прашање е потесно отколку што сугерира симптомот: и треба на втората табела една врска или двете, и што ги држи тие рути живи по рестарт. Три услови, проверени по ред, решаваат најголем дел.

Истиот fe80::1 се два различни соседи

Линк-локалните адреси се ограничени на една врска, па fe80::1 не е една адреса испечатена двапати; тоа се два соседи што случајно делат суфикс. Зонскиот индекс е како домаќин кажува на кој мисли, па fe80::1%uplink0 и fe80::1%uplink1 се различни одредишта за кернелот, а тој суфикс никогаш не патува до далечен рутер. RFC 4007 го опишува зонскиот модел зад ова, и затоа табелата на политика мора да носи уред со секој линк-локален следен скок.

Генератор на VPN конфигурација што копира нумерички зонски ИД од еден домаќин во шаблон го третира локалниот контекст како да е дел од адресата, а датотеката што ја пишува е погрешна на секоја машина чии имиња или индекси на интерфејси се разликуваат. Ниту табелата на политика не спојува две врски во една: рутиран VPN пренесува пакети меѓу мрежи, но не го пренесува линк-локалниот идентитет на далечен Ethernet сосед низ тунелот, па линк-локалниот сообраќај останува на својата врска.

Отстрани го уредот и рутата станува незапишлива. ip -6 route add default via fe80::1 table 200 не може да го реши гејтвејот, а iproute2 го одбива со Error: Nexthop has invalid gateway. Додај dev uplink0 и командата успева, затоа што уредот е тоа што го прицврстува следниот скок за еден од тие два соседи. Она што уредот не може да ти го каже е дали uplink0 е вистинската врска за оваа табела, а рута копирана од друг домаќин ги носи имињата на интерфејсите на тој домаќин, и оттука доаѓаат вистинските грешки.

Услов еден: една врска или две во табелата

Почни од тоа за што служи втората врска. Ако двете врски носат ист сообраќај и едната е резерва, алтернативната табела треба да ги држи двата гејтвеја со различни метрики: исти одредишта, еден префериран пат, еден очигледен втор избор. Ако врските постојат затоа што различен сообраќај мора да излезе низ различни провајдери, или затоа што ова е split тунел во кој дел од сообраќајот го заобиколува VPN-от додека остатокот останува внатре, двете врски воопшто не припаѓаат на една табела. Тие припаѓаат на две табели, избрани со правило, а правилото ја избира табелата, не тунелот: сообраќајот што заобиколува се означува пред да биде рутиран, и ознаката е тоа што го праќа во втората табела.

Во тој втор случај правилото одлучува кога се консултира табела, а рутата одлучува каде оди пакетот кога тоа ќе се случи:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

Ниту еден од објектите не го заменува другиот, а табела што држи само стандардна рута сепак може да не успее да го реши својот гејтвеј. Ако add се одбие, или рутата постои но е неупотреблива, стави го поврзаниот префикс на тој интерфејс во истата табела, или означи го скокот како onlink кога тој префикс се рутира на друго место. Во блокот погоре, 2001:db8:100::/48 стои за тој поврзан префикс на uplink1, не за произволно одредиште. fwmark правилото троши само ознака што нешто друго мора да ја постави, од nftables или iptables правило на патот на проследување или од SO_MARK на сокетот, па блок копиран без извор на ознака не одговара на ништо.

Услов два: метриките не откриваат мртов провајдер

Метрика е преференција меѓу рути што постојат, не проверка на здравје. Кога операторот паѓа, кернелот ги отстранува рутите на тој уред и втората стандардна рута презема. Кога кабелот останува горе, а провајдерот зад него умира, во табелата ништо не се менува: преферираната рута е инсталирана, соседот е достапен на слој 2, а пакетите заминуваат во црна дупка. Ако таа разлика е важна за твоето поставување, failover-от мора да дојде од нешто што го сондира патот и ја отстранува рутата, било да е тоа рутинг демон или мал скрипт што го брише и повторно го инсталира записот.

Провери го изборот откако табелата е изградена, и провери го онака како што кернелот ќе го види. ip -6 route get 2001:db8:100::1 ја печати рутата што би се користела, вклучувајќи го уредот и избраната изворна адреса, и ги почитува правилата на политиката. Изворна адреса што припаѓа на погрешна врска е вообичаен знак дека правило одговорило порано отколку што очекуваше.

Услов три: одлучи кому му припаѓа трајноста

Рута додадена со ip -6 route add преживува до рестарт или додека нешто не ја испере. Стандардна рута научена од огласи на рутер носи животен век и рутерот може да ја повлече, додека рачно додадена стандардна рута никогаш сама не истекува. Мешањето на двете во една табела е начинот на кој застарена трајна рута завршува пред свежо огласена, долго откако врската што ја опишуваше престана да постои.

Избери еден сопственик по табела. Ако мрежен менаџер или рутинг демон веќе управува со интерфејсот, опиши ја рутата на политика таму и остави го кернелот на мир. Ако тоа го скриптираш, направи го скриптот идемпотентен и напиши го teardown-от во исто време, затоа што ќе ти треба за време на првата лоша промена:

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

На рутер што проследува за други домаќини, провери net.ipv6.conf.all.forwarding пред да ја обвиниш табелата. Со исклучено проследување, пакетите наменети за друга мрежа се отфрлаат, колку и да е точна табелата 201.

Запиши го дизајнот за следната личност да може да го ревидира

Инвентар што чува само fe80::1 ги фрла полињата што се важни. Запиши го одредиштето, следниот скок, уредот, табелата и метриката заедно, плус од каде дошла секоја рута, дали е огласена, генерирана од менаџерот или статична. Кога некој подоцна ќе праша дали втората врска навистина носи сообраќај, тој запис одговара без нагаѓање.

Пред да ја прогласиш табелата за готова, потврди го соседот со ip -6 neigh show dev uplink0, прочитај повторно ip -6 rule show поради незгоди со редоследот, и тестирај со сообраќај што одговара на правилото наместо со ping што ја зема стандардната рута. Потоа намерно спушти една врска и гледај на која рута кернелот се враќа; одговорот треба да одговара на она што си го запишал.