ESP pravilno dešifrira, notranji paket pa vseeno ne pride nikamor

Števec prejema ESP narašča, tunel ostane pokonci, aplikacija pa paketa nikoli ne vidi. Dešifriranje je potekalo, preverjanje celovitosti je uspelo, nato pa se je moral prejemnik odločiti, kaj zaščitena koristna obremenitev pravzaprav je. Prav v tem zadnjem koraku se pokaže neujemanje oblike, in od zunaj to sploh ni podobno težavi požarnega zidu.

Kaj vidite, ko oznaka laže

Nič v dnevniku odjemalca tega ne loči od črne luknje v usmerjanju. Oboje ustvari časovno prekoračitev aplikacije ob zdravem tunelu, zato so najprej obdolženi števci.

Naraščajoči števec prejema je res dobra novica: paketi prihajajo in se overjajo. To ni dokaz, da je bil notranji paket smiseln za kar koli nad kriptografsko plastjo.

Vrsta prebiva v trailerju

V običajnem tunelskem načinu IPsec zaščitena obremenitev ESP vsebuje celoten notranji paket IP. Polje naslednje glave v trailerju določa, kaj je ta obremenitev, in to ni vrata TCP, ni številka protokola v zunanji glavi in ni del začetnega polja SPI ter zaporedne številke. RFC 4303 razdelek 2.6 ga opredeli kot polje vrste obremenitve, kar je natančno ime za natančno delo.

Vrednosti, ki jih boste srečali, so majhne in vredne zapomnitve: IPv4 je 4 (0x04), IPv6 pa 41 (0x29).

Te številke izhajajo iz dodelitev številk protokolov IANA in ne iz krajevnega dogovora. Pošiljatelj, ki razglasi IPv4, hkrati pa ovije paket IPv6, je ustvaril neujemanje oblike, in nobeno pravilo požarnega zidu ne popravi bajtov, ki nasprotujejo lastni oznaki.

Kako ga ločiti od običajnih osumljencev

Večina manjkajočih paketov niso napake pri kodiranju. Najprej preverite selektorje, ker selektor prometa, ki izloči predpono IPv6, zavrže promet, preden se karkoli enkapsulira. Nato preverite usmerjanje in zatem krajevno filtriranje na prejemnem gostitelju. Šele ko je to izločeno, neujemanje oblike obremenitve postane verjetna razlaga.

Šifriran posnetek tega ne bo razrešil, ker zaščitena naslednja glava sedi znotraj šifrirane obremenitve. Potrebujete diagnostiko izvedbe ali podprto dešifrirano opazovalno točko, oboje pa zahteva dovoljenje pred uporabo.

Če nihče ne more predložiti tega dokaza, nimate napake oblike. Imate teorijo, selektorji pa ostajajo boljša stava.

Česa popravek ni

Ne izklapljajte preverjanj celovitosti, da bi promet šel skozi. Ne prepisujte šifriranih paketov na vmesnem usmerjevalniku, ker to ne more delovati in bo pokvarilo tok, medtem ko je na posnetku videti koristno. Ne odpirajte širšega pravila požarnega zidu za aplikacijo na podlagi teorije, da je vrata blokirana. Nič od tega se ne dotakne neujemanja oznake.

Če potrjeno neujemanje izvira iz partnerske izvedbe, ohranite najmanjšo očiščeno reprodukcijo in jo odnesite v podprti kanal te izvedbe.

Preverite tok, ne števca

Po popravku preizkusite dejanski tok IPv6 od začetka do konca: zahtevo aplikacije skozi tunel, njen odgovor in par naslovov, ki ga vsaka stran opazuje. Naraščajoči števec ESP dokazuje le, da se paketi prejemajo in overjajo. Ne pove ničesar o tem, ali je bil notranji paket uporaben.

Zapišite oba izida v zahtevek. Gibanje števca skupaj z delujočim tokom je popravek; samo gibanje števca je natanko to, kar ste imeli pred začetkom.