IPv6 linkin paikallinen osoite ei toimi VPN:n yli: miksi fe80 pysähtyy linkille
Osoite fe80:: merkitsee jotain vain yhdellä linkillä. Katso, miksi reititetty VPN ei voi kuljettaa sitä, miltä vika näyttää ja mitä osoitetta käyttää sen sijaan.
Nostetaan tunneli, pingataan fe80::1 tunnelin ollessa lähiverkkoliitäntä, eikä mitään tule takaisin. Kyse ei ole unohtamastasi palomuurisäännöstä. Linkin paikallinen osoite merkitsee jotain vain sillä yhdellä linkillä, jolla se muodostettiin, eikä reititetty VPN ole se linkki. Etäisen reitittimen fe80::1 asuu etäisellä LAN-segmentillä; istut yhden hypyn päässä toisella segmentillä, eikä IPv6:ssa ole mitään mekanismia, jolla reititin välittäisi linkin paikallisia paketteja lainkaan.
Etuliite fe80 kuvaa ulottuvuutta, ei vaihteluväliä
Linkin paikallinen unicast on fe80::/10, eikä määrittävä ominaisuus ole luku vaan ulottuvuus. Osoite on kelvollinen vain yhdellä linkillä, ja jokainen liitäntä muodostaa sellaisen omasta tunnisteestaan; siksi kaksi toisiinsa liittymätöntä konetta kahdessa toisiinsa liittymättömässä verkossa voivat molemmat vastata osoitteeseen fe80::1 ilman pienintäkään ristiriitaa. Etuliite sanoo pohjimmiltaan ”jollakin linkillä”; itse linkki tulee kontekstista.
Isännässä tämä konteksti on vyöhyke eli ulottuvuuden tunniste, jonka lisäät prosenttimerkin jälkeen: fe80::1%eth0 Linuxissa, fe80::1%3 tai fe80::1%12 Windowsissa ja työkaluissa, jotka näyttävät liitäntöjen indeksit. Ydin selvittää osoitteen yhdessä liitännän indeksin kanssa ja lähettää sitten. Jos jätät vyöhykkeen pois, kohde on monitulkintainen, joten pinolla ei ole tapaa valita segmenttiä.
Miksi reititetty tunneli ei voi toimittaa sitä
Reititetty VPN on pisteestä pisteeseen -liitäntä, joka kantaa omat osoitteensa, yleensä /64 yksilöllistä-paikallista tai yksityistä IPv6-avaruutta tunnelin sisällä. Etäinen LAN on erillinen linkki, johon päästään tunnelin päätepisteen reitittäessä ja välittäessä puolestasi. Ne ovat kaksi erillistä segmenttiä, joten toisen osoite ei ole kelvollinen kohde toisella.
Välityssääntö on standardissa nimenomaisesti, ei asiakkaasi erikoisuus: reitittimet eivät välitä paketteja, joiden lähde tai kohde on linkin paikallinen. Siksi paketti kuolee, vaikka reititystaulu näyttäisi oikealta. Lisää reitti fe80::/64:lle tunneliin, ja standardinmukainen pino joko hylkää sen tai hyväksyy sen ja pudottaa jokaisen vastaavan paketin: kohteen ulottuvuus sanoo ”vain tämä linkki”, eikä lähtevä liitäntä ole se linkki.
Naapurien löytäminen vahvistaa saman rajan. Isännät selvittävät linkin paikalliset seuraavat hypyt naapuripyynnöllä, joka lähetetään linkin laajuiseen multicastiin 255 hypyn rajoituksella, jotta reitittimet voivat hylätä kaiken välitetyn. Tämän saaminen toimimaan tunnelin yli tarkoittaisi löytämisen välitystä etäiselle segmentille, mikä on kerroksen 2 siltaaminen toisessa hatussa.
On myös hiljaisempi toinen vika, ja se kompastuttaa ne, jotka yrittävät pakottaa reitin joka tapauksessa: vyöhyke. Minkä tahansa vyöhykkeen kirjoitat paikallisesti, se nimeää tunnelin liitännän, kun taas haluamasi osoite on sidottu etäisen LANin liitäntään. Ne kaksi eivät koskaan täsmää, joten pakettia ei voi ohjata oikealle liitännälle kaukopäässä.
Miltä vika näyttää käytännössä
Työkalujen tuloste ulottuvuusvirheestä luetaan reititys- tai palomuurivirheeksi, ja juuri siksi ihmiset viettävät iltapäivän väärässä kerroksessa.
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
Kolmas rivi tuhlaa eniten aikaa, koska tulosteeton ssh-asiakas näyttää kuuntelevan palvelun ongelmalta. Jos sinulla on mitään sisäänpääsyä, katso kaukopuolta ja varmista, onko sshd sidottu kaikkiin osoitteisiin vai vain yhteen.
Käytä osoitetta, joka oli tarkoitettu reititettäväksi
Käytä kaikkeen, johon täytyy päästä tunnelin kautta, osoitetta, joka palvelulle annettiin juuri tähän tarkoitukseen: maailmanlaajuinen unicast-osoite tai yksilöllinen-paikallinen osoite avaruudesta fc00::/7, täsmälleen tätä sisäistä tapausta varten varattu alue. Varmista, että kuuntelija todella sitoo sen, ja tarkista paluureitti ja isännän palomuurisäännöt.
Katso etäistä isäntää sen sijaan että arvaisit. ip -6 addr show luettelee olemassa olevat osoitteet ja ss -6 -ltn sen, mitä taustapalvelu kuuntelee. Vain fe80:: osoitteeseen sidottu palvelu on tavoitettavissa vain omalta segmentiltään, mikä on yleensä oletusasetus, jota kukaan ei valinnut tahallaan ja joka voidaan muuttaa ylläpitäjän suostumuksella.
Kun palvelua ei todella voi sitoa uudelleen, nosta silta sovelluskerrokselle verkkokerroksen sijaan. Etäisellä isännällä oleva välittäjä, joka kuuntelee reititettävää osoitetta ja yhdistää linkin paikalliseen osoitteeseen, ratkaisee ongelman laajentamatta yhtään segmenttiä:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80Tässä vyöhyke on oikealla puolella, isännässä, jolla todella on eth0 sillä linkillä. Asiakkaasi puhuu osoitteelle fd00:1:2::10, joka reitittyy normaalisti, ja välittäjä tekee linkin paikallisen hypyn paikallisesti. Sama temppu toimii laitteen verkkokäyttöliittymälle tai vanhalle BMC:lle, joka mainostaa vain linkin paikallista osoitetta.
Milloin siltaaminen on todella vastaus, ja mitä tarkistaa
Jotkin käyttöönotot tarvitsevat todella yhden yhteisen segmentin: laite, joka puhuu vain linkin paikallista löytämistä, laite, joka riippuu multicastista, laboratorio, joka toistaa litteän LANin. Se on kerroksen 2 ongelma ja vaatii kerroksen 2 vastauksen, kuten etäiselle liitännälle sillattu tap-laite tai asiakastuote, jossa on nimenomainen siltatila. Se maksaa sinulle tunnelin yli kulkevan broadcast- ja multicast-liikenteen sekä naapurien löytämisen, jonka on toimittava päästä päähän.
Älä yritä lähentää sitä lisäämällä fe80::/64 reititettyyn profiiliin. Se tuottaa kaikkein huonoimman tilan: kokoonpano näyttää valmiilta, reititystaulu näyttää merkinnän, ja jokainen paketti hylätään silti jossain kahden pinon välissä, jotka molemmat käyttäytyvät oikein.
Tarkista liitännällä, älä pingillä. ip -6 addr show tun0 kertoo, muodostiko tunnelin linkki oman linkin paikallisen osoitteensa, ja ip -6 route get fe80::1%tun0 kertoo, mitä ydin todella tekisi ulottuvuudelliselle kohteelle. Kun ydin sanoo, että kohde on tavoittamaton kyseisellä liitännällä, mikään tunneliasetus ei muuta sitä, ja on aika lopettaa profiilin muokkaaminen.
Lyhyt järjestys, joka ratkaisee kysymyksen:
- Lue osoite etäiseltä isännältä ja pane merkille, onko se fe80:: vai reititettävä etuliite.
- Jos se on fe80::, sido palvelu uudelleen, välitä kyseisellä isännällä tai siltaa segmentti; jos se on reititettävä, korjaa reitti, palomuuri tai sidontaosoite.
- Tarkista vyöhyke joka kerta uudelleen testatessasi, koska kopioitu komento säilyttää yleensä väärän liitännän.
Lähteet: RFC 4291, IPv6-osoitearkkitehtuuri.