ICMP ümbersuunamised versus sinu VPN-marsruudid: mis tegelikult muutub

Voog, mis peaks tunnelit läbima, valib teistsuguse järgmise hüppe, ja keegi leiab salvestusest ICMP ümbersuunamise. See on hüpotees, mitte diagnoos. Ümbersuunamine on ruuteri ettepanek parema järgmise hüppe kohta, ja kas host selle järgi käitub, sõltub seadetest, mis erinevad platvormi, liidese ja aadressiperekonna kaupa.

Ümbersuunamine on ruuteri ettepanek

IPv4 ICMP ümbersuunamistel on oma sõnumitüüp ja kitsas tingimuste kogum: ruuter edastab paketi välja liidesest, mille kaudu see saabus, ja teab samal lingil järgmist hüpet, mis on sihtmärgile lähemal. Seejärel ütleb ta saatjale, et kasutada seda järgmist hüpet otse. Sõnum nimetab uue lüüli ja sisaldab osa algsepaketist, et saatja saaks selle vooluga siduda. See on viisakussõnum kohaliku topoloogia kohta ja eeldab, et saatja jagab linki pakutud lüüsiga.

Saatja võib selle ignoriseerida. Protokollis ei nõua miski, et host oma tabelit muudaks, ja püütud ümbersuunamine tõestab vaid seda, et ruuter saatis ühe.

Just selles eristuses läheb enamik ümbersuunamiste uurimisi valesse kohta.

IPv4 ja IPv6 edastavad seda erinevalt

IPv6-s on analoogne mehhanism naabrite avastamise sees, mitte ICMPv4-s, erinevate sõnumivormingute ja erinevate valideerimisreeglitega. Mõisted riimuvad, paketid mitte. ICMP tüübile 5 kirjutatud salvestusfilter ei näita IPv6 võrgus midagi, mida mõnikord loetakse tõendiks, et ühtegi ümbersuunamist ei toimunud.

Ka poliitikalülitid on eraldi, nii et host võib aktsepteerida IPv4 ümbersuunamisi ja ignoreerida IPv6 omi, või vastupidi.

Kontrolli mõlemat perekonda, kui kõnealune voog võiks kasutada kumbagi.

Vastuvõtt on hosti poliitika, mitte võrgu fakt

Linuxis juhitakse ümbersuunamiste vastuvõttu liidese kaupa ja globaalselt, ning vaikeväärtused erinevad hosti ja ruuteri rolli vahel. Tunneliliides, mis võtab ümbersuunamisi vastu, on imelik disain, sest punkt-punkt-tunneli sees ei ole samal lingil mõistlikku alternatiivset järgmist hüpet. See teeb seade lugemist väärt, mitte oletamist.

Turvalise ümbersuunamise seaded piiravad veelgi, milliseid lüüse võib uskuda.

Kui sa hosti karmistad, on need lülitid, mida üle vaadata, ja need on ka põhjus, miks kaks masinat samas võrgus võivad käituda erinevalt. Muuda neid poliitikana, mitte silumise lühiteena.

Mida ümbersuunamine seletada ei suuda

Konkreetsed marsruudid, poliitikapõhise marsruutimise reeglid ja kohalikud liidesed seletavad enamiku ootamatutest teedest täiesti ilma ümbersuunamiseta. Täpsem prefix, lähteaadressiga sobiv reegel või teine vaikeväärtus teises tabelis igaüks neist tühistab marsruudi, mida sa ootasid. Kontrolli neid kõigepealt, sest need on deterministlikud ja nähtavad.

Vanad salvestused on teine lõks, sest võrku vahetanud kliendil on teistsugune kohalik lüüs.

Varasemast ühendusest pärit vana ümbersuunamine ei seleta praeguse tee kohta midagi, seega pane kirja, milline liides võtab nüüd juhtimisliiklust vastu.

Kontrolli marsruuti enne, kui süüdistad tunnelit

Küsi kernelilt, millist marsruuti see sihtkoha jaoks kasutaks, ja võrdle seda siis tabeliga, mida sa kavatsesid. Kui vastus sobib tabeliga, ei muutnud ükski ümbersuunamine midagi ja uurimine kuulub mujale. Kui ei sobi, otsi vahemällu salvestatud ümbersuunamist, poliitikareeglit või teist tabelit, enne kui eeldad, et tunnel on süüdi. Otsing on alustõde, ja kõik muu on lugu sellest, kuidas see sinna jõudis.

Ümbersuunamine ei tohiks kunagi olla põhjus, miks kaitstud tee muutub vaikselt kaitsmata teeks, ja seetõttu kuulub vastuvõtupoliitika disainiülevaatesse. RFC 792 määratlus jääb referentsiks sellele, mida IPv4 sõnumil on lubatud öelda.

Kirjuta marsruudiotsing ja salvestuse ajatempel koos, ja järgmine inimene saab sinu järeldust korrata.