iOS IKEv2 към strongSwan: не е избрана оферта, поправете списъка

iPhone вдига тунела, шлюзът отговаря с нищо, а телефонът показва обща грешка. Журналът на strongSwan е по-конкретен: не е избрана оферта. Това съобщение означава, че двата списъка с приемливи шифърни комплекти никога не са се препокрили, затова обменът е приключил преди началото на удостоверяването. Това е проблем на съвпадение и решението е списъците да се пресекат.

Къде шлюзът заявява политиката си

strongSwan записва политиката си в конфигурацията и удивителният знак в края решава как се чете тази политика. Със знака списъкът е изчерпателен: приемат се тези записи и нищо друго. Без него същият ред е ред на предпочитания и демонът може да избере нещо, което не сте имали предвид. Питайте коя форма е разгърната, преди да превеждате каквото и да е, защото двете се държат различно срещу един и същ клиент. Запишете точния ред, включително знака, и тествайте срещу него.

Клиент, който предлага по-широк списък, все още може да се свърже със закрепен шлюз, стига една комбинация да присъства от двете страни. Това, което не може да се случи, е договаряне извън закрепения набор.

Затова профил, копиран от друго VPN приложение, може да работи там, където вашият не работи: другото приложение е доставяло различен списък.

Имената трябва да съвпадат, а не да се подобряват

Два превода хващат хората, които прехвърлят стойности от strongSwan към iOS. Алгоритъмът за цялост, записан като SHA1 в IKE оферта, пътува в съкратената си форма, която iOS нарича .SHA96. Групата на Дифи-Хелман, записана като modp1024, е group 2, която iOS нарича .group2. Замяната с SHA-256 или group 14 няма да договори нищо срещу шлюз, който приема само по-старата двойка. Клиентът трябва да описва същия алгоритъм, а не по-силен.

Задайте тези стойности явно в NEVPNProtocolIKEv2. Стойностите по подразбиране може да са по-широки или по-тесни от профила, който заменяте, и разликата се показва само когато ръкостискането се провали.

Офертата на дъщерната връзка се проваля по-късно и по-тихо

Конфигурирайте асоциацията за сигурност на дъщерната връзка заедно с тази на IKE. Когато съвпадат само IKE параметрите, тунелът се удостоверява и след това не носи трафик, което е много по-тих провал от отказ. Задайте шифроването, цялостта, групата и живота на дъщерната връзка в същия проход. Дръжте живота на клиента на стойността на шлюза или по-ниско, защото настояването за по-дълъг дава същото съобщение за липса на избрана оферта, но от друга причина. Несъответствието там изглежда идентично на IKE несъответствие в журнала.

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

Оставете стария комплект само докато е нужен

Закрепването на SHA-1 с 1024-битова група е мост, а не дестинация. И двете са остарели и по-новите клиенти може да ги откажат напълно, което означава, че профилът ще се провали на следващото устройство без промяна от ваша страна. Считайте закрепването за временно и кажете това в записа.

Ако strongSwan е ваш, добавете модерна оферта и оставете двете страни да договарят нагоре, докато старият запис остава за по-стари устройства. Прочетете изхода от състоянието на демона, за да видите кой комплект е използвала всяка връзка всъщност. След това премахнете закрепването от страна на клиента, след като модерната двойка бъде потвърдена. Тунел, който се вдига, не е достатъчно доказателство, защото може да се вдигне на комплекта, който сте се опитвали да оттеглите. Документацията на strongSwan за IKEv2 описва синтаксиса на офертите и строгия маркер.