ESP purkaa salauksen kunnolla, ja sisempi paketti ei silti päädy mihinkään

ESP:n vastaanottolaskuri kasvaa, tunneli pysyy pystyssä eikä sovellus näe pakettia koskaan. Salauksen purku tapahtui, eheystarkistus meni läpi, ja sitten vastaanottajan oli päätettävä, mikä suojattu hyötykuorma oikeastaan on. Juuri siinä viimeisessä vaiheessa muotoyhteensopimattomuus ilmenee, eikä se ulospäin näytä lainkaan palomuuriongelmalta.

Mitä näet, kun tarra valehtelee

Mikään asiakkaan lokissa ei erota tätä reitityksen mustasta aukosta. Molemmat tuottavat sovelluksen aikakatkaisun terveen tunnelin rinnalle, minkä vuoksi laskureita syytetään ensin.

Nouseva vastaanottolaskuri on todella hyvä uutinen: paketit saapuvat ja todennetaan. Se ei ole todiste siitä, että sisempi paketti olisi ollut mielekäs jollekin salauskerroksen yläpuolella.

Tyyppi asuu trailerissa

Tavallisessa IPsec-tunnelitilassa ESP:n suojaama hyötykuorma sisältää täydellisen sisemmän IP-paketin. Trailerin seuraavan otsakkeen kenttä kertoo, mikä tämä hyötykuorma on, eikä se ole TCP-portti, ei ulomman otsakkeen protokollanumero eikä osa alkuperäistä SPI- ja järjestysnumerokenttää. RFC 4303 luku 2.6 määrittelee sen hyötykuorman tyyppikentäksi, mikä on täsmällinen nimi täsmälliselle tehtävälle.

Vastaan tulevat arvot ovat pieniä ja kannattaa painaa mieleen: IPv4 on 4 (0x04) ja IPv6 on 41 (0x29).

Nämä luvut tulevat IANAn protokollanumeroiden jaosta eivätkä paikallisesta käytännöstä. Lähettäjä, joka ilmoittaa IPv4:n mutta käärii sisäänsä IPv6-paketin, on tuottanut muotoristiriidan, eikä mikään palomuurisääntö korjaa tavuja, jotka ovat ristiriidassa oman tarran kanssa.

Miten erottaa se tavallisista epäillyistä

Useimmat puuttuvat paketit eivät ole koodausvirheitä. Tarkista ensin valitsimet, koska liikennevalitsin, joka sulkee pois IPv6-etuliitteen, pudottaa liikenteen ennen kuin mitään kääritään. Tarkista sitten reititys ja sen jälkeen paikallinen suodatus vastaanottavalla isännällä. Vasta kun ne on suljettu pois, hyötykuorman muotoyhteensopimattomuudesta tulee uskottava selitys.

Salattu kaappaus ei ratkaise asiaa, koska suojattu seuraava otsake on salatun hyötykuorman sisällä. Tarvitset toteutuksen diagnostiikkaa tai tuetun salauksenpurkuhavainnointipisteen, ja molemmat vaativat luvan ennen käyttöä.

Jos kukaan ei pysty tuottamaan sitä todistetta, sinulla ei ole muotovikaa. Sinulla on teoria, ja valitsimet ovat edelleen parempi veto.

Mikä korjaus ei ole

Älä poista eheystarkistuksia käytöstä, jotta liikenne menisi läpi. Älä kirjoita salattuja paketteja uudelleen välireitittimellä, koska se ei voi toimia ja turmelee virran samalla kun se näyttää kaappauksessa hyödylliseltä. Älä avaa sovelluksen palomuurisääntöä leveämmäksi sillä teorialla, että portti on estetty. Mikään noista ei kosketa tarran ristiriitaa.

Jos vahvistettu ristiriita tulee vertaistoteutuksesta, säilytä minimaalinen puhdistettu toisinto ja vie se kyseisen toteutuksen tuettuun kanavaan.

Varmista virta, älä laskuria

Korjauksen jälkeen testaa todellinen IPv6-virta päästä päähän: sovelluksen pyyntö tunnelin läpi, sen vastaus ja osoitepari, jonka kumpikin puoli havaitsee. Nouseva ESP-laskuri todistaa vain, että paketteja vastaanotetaan ja todennetaan. Se ei kerro mitään siitä, oliko sisempi paketti käyttökelpoinen.

Kirjaa molemmat tulokset tikettiin. Laskurin liike ja toimiva virta on korjaus; pelkkä laskurin liike on täsmälleen se, mitä sinulla oli ennen aloittamista.