iPhone Always On VPN: два тунела можат да делат една виртуелна IP

На надгледуван iPhone со управуван Always On профил, телефонот држи тунел за секој активен IP интерфејс, па мобилната мрежа и Wi-Fi добиваат секој свој. Серверот потоа наведува две IKE безбедносни асоцијации за еден уред, често споделувајќи една виртуелна адреса, а првиот импулс е тоа да се нарече rekey јамка и да се почнат да се менуваат тајмерите. Тој импулс обично е погрешен. Поминете ги чекорите подолу по редоследот по кој доказите се појавуваат на серверот и оставете ги поставките на телефонот на мир додека серверот не ви каже кој случај го имате.

Започнете со двете редови што серверот веќе ги има

Наведете ги асоцијациите со swanctl --list-sas и прочитајте четири полиња во двата записи: далечната адреса, автентифицираниот идентитет, доделената виртуелна IP и времето на создавање. Две различни надворешни адреси со еден идентитет и една виртуелна IP се формата што го започна ова прашање, и вреди да се запише пред каква било промена. Потоа проверете ги подредените асоцијации прикачени на секоја, бидејќи селекторите на сообраќај одлучуваат дали барањето на дестинација некогаш би можело да ги разликува двата тунела. Пар што се појавува и исчезнува во секунди е друго животно од пар во кој двата живеат со часови.

Сортирајте ја листата по време на создавање пред да донесете заклучок. Соседството во излезот не значи ништо, а табеларниот список токму на таа грешка ве поканува.

Одлучете кое преклопување го гледате

IKEv2 rekey и make-before-break реавтентикацијата намерно создаваат кратко преклопување, воспоставувајќи ја новата асоцијација пред да се избрише старата. Временските ознаки го решаваат случајот, бидејќи стара SA што исчезнува секунда или две по појавувањето на новата е обновување што ја врши својата работа. Независните интерфејс тунели никогаш не изгледаат така, бидејќи секој опстојува додека неговиот интерфејс е горе, а бришењето на едниот не произлегува од создавањето на другиот.

Apple управуваното Always On однесување е по интерфејс, затоа надгледуван уред може законски да изгледа поактивен од рачно поставен профил. Прекинувачот за автоматско поврзување на апликација на провајдер не значи истото, а ни обичното 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 со активна сесија, потоа вратете се и проверете дали одговорите пристигнуваат во двете насоки. Направете го тоа двапати, бидејќи втората транзиција е местото каде што обично се појавува застарена политика. Тестирајте со услуга што одговара на врската што сте ја отвориле и повторете го излегувањето додека тунелот носи сообраќај наместо да стои неактивен. Телефон што може да испраќа, но не да прима, изгледа здраво во дневникот за ракување и скршено во прелистувач.

Екран за состојба сведен на еден ред не е доказ за дизајн што работи, само доказ дека еден тунел заминал. Двете насоки мора да работат пред да помине транзиција. Запишете што забележавте, заедно со двата излези од проверката на преклопување, за следниот инженер да може да споредува наместо да ја повторува прошетката.