Когато IKEv2 върне TS_UNACCEPTABLE, сравнете реалните подмрежи

Четете TS_UNACCEPTABLE като несъгласие за покритието, а не като повреден профил. Шлюзът казва, че двата върха не са успели да се споразумеят кои адреси може да носи този тунел. IKE SA може вече да е вдигната в този момент, затова клиентът може да изглежда свързан без дъщерна SA зад него. След като го формулирате така, работата става механична. Запишете предвидените префикси на двете страни, сравнете ги в една посока и стеснявайте, докато се пресекат.

Първо запишете предвидените двойки

Преди да пипате конфигурацията, избројте четири стойности: диапазонът на източника на инициатора, диапазонът на дестинацията му и същата двойка, видяна от ответника. Запишете и семейството на адресите на всяка от тях. Диапазон IPv4 и диапазон IPv6 са различни типове селектори и нито един не може да се сгъне в полезния товар на другия.

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

Обърнете обозначенията преди сравняване

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

Ответникът може да стесни оферта до приемливо подмножество вместо да я отхвърли. Този изход е по-лош от чист провал, защото работи наполовина. Поискайте 10.0.0.0/16, когато политиката разрешава 10.0.5.0/24, и може да получите дъщерна SA, покриваща само тази /24. Един хост отговаря, всичко останало остава извън обхвата и нищо в клиента не го казва. Четете приетите селектори, а не поисканите, преди да заключите, че договарянето е успяло.

Профили road warrior, които искат маршрут по подразбиране, попадат тук постоянно. Шлюз, изграден за разделен достъп, стеснява оферта с пълен диапазон до своите подмрежи и клиентът трябва да приеме стеснения резултат или да се провали шумно.

Четете отказа от един опит

Съберете двата журнала от един и същ опит за свързване. Запазеният профил показва какво сте конфигурирали, а не какво е било предложено, и на strongSwan swanctl --log отпечатва полученото уведомление заедно със селекторите, които е носело.

След това проверете какво действително е инсталирано. swanctl --list-sas показва селекторите на дъщерната SA, а ip xfrm policy показва същите диапазони като записи в политиката на ядрото. Дъщерна SA в този списък със селектори, които не сте предвидили, е събитие на стесняване; липса на дъщерна SA плюс TS_UNACCEPTABLE в журнала е отказ.

Докато сте там, отделете близките съседи. INVALID_SELECTORS се оплаква от селектор вътре в установена дъщерна SA, докато INTERNAL_ADDRESS_FAILURE означава, че ответникът не е могъл да отпусне виртуален адрес, което е проблем на пул, а не на покритие.

Проверете какво тихо свива набора

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

Третото са ограниченията на протокол и порт. Когато политиката разрешава само TCP 445, дъщерна SA може да се вдигне, докато ICMP и UDP остават извън нея, и потребителят съобщава за счупен тунел, когато единствено един протокол е бил разрешен.

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

Докажете покритието с трафик, който пасва

След като дъщерната SA се инсталира, изпратете една заявка, която със сигурност попада в приетите диапазони. Гледайте броячите, а не иконата за състояние: ip -s xfrm state и броячите зад ip xfrm policy се увеличават, когато пакет бъде съпоставен и защитен. Байтов брой, който остава нула след реален трафик, означава, че ядрото никога не е избрало тази политика.

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

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