AH ці ESP? Рашэнне залежыць ад таго, што павінен абараніць пакет

Дзве прапановы IPsec могуць назваць адзін і той жа алгарытм цэласнасці на аснове SHA і пры гэтым патрабаваць розныя пратаколы абароны; AH і ESP не два напісанні адной налады аўтэнтыфікацыі. Спачатку прачытайце пратакол, потым яго алгарытмы, потым рэжым, і большасць няяснасці знікне. AH аўтэнтыфікуе пакет, уключаючы тыя палі загалоўка IP, якія застаюцца нязменнымі ў шляху, а ESP аўтэнтыфікуе і шыфруе тое, што ён інкапсулюе, і пакідае знешні загаловак без змен. Гэтая розніца вызначае больш разгортванняў, чым любое імя хэша.

Што AH пакрывае, а ESP не

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

Гэты ахоп таксама прычына, чаму AH далікатны на практыцы. Зменлівыя палі, такія як TTL, кантрольная сума загалоўка і некаторыя опцыі, нельга аўтэнтыфікаваць, бо маршрутызатары могуць іх перапісаць, таму пратакол абнуляе іх перад вылічэннем праверкі. Такім чынам, усё, што перапісвае адрасы, ламае вылічэнне, а не толькі палітыку.

NAT ператварае выбар у абмежаванне

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

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

Рэжым памнажае пытанне

ESP у транспартным рэжыме абараняе карысную нагрузку верхняга ўзроўню і пакідае загаловак IP без змен; у тунельным рэжыме ён інкапсулюе ўвесь унутраны пакет, уключаючы ўнутраны загаловак IP, і абараняе яго. AH мае тыя ж два рэжымы, таму AH або ESP гэта насамрэч чатыры камбінацыі да выбару любога алгарытму.

Камбінаваныя алгарытмы ESP затым вырашаюць цэласнасць без другога пратаколу. AES-GCM і ChaCha20-Poly1305 аўтэнтыфікуюць і шыфруюць у адной канструкцыі, таму даданне AH зверху нічога не дае, але каштуе яшчэ адзін загаловак і яшчэ адну ўгоду. Архітэктура дазваляе AH і ESP разам, і практычнае пытанне ці падтрымліваюць вашы шлюз і выпуск гэтую камбінацыю і ці зможа хтосьці потым гэта суправаджаць.

Сумленная замена для AH-only

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

Бачыць ESP у прапанове таксама не доказ шыфравання. Чытайце алгарытм шыфравання: запіс NULL азначае толькі цэласнасць, а запіс камбінаванага рэжыму і тое, і другое.

Вырашайце трыма пытаннямі

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

Затым праверце, што было прынята, а не што было прапанавана. ip xfrm state паказвае пратакол усталяванай асацыяцыі, рэжым і алгарытмы, і неадпаведнасць не ўсталёўвае нічога, што зявляецца больш чыстай няўдачай, чым тунель, які ўзнімаецца без патрэбнай вам абароны.

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