ICMP-uudelleenohjaukset vastaan VPN-reitityksesi: mikä oikeasti muuttuu

Vuon, jonka pitäisi kulkea tunnelin läpi, ottaa eri seuraava hyppy, ja joku löytää kaappauksesta ICMP-uudelleenohjauksen. Se on hypoteesi, ei diagnoosi. Uudelleenohjaus on reitittimen ehdotus paremmasta seuraavasta hypystä, ja se, toimiiko isäntä sen mukaan, riippuu asetuksista, jotka eroavat alustan, liitännän ja osoiteperheen mukaan.

Uudelleenohjaus on reitittimen ehdotus

IPv4:n ICMP-uudelleenohjauksilla on oma viestityyppinsä ja kapea joukko ehtoja: reititin välittää paketin ulos liitännästä, josta se saapui, ja tuntee samalla linkillä seuraavan hypyn, joka on lähempänä kohdetta. Sitten se kehottaa lähettäjää käyttämään tuota seuraavaa hyppyä suoraan. Viesti nimeää uuden yhdyskäytävän ja sisältää osan alkuperäisestä paketista, jotta lähettäjä voi sovittaa sen vuohon. Se on kohteliaisuusviesti paikallisesta topologiasta, ja se olettaa, että lähettäjä jakaa linkin ehdotetun yhdyskäytävän kanssa.

Lähettäjä voi vapaasti jättää sen huomiotta. Mikään protokollassa ei vaadi isäntää muuttamaan tauluaan, ja kaapattu uudelleenohjaus todistaa vain, että reititin lähetti sellaisen.

Juuri tässä erossa useimmat uudelleenohjausten tutkimukset menevät pieleen.

IPv4 ja IPv6 toimittavat sen eri tavoin

IPv6:ssa vastaava mekanismi on naapureiden löytämisen sisällä eikä ICMPv4:ssä, ja viestimuodot sekä validointisäännöt ovat erilaiset. Käsitteet rimmaavat, paketit eivät. ICMP-tyypille 5 kirjoitettu kaappaussuodatin ei näytä mitään IPv6-verkossa, mikä luetaan joskus todisteeksi siitä, ettei uudelleenohjausta tapahtunut.

Myös käytännön kytkimet ovat erillisiä, joten isäntä voi hyväksyä IPv4-uudelleenohjaukset ja jättää IPv6:n huomiotta tai päinvastoin.

Tarkista molemmat perheet, jos kyseinen vuo voisi käyttää kumpaa tahansa.

Hyväksyntä on isännän käytäntö, ei verkon tosiasia

Linuxissa uudelleenohjausten hyväksyntää ohjataan liitäntäkohtaisesti ja globaalisti, ja oletusarvot eroavat isännän ja reitittimen roolien välillä. Tunnelin liitäntä, joka hyväksyy uudelleenohjauksia, on outo suunnittelu, koska piste-piste-tunnelissa ei ole mielekästä vaihtoehtoista seuraavaa hyppyä samalla linkillä. Siksi asetus kannattaa lukea eikä olettaa.

Turvallisen uudelleenohjauksen asetukset rajoittavat edelleen sitä, mitä yhdyskäytäviä voi uskoa.

Jos kovennat isäntää, nämä ovat tarkistettavat kytkimet, ja ne ovat myös syy siihen, miksi kaksi konetta samassa verkossa voi käyttäytyä eri tavoin. Muuta niitä käytäntönä, älä virityksen oikotienä.

Mitä uudelleenohjaus ei voi selittää

Tietyt reitit, käytäntöperusteisen reitityksen säännöt ja paikalliset liitännät selittävät useimmat odottamattomat polut ilman mitään uudelleenohjausta. Tarkempi etuliite, lähdeosoitteeseen sopiva sääntö tai toinen oletus toisessa taulussa jokainen niistä ohittaa reitin, jota odotit. Tarkista ne ensin, koska ne ovat deterministisiä ja näkyviä.

Vanhentuneet kaappaukset ovat toinen ansa, koska verkon vaihtaneella asiakkaalla on eri paikallinen yhdyskäytävä.

Vanha uudelleenohjaus aiemmasta liitoksesta ei selitä mitään nykyisestä polusta, joten kirjaa, mikä liitäntä vastaanottaa ohjausliikennettä nyt.

Tarkista reitti ennen kuin syytät tunnelia

Kysy ytimeltä, mitä reittiä se käyttäisi kohteeseen, ja vertaa sitä sitten tauluun, jonka tarkoitit. Jos vastaus vastaa taulua, mikään uudelleenohjaus ei muuttanut mitään ja tutkimus kuuluu muualle. Jos se ei vastaa, etsi välimuistiin tallennettua uudelleenohjausta, käytäntösääntöä tai toista taulua ennen kuin oletat tunnelin olevan syyllinen. Haku on perustotuus, ja kaikki muu on tarina siitä, miten se sinne päätyi.

Uudelleenohjaus ei saisi koskaan olla syy siihen, että suojattu polku muuttuu hiljaa suojaamattomaksi, ja siksi hyväksyntäkäytäntö kuuluu suunnittelukatsaukseen. RFC 792:n määritelmä on edelleen viite siihen, mitä IPv4-viesti saa sanoa.

Kirjoita reittihaku ja kaappauksen aikaleima yhteen, niin seuraava henkilö voi toistaa päätelmäsi.