iPhone Always On VPN: два тунэлі могуць дзяліць адзін віртуальны IP

На кантраляваным iPhone з кіраваным профілем Always On тэлефон трымае тунэль для кожнага актыўнага IP-інтэрфейса, таму сотавая сетка і Wi-Fi атрымліваюць кожны свой. Затым сервер пералічвае дзве IKE-асацыяцыі бяспекі для адной прылады, часта са агульным віртуальным адрасам, і першы парыў — назваць гэта цыклам rekey і пачаць змяняць таймеры. Гэты парыў звычайна памылковы. Прайдзіце крокі ніжэй у тым парадку, у якім доказы з'яўляюцца на серверы, і не чапайце налады тэлефона, пакуль сервер не скажа, які ў вас выпадак.

Пачніце з двух радкоў, якія сервер ужо мае

Пералічыце асацыяцыі з дапамогай swanctl --list-sas і прачытайце чатыры палі ў абодвух запісах: выдалены адрас, аўтэнтыфікаваную ідэнтычнасць, прызначаны віртуальны IP і час стварэння. Два розныя знешнія адрасы з адной ідэнтычнасцю і адным віртуальным IP — гэта форма, з якой пачалося гэтае пытанне, і яе варта запісаць перад любымі зменамі. Затым праверце даччыныя асацыяцыі, прывязаныя да кожнай з іх, бо селектары трафіку вырашаюць, ці зможа пошук па прызначэнні калі-небудзь адрозніць два тунэлі. Пара, якая з'яўляецца і знікае за секунды, — іншая жывёла, чым пара, дзе абедзве жывуць гадзінамі.

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

Вызначце, на якое перакрыцце вы глядзіце

Rekey IKEv2 і паўторная аўтэнтыфікацыя make-before-break наўмысна ствараюць кароткае перакрыцце, усталёўваючы новую асацыяцыю да выдалення старой. Часавыя адзнакі вырашаюць справу, бо старая SA, якая знікае праз секунду-дзве пасля з'яўлення новай, — гэта абнаўленне, якое выконвае сваю працу. Незалежныя інтэрфейсныя тунэлі ніколі так не выглядаюць: кожны існуе, пакуль яго інтэрфейс падняты, а выдаленне аднаго не вынікае са стварэння іншага.

Кіраваныя паводзіны Always On ад Apple дзейнічаюць па інтэрфейсах, таму кантраляваная прылада можа законна выглядаць заняцейшай за профіль, наладжаны ўручную. Перамыкач аўтападключэння ў праграме правайдэра не азначае таго ж, і звычайнае правіла on-demand таксама. Агляд разгортвання Apple апісвае мадэль па інтэрфейсах; параўнайце свае два радкі з ім, перш чым меркаваць цыкл. Абедзве формы таксама бяруць з аднаго пула на серверы, таму перакрыцце — ваша адзіны ранні сігнал.

Убачце, чаму адзін віртуальны адрас для двух тунэляў ламае адказы

Адказ тэлефону адрасуецца ўнутранаму адрасу, і ядро выбірае зыходны тунэль па прызначэнні і палітыцы, а не па інтэрфейсе, які выкарыстаў тэлефон. Дзве адначасовыя асацыяцыі з адным віртуальным IP і супадаючымі палітыкамі пакідаюць рашэнне пра маршрутызацыю без спосабу сказаць, якой сесіі належыць адказ. Некаторыя адказы ідуць няправільным тунэлем, і тэлефон паказвае злучэнне, якое працуе ў адзін бок або памірае, калі з'яўляецца Wi-Fi. Два вывады каманд даказваюць стан: swanctl --list-sas паказвае той жа віртуальны IP на абодвух SA, а ip xfrm policy паказвае два аднолькавыя селектары.

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

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

Змяніце пул або мадэль паралелізму, а не таймер rekey

У канфігурацыі swanctl унікальнасць — гэта яўная палітыка на злучэнні: unique = replace выдаляе старэйшае злучэнне, калі ўсталёўваецца новае, а unique = keep адхіляе навачка. Абедзве значэнні дзейнічаюць падчас наладжвання злучэння, а не на даччыных SA ўнутры яго.

connections {
  ios-alwayson {
    unique = replace
  }
}

Ні адно са значэнняў не нейтральнае для кліента па інтэрфейсах. keep вяртае ахайны экран стану, адмаўляючы другому тунэлю, і ламае кіраваную канструкцыю, тады як replace зносіць старэйшы тунэль і з'яўляецца тым жа кампрамісам у процілеглы бок. Калі абодва тунэлі сапраўды патрэбныя, бэкенд пула павінен выдаваць розныя арэнды для адной ідэнтычнасці, а яго ключ арэнды павінен адрозніваць запыты. Статычная табліца «ідэнтычнасць — адрас» ахвотна верне той жа адрас двойчы і адновіць зыходную праблему з большай канфігурацыяй. Праверце, як бэкенд фарміруе ключы арэнды, перш чым дадаваць другое статычнае супастаўленне.

Праверце пераходы, якія вы сапраўды ўкараняеце

Выйдзіце з зоны Wi-Fi з актыўнай сесіяй, затым вярніцеся і праверце, што адказы прыходзяць у абодва бакі. Зрабіце гэта двойчы, бо менавіта на другім пераходзе звычайна з'яўляецца састарэлая палітыка. Праверце на сэрвісе, які адказвае на адкрытым вамі злучэнні, і паўтарыце выхад, пакуль тунэль нясе трафік, а не проста стаіць. Тэлефон, які ўмее адпраўляць, але не прымаць, выглядае здаровым у журнале рукапаціскання і зламаным у браўзеры.

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