Egy folyam, amelynek az alagúton kellene átmennie, más következő ugrást választ, és valaki ICMP-átirányítást talál egy rögzítésben. Ez hipotézis, nem diagnózis. Az átirányítás a router javaslata egy jobb következő ugrásról, és hogy a gazdagép aszerint cselekszik-e, olyan beállításoktól függ, amelyek platform, interfész és címcsalád szerint eltérnek.

Az átirányítás a router javaslata

Az IPv4-es ICMP-átirányításoknak saját üzenettípusuk és szűk feltételrendszerük van: a router továbbítja a csomagot azon az interfészen, amelyen érkezett, és ismer egy következő ugrást ugyanazon a linken, amely közelebb van a célhoz. Utána azt mondja a küldőnek, hogy közvetlenül ezt a következő ugrást használja. Az üzenet megnevezi az új átjárót, és tartalmazza az eredeti csomag egy részét, hogy a küldő hozzá tudja párosítani egy folyamhoz. Ez illemüzenet a helyi topológiáról, és feltételezi, hogy a küldő osztozik a linken a javasolt átjáróval.

A küldő szabadon figyelmen kívül hagyhatja. A protokollban semmi nem írja elő, hogy a gazdagép módosítsa a tábláját, és egy rögzített átirányítás csak azt bizonyítja, hogy egy router küldött egyet.

Ebben a megkülönböztetésben megy félre a legtöbb átirányítás-vizsgálat.

Az IPv4 és az IPv6 máshogy szállítja

Az IPv6-ban hasonló mechanizmus a szomszéd-felfedezésen belül található, nem az ICMPv4-ben, más üzenetformátumokkal és más ellenőrzési szabályokkal. A fogalmak rímelnek, a csomagok nem. Az ICMP 5-ös típusára írt rögzítésszűrő semmit nem mutat IPv6-hálózaton, amit néha annak bizonyítékeként olvasnak, hogy nem történt átirányítás.

A szabályzatkapcsolók is külön vannak, így a gazdagép elfogadhatja az IPv4-es átirányításokat és figyelmen kívül hagyhatja az IPv6-osokat, vagy fordítva.

Ellenőrizze mindkét családot, ha a szóban forgó folyam bármelyiket használhatja.

Az elfogadás gazdagép-szabályzat, nem hálózati tény

Linuxon az átirányítások elfogadását interfészenként és globálisan szabályozzák, és az alapértékek eltérnek a gazdagép és a router szerepe között. Az átirányításokat elfogadó alagút-interfész furcsa tervezés, mert egy pont-pont alagúton belül nincs értelmes alternatív következő ugrás ugyanazon a linken. Ezért érdemes elolvasni ezt a beállítást, nem feltételezni.

A biztonságos átirányítás beállításai tovább korlátozzák, mely átjáróknak lehet hinni.

Ha egy gazdagépet szigorít, ezek az áttekintendő kapcsolók, és ez az oka annak is, hogy két gép ugyanazon a hálózaton eltérően viselkedhet. Szabályzatként módosítsa őket, nem hibakeresési rövidítésként.

Mit nem tud megmagyarázni az átirányítás

A konkrét útivonalak, a szabályzatalapú útiválasztás szabályai és a helyi interfészek a legtöbb váratlan útivonalat minden átirányítás nélkül megmagyarázzák. Egy konkrétabb előtag, a forráscímhez illeszkedő szabály, vagy egy második alapértelmezett egy másik táblában mindegyik felülírja a várt útivonalat. Először ezeket ellenőrizze, mert determinisztikusak és láthatók.

Az elavult rögzítések a másik csapda, mert a hálózatot váltó kliens helyi átjárója más.

Egy korábbi kapcsolat régi átirányítása semmit nem magyaráz a jelenlegi útivonalról, ezért jegyezze fel, melyik interfész fogadja most a vezérlőforgalmat.

Ellenőrizze az útivonalat, mielőtt az alagutat hibáztatja

Kérdezze meg a kernelt, melyik útivonalat használná a célhoz, majd hasonlítsa össze a szándékolt táblával. Ha a válasz megegyezik a táblával, egyetlen átirányítás sem változtatott semmit, és a vizsgálat máshova tartozik. Ha nem egyezik, keressen gyorsítótárazott átirányítást, szabályzati szabályt vagy második táblát, mielőtt feltételezné, hogy az alagút a hibás. A keresés a talapzatigazság, és minden más történet arról, hogyan került oda.

Az átirányítás soha nem lehet az oka annak, hogy egy védett útivonal csendesen védtelenné válik, és ezért tartozik az elfogadási szabályzat a tervezési felülvizsgálathoz. Az RFC 792 definíciója továbbra is az a hivatkozás, hogy mit mondhat az IPv4-üzenet.

Írja le az útivonalkeresést és a rögzítés időbélyegét együtt, és a következő ember reprodukálhatja a következtetését.

Kapcsolódó cikkek