Разликување на фрагментацијата на IKEv2 од проблем со синџир на сертификати

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

Два механизми за фрагментација, еден симптом

IKEv2 има свое проширување за фрагментација, дефинирано во RFC 7383, кое заштитените IKE пораки ги дели на помали IKE пораки. Страните преговараат за таа можност, а пораката ја составува повторно имплементацијата на IKE, а не IP слојот.

Обичната IP фрагментација е друг механизам со различен режим на откажување. Рутерот меѓу страните фрагментира голема датаграма или ја отфрла и враќа ICMP порака што може никогаш да не стигне до испраќачот. Некои мрежи тивко ги отфрлаат фрагментите, а некои средни уреди го обработуваат првиот фрагмент, но не и остатокот. Од гледна точка на апликацијата, сите три случаи изгледаат исто.

Поминувањето низ NAT додава трета променлива, бидејќи тогаш ESP се завиткува во UDP и надворешниот пакет станува поголем додека изгледа како обичен UDP сообраќај на портата 4500. Патека што добро пропушта UDP сепак може да не успее на датаграма што повеќе не се собира.

Прочитајте ја размената што не успеа

Барајте го преминот, а не грешката. Дневник што покажува дека првата размена е испратена и одговорена, а потоа ништо, ви кажува дека следната порака никогаш не завршила. Привремено подигнете го нивото на дневникот и споредете ги пријавените големини на двете страни.

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

Сменете ја патеката, не сертификатот

Тестирајте го истиот клиент, истиот сертификат и истата конфигурација од друга мрежа. Мобилниот хотспот е обично најевтината втора патека, и тој навистина се разликува од канцелариската врска, а не само номинално.

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

Измерете ја размената пред да уредите нешто

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

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

Првите две ја даваат бројот на сертификати и големината на датотеката, што е разумен показател за тоа колку голема ќе биде пораката за автентикација. Ping проверката известува дали датаграма од таа големина преживува на патеката, а бројачите на интерфејсот покажуваат дали фрагментите биле отфрлени на вашата страна. На Windows, еквивалентната проверка е ping со знамето do-not-fragment и експлицитна големина на корисниот товар.

Повторете ја проверката надолу додека не успее. Најголемата големина што поминува е работниот буџет за таа патека, и е покорисна од која било објавена стандардна вредност.

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

Ако патеката отфрла големи датаграми, овозможете IKE фрагментација на двете страни и потврдете дека проширувањето било преговарано, а не само понудено. Ако патеката лошо се справува со фрагментите на IP ниво, поправката припаѓа таму или во MTU на надворешниот интерфејс, а не во складиштето за сертификати.

Ако синџирот е непотребно долг, скратете го до средните сертификати што на страната навистина ѝ се потребни. Отстранувањето на корен во кој клиентот веќе има доверба е разумно одржување; отстранувањето на среден не е, а исклучувањето на проверката за да се намали пораката заменува проблем со доставување за проблем со безбедност.

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