ESP расшыфроўвае нармальна, а ўнутраны пакет усё роўна нікуды не ідзе

Лічыльнік прыёму ESP павялічваецца, тунель трымаецца, а праграма ніколі не бачыць пакет. Расшыфроўка прайшла, праверка цэласнасці паспяховая, і потым атрымальніку давялося вырашаць, што ж уяўляе сабой абароненая карысная нагрузка. Менавіта на гэтым апошнім кроку і ўзнікае неадпаведнасць фармату, а збоку гэта зусім не падобна на праблему міжсеткавага экрана.

Што вы бачыце, калі этыкетка хлусіць

Нішто ў кліенцкім журнале не адрознівае гэта ад чорнай дзіркі ў маршрутызацыі. Абодва даюць тайм-аўт праграмы побач са здаровым тунелем, таму першымі вінавацяць лічыльнікі.

Растуны лічыльнік прыёму гэта сапраўды добрая навіна: пакеты прыходзяць і праходзяць аўтэнтыфікацыю. Гэта не доказ таго, што ўнутраны пакет меў сэнс для чаго-небудзь вышэй за крыптаграфічны ўзровень.

Тып жыве ў трэйлеры

У звычайным рэжыме тунеля IPsec абароненая ESP карысная нагрузка ўтрымлівае поўны ўнутраны IP-пакет. Поле наступнага загалоўка ў трэйлеры вызначае, што гэта за нагрузка, і гэта не порт TCP, не нумар пратакола ў знешнім загалоўку і не частка пачатковага поля SPI і нумара паслядоўнасці. RFC 4303 раздзел 2.6 вызначае яго як поле тыпу нагрузкі, а гэта дакладнае імя для дакладнай задачы.

Значэнні, якія вы сустрэнеце, невялікія і вартыя запомніць: IPv4 гэта 4 (0x04), а IPv6 гэта 41 (0x29).

Гэтыя лікі паходзяць з прызначэнняў нумароў пратаколаў IANA, а не з мясцовай традыцыі. Адпраўнік, які абвяшчае IPv4, але ўкладае пакет IPv6, стварыў неадпаведнасць фармату, і ніякае правіла міжсеткавага экрана не выправіць байты, што супярэчаць уласнай этыкетцы.

Як адрозніць гэта ад звычайных падазраваных

Большасць зніклых пакетаў гэта не дэфекты кадавання. Спачатку праверце селектары, бо селектар трафіку, які выключае прэфікс IPv6, адкідае трафік яшчэ да таго, як што-небудзь інкапсулюецца. Затым праверце маршрутызацыю, потым лакальную фільтрацыю на хаце-атрымальніку. Толькі пасля іх выключэння неадпаведнасць фармату нагрузкі становіцца праўдападобным тлумачэннем.

Зашыфраваны захоп не вырашыць пытанне, бо абаронены наступны загаловак знаходзіцца ўнутры зашыфраванай нагрузкі. Патрэбна дыягностыка рэалізацыі або падтрыманая кропка назірання пасля расшыфроўкі, і абодва патрабуюць дазволу перад выкарыстаннем.

Калі ніхто не можа прадставіць гэтыя доказы, у вас няма памылкі фармату. У вас ёсць тэорыя, і селектары застаюцца лепшай стаўкай.

Чым рамонт не з'яўляецца

Не адключайце праверкі цэласнасці, каб трафік праходзіў. Не перапісвайце зашыфраваныя пакеты на прамежкавым маршрутызатары, бо гэта не можа працаваць і сапсуе паток, выглядаючы карысным у захопе. Не адкрывайце шырэйшае правіла міжсеткавага экрана для праграмы на падставе тэорыі, што порт заблакаваны. Нішто з гэтага не датычыцца неадпаведнасці этыкеткі.

Калі пацверджаная неадпаведнасць паходзіць ад рэалізацыі партнёра, захавайце мінімальнае ачышчанае ўзнаўленне і перанясіце яго ў падтрыманы канал гэтай рэалізацыі.

Правярайце паток, а не лічыльнік

Пасля выпраўлення праверце фактычны паток IPv6 ад пачатку да канца: запыт праграмы праз тунель, адказ на яго і пару адрасоў, якую бачыць кожны бок. Растуны лічыльнік ESP даказвае толькі тое, што пакеты прымаюцца і аўтэнтыфікуюцца. Ён нічога не кажа пра тое, ці быў унутраны пакет прыдатны да выкарыстання.

Запішыце абодва вынікі ў тыкеце. Рух лічыльніка разам з працоўным патокам гэта выпраўленне; адзін толькі рух лічыльніка гэта менавіта тое, што было ў вас да пачатку.