iOS IKEv2 ка strongSwan-у: није изабран предлог, поправите листу

iPhone подиже тунел, гејтвеј не одговара ничим, а телефон приказује општу грешку. Дневник strongSwan-а је прецизнији: no proposal chosen. Та порука значи да се две листе прихватљивих шифарских скупова никада нису преклопиле, па је размена завршена пре него што је аутентификација почела. То је проблем поклапања, а решење је учинити да се листе секу.

Где гејтвеј објављује своју политику

strongSwan уписује политику у конфигурацију, а узвичник на крају одлучује како се та политика чита. Са знаком листа је исцрпна: прихватају се само ти уноси и ништа друго. Без знака иста линија је редослед преференција, а демон може изабрати нешто што нисте намеравали. Питајте која је форма имплементирана пре него што било шта преведете, јер се две понашају различито према истом клијенту. Запишите тачну линију, са знаком, и тестирајте према њој.

Клијент који нуди ширу листу ипак може да се повеже на прикован гејтвеј, све док се једна комбинација појављује на обе стране. Оно што се не може догодити је преговарање изван прикованог скупа.

Зато профил копиран из друге VPN апликације може радити тамо где ваш не ради: та друга апликација је слала другу листу.

Имена морају да се подударају, а не да се побољшавају

Два превода збуњују људе који преносе вредности из strongSwan-а у iOS. Алгоритам интегритета написан као SHA1 у IKE предлогу путује у свом скраћеном облику, који iOS зове .SHA96. Diffie-Hellman група написана као modp1024 је група 2, коју iOS зове .group2. Замена са SHA-256 или групом 14 неће преговарати са гејтвејем који прихвата само старији пар. Клијент мора да опише исти алгоритам, а не јачи.

Поставите те вредности експлицитно у NEVPNProtocolIKEv2. Подразумеване вредности могу бити шире или уже од профила који замењујете, а разлика се види тек када руковање не успе.

Подређени предлог пада касније и тише

Конфигуришите и подређену безбедносну асоцијацију, не само IKE. Када се поклапају само IKE параметри, тунел се аутентификује и затим не преноси саобраћај, што је много тиши квар од одбијања. Поставите шифровање, интегритет, групу и животни век подређене у истом пролазу. Држите животни век клијента једнак или мањи од вредности гејтвеја, јер инсистирање на дужем даје исту поруку no proposal chosen из другог узрока. Неподударање тамо изгледа идентично као неподударање IKE у дневнику.

Проверите да ли се профил аутентификује сертификатима или заједничком тајном док сте у конфигурацији. Одбијање предлога и одбијање аутентификације појављују се на различитим линијама, а поправљање погрешног кошта дан. Тестирајте са свежом везом после сваке промене, по једна варијабла, јер кеширано стање скрива који се параметар померио.

Оставите стари скуп само док је потребан

Приквачивање SHA-1 уз групу од 1024 бита је мост, а не одредиште. Оба су застарела, а новији клијенти могу их потпуно одбити, што значи да ће профил пасти на следећем уређају без икакве промене на вашој страни. Третирајте приквачивање као привремено и тако напишите у записнику.

Ако је strongSwan ваш, додајте модеран предлог и пустите оба краја да преговарају нагоре док стари унос остаје за старије уређаје. Прочитајте излаз статуса демона да видите који је скуп свака веза заиста користила. Затим уклоните приквачивање на страни клијента када модерни пар буде потврђен. Подигнут тунел није довољан доказ, јер се може подићи на скупу који сте покушавали да умировите. Документација strongSwan-а за IKEv2 описује синтаксу предлога и strict ознаку.