iPhone Always On VPN: два тунела могу делити једну виртуелну IP
Always On тунели по интерфејсу нису неуспешан rekey. Упоредите две SA на серверу, затим одлучите да ли један идентитет може да држи две унутрашње адресе.
На надгледаном 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 са активном сесијом, затим се вратите и проверите да одговори стижу у оба смера. Урадите то два пута, јер се на другом прелазу обично појављује застарела политика. Тестирајте услугом која одговара на вези коју сте отворили и поновите излазак док тунел носи саобраћај уместо да стоји неактиван. Телефон који може да шаље али не да прима изгледа здраво у дневнику руковања и покварено у прегледачу.
Екран стања сведен на један ред није доказ дизајна који ради, само доказ да је један тунел отишао. Оба смера морају да раде пре него што прелаз прође. Запишите шта сте приметили, заједно са два излаза провере преклапања, да би следећи инжењер могао да упореди уместо да понавља шетњу.