IPv6 link-local не ради преко VPN-а: зашто се fe80 зауставља на вези

Подигнете тунел, пингујете fe80::1 са тунелом као изворним интерфејсом и ништа се не враћа. То није firewall правило које сте заборавили. Link-local адреса има значење само на тој једној вези где је настала, а рутирани VPN није та веза. fe80::1 удаљеног рутера живи на удаљеном LAN сегменту; ви седите један скок даље на другом сегменту, а IPv6 уопште нема механизам којим би рутер прослеђивао link-local пакете.

Префикс fe80 описује опсег, а не распон

Link-local unicast је fe80::/10, а дефинишуће својство није број него опсег. Адреса важи само на једној вези, и сваки интерфејс формира једну из сопственог идентификатора, зато две неповезане машине на две неповезане мреже могу обе да одговоре на fe80::1 без најмањег сукоба. Префикс у суштини каже „на некој вези“; сама веза долази из контекста.

На хосту тај контекст је зона, или scope ID, коју додајете после знака процента: fe80::1%eth0 на Linux-у, fe80::1%3 или fe80::1%12 на Windows-у и у алатима који приказују индексе интерфејса. Језгро разрешава адресу заједно са индексом интерфејса и затим шаље. Ако уклоните зону, одредиште је двосмислено, па стек нема начин да изабере сегмент.

Зашто рутирани тунел не може да је достави

Рутирани VPN је тачка-до-тачке интерфејс који носи сопствене адресе, обично /64 unique-local или приватног IPv6 простора унутар тунела. Удаљени LAN је одвојена веза, до које се долази тако што крај тунела рутира и прослеђује у ваше име. То су два различита сегмента, па адреса из једног није важеће одредиште на другом.

Правило прослеђивања је изричито у стандарду, а не хировитост вашег клијента: рутери не прослеђују пакете са link-local извором или одредиштем. Зато пакет умире и када табела рутирања изгледа исправно. Додајте руту за fe80::/64 ка тунелу и стек у складу са стандардом ће је или одбити или прихватити и одбацити сваки одговарајући пакет: опсег одредишта каже „само ова веза“, а излазни интерфејс није та веза.

Откривање суседа учвршћује исту границу. Хостови разрешавају link-local следеће скокове захтевом за суседа који се шаље на multicast са опсегом везе и ограничењем скока 255, па рутери могу да одбију све што се проследи. Учинити то да ради преко тунела значило би да се проксира откривање за удаљени сегмент, што је Layer 2 премошћавање у другој капи.

Постоји тиши други квар, и он хвата људе који ипак покушавају да наметну руту: зона. Коју год зону упишете локално, она именује интерфејс тунела, док је адреса која вам треба везана за интерфејс удаљеног LAN-а. Њих две се никада не поклапају, па пакет не може да се усмери на прави интерфејс на удаљеном крају.

Како квар изгледа у пракси

Излаз алата за грешку опсега чита се као грешка рутирања или firewall-а, и управо зато људи проведу поподне у погрешном слоју.

Трећи ред троши највише времена, јер ssh клијент без излаза изгледа као проблем услуге која слуша. Ако имате било какав начин да уђете, проверите удаљену страну и потврдите да ли је sshd везан за све адресе или само за једну.

Користите адресу која је била намењена рутирању

За све до чега треба да стигнете кроз тунел, користите адресу коју је услуга добила управо за ту сврху: глобалну unicast адресу, или unique-local адресу из fc00::/7, опсег резервисан управо за овај унутрашњи случај. Потврдите да је слушалац заиста везује, и проверите повратни пут и свако firewall правило хоста.

Погледајте удаљени хост уместо да нагађате. ip -6 addr show наводи адресе које постоје, а ss -6 -ltn наводи на чему демон слуша. Услуга везана само за fe80:: доступна је само из сопственог сегмента, што је обично подразумевана вредност коју нико није намерно изабрао и која може да се промени уз сагласност администратора.

Када услуга заиста не може поново да се веже, преместите мост на апликациони слој уместо на мрежни. Реле на удаљеном хосту који слуша на рутирајућој адреси и повезује се са link-local решава проблем без проширења било ког сегмента:

socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80

Овде зона седи на исправној страни, на хосту који заиста има eth0 на тој вези. Ваш клијент разговара са fd00:1:2::10, која се нормално рутира, а реле обавља link-local скок локално. Исти трик ради за веб UI уређаја или стари BMC који оглашава само link-local адресу.

Када је премошћавање заиста одговор, и шта проверити

Неке поставке заиста траже један заједнички сегмент: уређај који говори само link-local откривање, апарат који зависи од multicast-а, лабораторија која репродукује раван LAN. То је Layer 2 проблем и тражи Layer 2 одговор, као tap уређај премошћен на удаљени интерфејс или клијентски производ са изричитим премошћеним режимом. То вас кошта broadcast и multicast саобраћаја који прелази тунел плус откривања суседа које мора да ради од краја до краја.

Не приближавајте се овоме додавањем fe80::/64 у рутирани профил. То ствара најгоре стање: конфигурација изгледа завршено, табела рутирања показује унос, а сваки пакет се и даље одбацује негде између два стека који се оба понашају исправно.

Проверите интерфејсом, а не ping-ом. ip -6 addr show tun0 каже да ли је веза тунела формирала сопствену link-local адресу, а ip -6 route get fe80::1%tun0 каже шта би језгро заиста урадило са одредиштем које има опсег. Када језгро каже да је одредиште недоступно на том интерфејсу, ниједна поставка тунела то неће променити, и време је да престанете да уређујете профил.

Кратак редослед који решава питање:

• Прочитајте адресу на удаљеном хосту и приметите да ли је fe80:: или префикс који може да се рутира.
• Ако је fe80::, поново вежите услугу, направите реле на том хосту или премостите сегмент; ако је рутирајућа, поправите руту, firewall или адресу везивања.
• Проверите зону сваки пут када поново тестирате, јер копирана команда обично задржи погрешан интерфејс.

Извори: RFC 4291, IPv6 архитектура адресирања.