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 с активна сесия, след това се върнете и проверете, че отговорите пристигат в двете посоки. Направете го два пъти, защото при втория преход обикновено се появява остаряла политика. Тествайте с услуга, която отговаря на връзката, която сте отворили, и повторете излизането, докато тунелът носи трафик, вместо да стои бездействащ. Телефон, който може да изпраща, но не да получава, изглежда здрав в дневника за ръкостискане и счупен в браузъра.

Екран за състоянието, сведен до един ред, не е доказателство за работещ дизайн, а само доказателство, че един тунел е изчезнал. И двете посоки трябва да работят, преди преход да мине. Запишете какво сте наблюдавали, заедно с двата изхода от проверката за застъпване, за да може следващият инженер да сравни, вместо да повтаря разходката.