Зыходны ESP без адказу не значыць, што VPN мёртвы
ESP абараняе адзін кірунак на асацыяцыю і нічога не пацвярджае. Супастаўце ўнутраную размову і ўваходную SA, перш чым называць сервер неадказным.
Вы захапілі трафік на IPsec-хосце, убачылі, як пакеты ESP сыходзяць, не ўбачылі нічога ў адказ і зрабілі выснову, што далёкі бок зламаны. Захоп гэтаму не спрыяе. ESP абараняе адзін кірунак размовы і нічога не пацвярджае на ўзроўні IP, таму адсутнасць зваротнага ESP можа з роўнай лёгкасцю азначаць, што праграме не было чаго сказаць, і тое, што тунель мёртвы. Прачытайце ўнутраны абмен і стан боку прыёму, перш чым вінаваціць любы з бакоў.
Міф: кожны абаронены пакет заслугоўвае адказу
ESP не з'яўляецца пратаколам запыт-адказ. Ён шыфруе і аўтэнтыфікуе ўсё, што выбірае палітыка, а атрымальнік правярае, дэшыфруе і дастаўляе гэты ўнутраны пакет, не ствараючы ўласнага пакета. UDP-запыт, які прызначэнне ігнаруе, або ICMP-рэха, якое ўваходная палітыка адкідае, ствараюць цішыню ў абодвух кірунках як правільны вынік. Калі лічыць гэтую цішыню збоем транспарту, вы адправіцеся шукаць сеткавую няспраўнасць, якой ніколі не было.
Аднабаковы захоп насамрэч даказвае толькі тое, што стэк адпраўніка нешта зашыфраваў у гэтым пункце назірання. Нічога пра прыход і нічога пра намер адказаць. Карыснае пытанне не "чаму няма адказу", а "што павінна была спарадзіць унутраная размова".
Дзве SA, два SPI, адна размова
Асацыяцыі бяспекі IPsec аднанакіраваныя, таму звычайны абаронены абмен уключае ўваходную і зыходную асацыяцыі з асобнымі ідэнтыфікатарамі і незалежным станам. Шукаць зваротны трафік па SPI зыходнага пакета — гэта памылка катэгорыі, бо любы адказ ідзе пад уласнай зыходнай SA партнёра з уласным SPI. Супастаўляйце пару па селектарах трафіку і адрасах партнёра.
Перагенерацыя ключоў ускладняе карціну на некалькі секунд за раз, бо стары і заменны стан могуць перакрыжоўвацца. Калі сімптом пачаўся вакол перагенерацыі ключоў, збірайце ідэнтыфікатары асацыяцый і часовыя меткі разам, а не толькі назву злучэння.
Што павінен зрабіць атрымальнік, перш чым нешта адкажа
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Кожны радок адмаўляе незалежна, і ў кожнай адмовы свой уладальнік, таму адзін захоп не можа іх адрозніць. Уваходны лічыльнік — адзінае прамое сведчанне прыходу, бо пакет, які не прайшоў аўтэнтыфікацыю або праверку паўтору, адкідаецца без любога адказу. Партнёр, у якога ўваходны лічыльнік не зрушыўся, такім чынам не паведамляе вам нічога пра сваю палітыку.
Дастаўка — асобны крок ад дэшыфравання. Стан можа быць сапраўдным, а пакет усё роўна адкінуты пазней уваходнай палітыкай або маршрутам, які не ўключае ўнутраную мэту, таму праверце, ці бачыў мэтавы хост адкрыты тэкст, замест таго каб меркаваць, што чысты лічыльнік азначае, што пакет пайшоў куды трэба.
Уласны ESP — не UDP
Уласны ESP — гэта IP-пратакол 50, які не з'яўляецца ні TCP, ні UDP і наогул не мае портаў. Таму правіла міжсеткавага экрана, якое дазваляе IKE на UDP 500, нічога не кажа пра шлях даных, а фільтр, напісаны вакол портаў, можа дазволіць тунелю дамовіцца, а затым адкінуць усё, што ў ім пераносіцца. Тэстуйце шлях даных асобна, у тым рэжыме, які вы фактычна назіралі.
За NAT форма змяняецца: абароненая карысная нагрузка ідзе ўнутры UDP, звычайна на порце 4500, як вызначае RFC 3948. Запішыце актыўны рэжым перад напісаннем любога правіла, бо прылада на шляху можа цалкам па-рознаму ставіцца да ўласнага ESP і ESP у абгортцы UDP, а некаторыя прамежкавыя прылады дазваляюць адно і адкідаюць другое.
Чытайце лічыльнікі, што належаць гэтаму інцыдэнту
На хосце strongSwan swanctl --list-sas паказвае лічыльнікі пакетаў і байтаў па кожнай асацыяцыі ў абодвух кірунках, чаго дастаткова, каб аддзяліць "ніколі не прыйшло" ад "прыйшло і не было адказана". На Linux /proc/net/xfrm_stat лічыць сукупныя збоі, такія як адсутнасць стану, адсутнасць палітыкі і памылкі пратаколу. Гэтыя сумы назапашваюцца з моманту загрузкі і належаць аднаму сеткаваму прасторы імён, таму вялікая лічба — не атрыбуцыя.
Вазьміце два замеры вакол акна інцыдэнту ў правільнай прасторы імён і параўнайце дэльты, інакш вы павесіце памылкі мінулага тыдня на сённяшні тыкет. Змесціце прастору імён і абедзве часовыя меткі ў тыкеце, каб наступны чытач мог узнавіць параўнанне, а не давяраць суме.
Называйце этап, а не падазраванага
Карысная выснова кажа, дзе спыніўся пакет: ніколі не атрыманы, атрыманы і адкінуты, дастаўлены, але без адказу, або адказаны і згублены на зваротным шляху. Кожны з гэтых пунктаў паказвае на іншага ўладальніка і іншую наступную каманду. "Няма адказу ад VPN-сервера" згортвае чатыры розныя няспраўнасці ў адзін сказ, якога захоп ніколі не апраўдваў.
Трымайце захопы вузкімі, а сыры стан ядра — па-за тыкетамі, бо ён можа несці ключавы матэрыял, якому няма чаго рабіць па-за хосце. Дэльты лічыльнікаў і часовыя меткі — гэта тое, што варта перадаць наступнаму чалавеку.