169.254 VPN-en át: a cím soha nem volt útvonalazható
A link-local cél már a tunel elérése előtt eldobódik, így az útvonalak hozzáadása csak szélesíti a hibát. Válasszon az alhálózat javítása és a híd között.
Hozzáadja az útvonalat, a tunel feljön, és a túloldali ping mégis teljes veszteséggel hal meg, nem «network unreachable» hibával. Ez a különbség számít, mert az útvonaltáblától maga a cím felé tereli a figyelmet. A 169.254-es cél link-local, hatóköre pedig tervezés szerint az első ugrásnál véget ér, nem hibás konfiguráció miatt.
A következő döntés szűk, és érdemes kimondani: javítsa a kiszolgáló oldali alhálózatot, vagy terjessze ki a 2. réteg szegmensét, hogy a cím ismét helyi értelmet kapjon. Minden más, még egy szélesebb útvonal is, csak ugyanazt a hibát terjeszti ki több célra.
A cím nem útvonal nélküli, hanem nem útvonalazható
Az IPv4 link-local címek magukat osztják ki, amikor semmi jobb nem válaszol; innen ered a Windows automatikus privát címzése és a többi rendszer megfelelő tartaléka. A tartomány minden kapcsolaton egyszerre van használatban, és éppen ezért működik: két gazdagép ugyanabban a szegmensben bármilyen egyeztetés nélkül beszélhet.
Ugyanezen tulajdonság miatt a forgalomirányító nem továbbíthatja ezeket a csomagokat hálózatok között. Ha egy link-local célra címzett csomagot fogadna, és egy másik interfészen küldené ki, kétértelműség keletkezne, mert a küldő «helyi» és a fogadó «helyi» különböző helyek. Nincs olyan keresés, amely eldöntené, melyikre gondolt a küldő. A továbbítás itt nem olyan házirend-választás, amelyet a rendszergazda bekapcsolhat; a címosztály kizárja.
Így az az átjáró, amely a 169.254.1.10 címet a tunelen át elérhetőként telepíti, olyasmit kér a kerneltől, amit a cím formátuma tilt. A csomag jóval azelőtt eldobódik, hogy elérné a távoli gazdagépet, és az útvonal pontossága ezen nem változtat.
Miért teszi láthatóvá a tunel a hatókör problémáját
A TUN interfész IP-csomagokat visz két fél között, és mögötte nincs közös szegmens. Nincs szórás, nincs ARP a túloldal felé, és nincs szomszéd-felfedezés, amely egy link-local célt kapcsolati rétegbeli címmé oldana.
A tünetek pontosan összeillenek, ha tudja, mit keressen. Az útvonal ott van a táblában, a ping teljes veszteséget jelez elérhetetlen hálózat helyett, a szomszédtábla pedig hiányos vagy sikertelen bejegyzést mutat. A tunelen készült felvétel a csomag távozását mutatja, ami a távoli vég felé tereli a figyelmet a címosztály helyett.
Windows alatt van egy második, látszólag független tünet ugyanazzal a gyökérrel: az adapter, amelyen csak link-local cím maradt, nem kap használható átjárót, így a hálózatfelismerés nem tudja besorolni a kapcsolatot, és a tűzfalprofil nyilvánosra esik. Nem a tunel az ok; a cím az.
Döntsön három kérdéssel
Az alhálózat javítása és a kapcsolat áthidalása közötti választás három feltételtől függ, és bármelyik eldöntheti még a konfigurációs fájl megnyitása előtt.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
A legtöbb eset az első kérdésnél megáll. A link-local címet mutató gazdagép általában azt jelenti, hogy a DHCP nem válaszolt, a kábel vagy a VLAN rossz, vagy valaki kézzel írta be a címet. Ennek javítása olcsóbb minden tunelmunkánál, és minden jövőbeli ügyfélnél megszünteti a problémát, nem csak ennél.
Ellenőrizze a kiszolgáló oldalát, mielőtt bármit feltételez. Futtassa a ip addr show és ip route parancsot a gazdagépen, a arp -n vagy route print -4 parancsot az ügyfélen, hogy lássa, létezik-e az előtag, vagy csak egy régi bejegyzés állítja.
Mit ér egy híd, amikor ez a helyes válasz
A fizikai adapter áthidalása TAP-adapterrel a távoli ügyfelet a helyi szórási tartomány részévé teszi. Ekkor a szórás és a szomszéd-felfedezés működik, és a link-local cím ismét értelmet kap, mert az ügyfél valóban helyi azon a kapcsolaton.
A költségek valósak, és meg kell mondani őket, mielőtt bárki elfogadja. A szórási forgalom átlépi a tunelt, az ügyfél minden célra ki van téve a helyi szegmensnek, nem csak a szükséges szolgáltatásoknak, a kiszolgálónak pedig most kereteket kell továbbítania csomagok útvonalazása helyett. Ez ésszerű csere laboratóriumi padhoz vagy útvonalazható konfigurációs úttal nem rendelkező eszközhöz, távoli hozzáféréshez viszont rossz alapértelmezés.
Áthidaláskor mindkét félre szükség van: a hídra a kiszolgálón, és egy útvonalra az ügyfélprofilban, amely megmondja, mely célok vannak a túloldalon. A híd önmagában találgatásra kényszeríti az ügyfelet, az útvonal önmagában pedig nem javít egy címosztályt.