IPsec ESP: што ён пераносіць і як даказаць, што трафік ідзе
ESP у рэжыме тунеля ахінае ўнутраны IP-пакет і вызначае сваю асацыяцыю праз SPI. Прачытайце стан, затым паглядзіце, як адзін паток рухае лічыльнікі.
ESP пераносіць трафік у VPN на базе IPsec, і яго runbook пачынаецца з аднаго правіла: прачытайце асацыяцыю бяспекі, перш чым змяняць палітыку. Большасць незразумелых паводзін ESP зводзіцца да селектара, які не супаў, рэжыму, які меркавалі, а не чыталі, або лічыльніка, які ніхто не праверыў, пакуль ішоў адзін паток. Тры крокі ніжэй устанаўліваюць, што што пераносіць, даказваюць, што адзін паток выкарыстоўвае гэта, і пакідаюць адкат, які не залежыць ад памяці. Кожны крок дае адно назіранне, якое варта запісаць.
Ведайце палі перад тым, як іх чытаць
ESP ставіць загаловак перад абароненымі данымі і трэйлер пасля іх. Загаловак нясе індэкс параметраў бяспекі, які вызначае, якую асацыяцыю павінен выкарыстоўваць атрымальнік, нумар паслядоўнасці для выяўлення паўтору і запаўненне ў трэйлеры, якое трымае карысную нагрузку выраўнаванай для шыфра. Поле наступнага загалоўка ў трэйлеры паказвае, што ўяўляе сабой абаронены змест, і менавіта так атрымальнік даведваецца, што ён дэкапсуляваў.
Рэжым змяняе тое, што знаходзіцца ўнутры гэтай абароны. У рэжыме тунеля абаронены матэрыял — гэта поўны ўнутраны IP-пакет, і новы знешні загаловак пераносіць яго паміж канцавымі пунктамі. У транспартным рэжыме абарона ахінае нагрузку верхняга ўзроўню існуючага пакета, таму другога IP-загалоўка для распакавання няма. Які рэжым выкарыстоўваецца — гэта факт канфігурацыі, а не пытанне інтэрпрэтацыі. Чытайце яго з запісу стану, а не выводзьце з дыяграмы.
Ні адзін рэжым не хавае знешнюю адрасацыю, якая павінна даставіць пакет. Гэта ўласцівасць дызайну, а не недахоп, і менавіта таму прамежкавы назіральнік усё яшчэ бачыць, якія два адрасы размаўляюць, нават калі карысная нагрузка непразрыстая.
Крок першы: прачытайце стан, затым палітыку
Запісы стану захоўваюць ключы і лічыльнікі; запісы палітыкі захоўваюць селектары, якія вырашаюць, што можа імі карыстацца. У Linux абодва бачныя без перахопу пакетаў, і чытанне іх у гэтым парадку трымае два пытанні асобна.
ip xfrm state
ip xfrm policyУ вывадзе стану праверце крыніцу і прызначэнне асацыяцыі, рэжым і тое, ці паказвае інкапсуляцыя порты UDP. Гэтыя порты азначаюць, што выкарыстоўваецца праход праз NAT, што змяняе тое, што павінен дазваляць прамежкавы файрвол, але не тое, якія селектары ці ключы дзейнічаюць на канцавых пунктах.
Затым прачытайце селектары ў палітыцы. Селектар, які называе вузейшы прэфікс, чым трафік, які вы тэстуеце, — самая частая прычына, чаму працоўны тунель выглядае так, нібы ігнаруе паток, а селектар для няправільнага пратаколу дае такую ж цішыню.
| Field | Where it appears | What it decides |
|---|---|---|
| Security parameter index | ESP header, and the receiving state entry | Which association and keys the receiver applies |
| Sequence number | ESP header | Replay detection for that association |
| Next header | ESP trailer | What the decapsulated payload contains |
| Inner IP header | Inside tunnel-mode payload only | The original source and destination the endpoints act on |
| Traffic selectors | Policy, not the packet | Which local traffic is allowed to use the association |
Інструменты вытворцаў друкуюць тую ж інфармацыю ў зручнейшай форме. ipsec statusall у strongSwan пералічвае даччыныя асацыяцыі, іх селектары і лічыльнікі байтаў, што часта хутчэй, чым чытаць сыры вывад xfrm, калі вы ўжо ведаеце, на якую даччыную асацыяцыю глядзець.
Крок другі: дакажыце, што адзін паток рухае лічыльнікі
Лічыльнікі маюць сэнс, толькі калі вы ведаеце, што павінна было іх зрушыць, таму выберыце крыніцу і прызначэнне, якія селектар дакладна пакрывае, і адпраўце адзін бяскрыўдны запыт. Затым прачытайце той жа запіс зноў і параўнайце.
ip -s xfrm state
tcpdump -ni any espДва чытанні расказваюць розныя гісторыі. Пакеты, якія павялічваюцца на выхадзе, але ніколі на ўваходзе, указваюць на праблему перасылкі ці зваротнага шляху, а не на праблему ключа, бо пакет быў інкапсуляваны і пайшоў. Калі не рухаецца ні адзін лічыльнік, трафік наогул не супаў з палітыкай, і шукаць трэба ў селектары.
Перахоп на тым жа кроку пацвярджае інкапсуляцыю на дроце, уключаючы тое, ці знешнія пакеты — гэта ESP або ESP з UDP-інкапсуляцыяй. Ён таксама паказвае адрасы, якія фактычна перанеслі паток, а яны часам адрозніваюцца ад тых, што былі ў канфігурацыі, якую вы чыталі.
Крок трэці: змяніце адно і захавайце адкат
Запішыце крыніцу, прызначэнне, рэжым, селектары і лічыльнікі асацыяцыі, перш чым нешта рэдагаваць. Калі змена пагоршыць сітуацыю, менавіта гэты запіс дазволіць аднавіць папярэдні стан, а не будаваць працоўную канфігурацыю з здагадкі. Запіс займае хвіліну і эканоміць гадзіну пазней. Гэта таксама адзіны артэфакт, які перажывае чалавека, што ўнёс змену.
Змяніце адзін селектар або адзін параметр, перазагрузіце яго і паўтарыце другі крок на тым жа патоку. Выдаленне асацыяцыі разбурае кожны паток, які яе выкарыстоўвае, таму мэтанакіраваная праўка і перазагрузка даччынай асацыяцыі амаль заўсёды лепшыя за скід стану, каб паглядзець, што будзе.
Адкат для праўкі селектара — гэта аднаўленне папярэдняй палітыкі і перазагрузка, з агаворкай, што партнёру можа спатрэбіцца адпаведная змена, калі селектар узгадняецца, а не лакальны. Запішыце гэтую залежнасць, пакуль яна свежая, бо пара, адноўленая напалову, цяжэй для разумення, чым любы з двух канчатковых станаў.
Нарэшце, трымайце межы сумленнымі. Працоўная асацыяцыя ESP даказвае, што два шлюзы абараняюць і дастаўляюць сегмент, і нічога не кажа пра тое, ці аўтэнтыфікуе праграма зверху сваіх карыстальнікаў або шыфруе тое, што захоўвае. Гэта асобныя кантролі з асобнымі доказамі, і runbook скончаны толькі тады, калі наступны чалавек можа паўтарыць яго па нататках.