Az IPv6 link-local nem működik VPN-en: miért áll meg a fe80 a linknél
A fe80:: cím csak egyetlen linken jelent valamit. Nézze meg, miért nem tudja átvinni egy irányított VPN, hogyan néz ki a hiba, és melyik címet használja helyette.
Felhozza az alagutat, pingeli a fe80::1-et az alagutat forrásinterfészként használva, és semmi sem jön vissza. Ez nem egy elfelejtett tűzfalszabály. A link-local cím csak azon az egyetlen linken jelent valamit, ahol létrejött, és egy irányított VPN nem az a link. A távoli útválasztó fe80::1 címe a távoli LAN szegmensen él; ön egy ugrásra van egy másik szegmensen, és az IPv6-nak nincs semmilyen mechanizmusa arra, hogy egy útválasztó link-local csomagokat továbbítson.
A fe80 előtag hatókört ír le, nem tartományt
A link-local unicast a fe80::/10, és a meghatározó tulajdonság nem a szám, hanem a hatókör. A cím csak egy linken érvényes, és minden interfész a saját azonosítójából alkot egyet, ezért két független gép két független hálózaton is válaszolhat a fe80::1-re a legkisebb ütközés nélkül. Az előtag lényegében azt mondja: „valamelyik linken”; maga a link a kontextusból jön.
Egy hoszton ez a kontextus a zóna, azaz a scope ID, amelyet százalékjel után fűz hozzá: fe80::1%eth0 Linuxon, fe80::1%3 vagy fe80::1%12 Windowson és az interfészindexeket kiadó eszközökben. A kernel az interfész indexével együtt oldja fel a címet, majd küld. Ha elhagyja a zónát, a cél nem egyértelmű, így a stacknek nincs módja szegmenst választani.
Miért nem tudja egy irányított alagút kézbesíteni
Az irányított VPN egy pont-pont interfész, amely saját címeket hordoz, általában az alagúton belüli unique-local vagy privát IPv6 tér egy /64-ét. A távoli LAN külön link, amelyet az alagút végpontja ér el az ön nevében végzett útválasztással és továbbítással. Ez két külön szegmens, ezért az egyikről származó cím nem érvényes cél a másikon.
A továbbítási szabály a szabványban van kimondva, nem a kliens szeszélye: az útválasztók nem továbbítanak link-local forrású vagy célú csomagokat. Ezért hal meg a csomag akkor is, amikor az útválasztási tábla helyesnek látszik. Adjon hozzá egy útvonalat a fe80::/64-hez az alagút felé, és egy szabványkövető stack vagy elutasítja, vagy elfogadja, majd eldobja az összes egyező csomagot: a cél hatóköre azt mondja, „csak ez a link”, és a kimenő interfész nem az a link.
A szomszédfelderítés ugyanazt a határt erősíti. A hosztok a link-local következő ugrásokat a link hatókörű multicastra küldött szomszédkéréssel oldják fel 255-es ugráskorláttal, így az útválasztók elutasíthatnak mindent, ami továbbításra kerül. Ennek alagúton át történő megvalósítása azt jelentené, hogy egy távoli szegmens felderítését proxiznánk, ami más kalapban viselt Layer 2 híd.
Van egy halkabb második hiba is, és azokat fogja meg, akik mégis erőltetni próbálják az útvonalat: a zóna. Bármilyen zónát ír be helyben, az az alagút interfészét nevezi meg, miközben a kívánt cím a távoli LAN interfészhez kötődik. A kettő soha nem egyezik, ezért a csomagot nem lehet a megfelelő interfészre terelni a túlsó végén.
Hogyan néz ki a hiba a gyakorlatban
Egy hatókörhiba eszközkimenete útválasztási vagy tűzfalhibának olvasható, és pontosan ezért töltenek az emberek egy délutánt a rossz rétegben.
| 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 |
A harmadik sor pazarolja a legtöbb időt, mert a kimenet nélküli ssh kliens egy figyelő szolgáltatás problémájának látszik. Ha bármilyen módon be tud jutni, nézze meg a túlsó oldalt, és erősítse meg, hogy az sshd az összes címhez vagy csak egyhez van kötve.
Olyan címet használjon, amelyet irányításra szántak
Mindahhoz, amit az alagúton át el kell érnie, használja azt a címet, amelyet a szolgáltatás erre a célra kapott: egy globális unicast címet, vagy egy unique-local címet a fc00::/7-ből, amely tartomány pontosan erre a belső esetre van fenntartva. Erősítse meg, hogy a figyelő valóban hozzá köti, és ellenőrizze a visszautat és a hoszt bármely tűzfalszabályát.
Nézze meg a távoli hosztot a találgatás helyett. Az ip -6 addr show felsorolja a létező címeket, az ss -6 -ltn pedig azt, hogy a daemon min figyel. Egy csak fe80:: címhez kötött szolgáltatás csak a saját szegmenséről érhető el, ami általában olyan alapértelmezés, amelyet senki nem választott szándékosan, és az adminisztrátor beleegyezésével módosítható.
Amikor a szolgáltatást valóban nem lehet újrakötni, vigye fel a hidat a hálózati réteg helyett az alkalmazásrétegre. Egy távoli hoszton futó relé, amely egy irányítható címen figyel, és a link-local címhez csatlakozik, minden szegmens kiterjesztése nélkül megoldja a problémát:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80Itt a zóna a helyes oldalon van, azon a hoszton, amelynek valóban van eth0 interfésze azon a linken. A kliense az fd00:1:2::10 címmel beszél, amely normálisan irányítható, és a relé helyben végzi el a link-local ugrást. Ugyanez a trükk működik egy készülék webes felületénél vagy egy régi BMC-nél, amely csak link-local címet hirdet.
Amikor a hidalás a valódi válasz, és mit kell ellenőrizni
Egyes telepítéseknek valóban szükségük van egy közös szegmensre: olyan eszköz, amely csak link-local felderítéssel beszél, olyan készülék, amely multicasttól függ, olyan labor, amely lapos LAN-t reprodukál. Ez Layer 2 probléma, és Layer 2 választ kíván, például a távoli interfészre hídalt tap eszközt vagy kifejezett hídalt módú kliens terméket. Ennek ára az alagúton átkelő broadcast és multicast forgalom, valamint a szomszédfelderítés, amelynek végponttól végpontig működnie kell.
Ne közelítse ezt úgy, hogy a fe80::/64-et hozzáadja egy irányított profilhoz. Ez a legrosszabb állapotot hozza létre: a konfiguráció késznek látszik, az útválasztási tábla mutat egy bejegyzést, és minden csomag továbbra is elvész valahol két stack között, amelyek mindketten helyesen viselkednek.
Az interfésszel ellenőrizze, ne a pinggel. Az ip -6 addr show tun0 megmondja, hogy az alagút linkje létrehozott-e saját link-local címet, az ip -6 route get fe80::1%tun0 pedig azt, hogy a kernel mit tenne valójában egy hatókörrel ellátott céllal. Amikor a kernel azt mondja, hogy a cél elérhetetlen azon az interfészen, egyetlen alagútbeállítás sem változtat ezen, és itt az ideje abbahagyni a profil szerkesztését.
Egy rövid sorrend, amely eldönti a kérdést:
- Olvassa ki a címet a távoli hoszton, és jegyezze meg, hogy fe80:: vagy irányítható előtag-e.
- Ha fe80::, kösse újra a szolgáltatást, relézzon azon a hoszton, vagy hidalja a szegmenst; ha irányítható, javítsa az útvonalat, a tűzfalat vagy a kötési címet.
- Minden újrateszteléskor ellenőrizze újra a zónát, mert a másolt parancs rendszerint a rossz interfészt tartja meg.
Források: RFC 4291, az IPv6 címzési architektúrája.