ESP dekrüpteerib korralikult ja sisemine pakett ei jõua ikkagi kuhugi
ESP loendurid kasvavad, samal ajal kui rakendus ei näe midagi. Traileri järgmine päis peab vastama sisemisele paketile, mis on teistsugune viga kui selektori möödalask.
ESP vastuvõtuloendur kasvab, tunnel püsib püsti ja rakendus ei näe paketti kunagi. Dekrüpteerimine toimus, terviklikkuse kontroll läbis ja seejärel pidi vastuvõtja otsustama, mis kaitstud kasulik koormus tegelikult on. Just sellel viimasel sammul ilmneb vormingu lahknevus ja väljastpoolt ei näe see üldse tulemüüri probleemina välja.
Mida sa näed, kui silt valetab
Midagi kliendi logis ei erista seda marsruutimise mustast august. Mõlemad tekitavad tervisliku tunneli kõrval rakenduse ajalõpu, mistõttu süüdistatakse kõigepealt loendureid.
Kasvav vastuvõtuloendur on tõesti hea uudis: paketid saabuvad ja autenditakse. See ei ole tõestus, et sisemine pakett oli krüptokihist kõrgemal asuvale millelegi mõistlik.
Tüüp elab traileris
Tavalises IPsec tunnelirežiimis sisaldab ESP-ga kaitstud kasulik koormus tervet sisemist IP paketti. Traileri järgmise päise väli määrab, mis see koormus on, ning see ei ole TCP port, mitte välise päise protokollinumber ega algse SPI ja järjekorranumbri välja osa. RFC 4303 jaotis 2.6 määratleb selle koormuse tüübi väljana, mis on täpne nimi täpse töö jaoks.
Väärtused, mida kohtad, on väikesed ja neid tasub meeles pidada: IPv4 on 4 (0x04) ja IPv6 on 41 (0x29).
Need numbrid pärinevad IANA protokollinumbrite määramistest, mitte kohalikust tavast. Saatja, kes deklareerib IPv4, samal ajal kui pakendab IPv6 paketti, on tekitanud vormingu vastuolu, ja ükski tulemüüri reegel ei paranda baite, mis on vastuolus nende enda sildiga.
Kuidas eristada seda tavalistest kahtlusalustest
Enamik kadunud pakette ei ole kodeerimisvead. Kontrolli esmalt selektoreid, sest liiklusselektor, mis jätab IPv6 prefiksi välja, viskab liikluse kõrvale enne, kui midagi kapseldatakse. Seejärel kontrolli marsruutimist ja siis kohalikku filtreerimist vastuvõtvas hostis. Alles pärast nende välistamist muutub koormuse vormingu lahknevus usutavaks seletuseks.
Krüpteeritud püüdmine ei otsusta seda, sest kaitstud järgmine päis asub krüpteeritud koormuse sees. Sul on vaja rakenduse diagnostikat või toetatud dekrüpteeritud vaatluspunkti ja mõlemad nõuavad enne kasutamist luba.
Kui keegi ei suuda seda tõendit esitada, ei ole sul vormingu viga. Sul on teooria ja selektorid jäävad paremaks panuseks.
Milleks parandus ei ole
Ära lülita terviklikkuse kontrolle välja, et liiklus läbi läheks. Ära kirjuta krüpteeritud pakette vahepealses ruuteris ümber, sest see ei saa toimida ja rikub voo, samal ajal kui see püüdmises kasulikuna paistab. Ära ava laiemat rakenduse tulemüüri reeglit teooria põhjal, et port on blokeeritud. Miski neist ei puuduta sildi lahknevust.
Kui kinnitatud lahknevus pärineb partnerrakendusest, hoia alles minimaalne puhastatud reproduktsioon ja vii see selle rakenduse toetatud kanalisse.
Kontrolli voogu, mitte loendurit
Pärast parandust testi tegelikku IPv6 voogu otsast otsani: rakenduse päring läbi tunneli, selle vastus ja aadressipaar, mida kumbki pool näeb. Kasvav ESP loendur tõestab ainult seda, et pakette võetakse vastu ja autenditakse. See ei ütle midagi selle kohta, kas sisemine pakett oli kasutatav.
Kirjuta mõlemad tulemused piletisse. Loenduri liikumine koos toimiva vooga on parandus; ainult loenduri liikumine on täpselt see, mis sul enne alustamist oli.