Пинг от IPsec шлюза използва различен адрес на източника

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

Три различни въпроса, на които пингът може да отговори

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

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

Защо шлюзът избира адрес, който не очаквате

Когато пингвате дестинация, локалният стек избира източник от маршрута, който ѝ съответства. При тунел, базиран на маршрут, това може да е адресът на връзката на тунелния интерфейс, който в много проекти на обекти е двойка 169.254.x.x, избрана за прехода точка-точка. Тези адреси съществуват, за да работи връзката; те не се обявяват като мрежи на източник на приложения от далечната страна.

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

Изберете източника умишлено

На контролиран Linux шлюз изберете източник, който вече е назначен локално: ping -c 4 -I 10.30.0.1 10.40.0.20. Адресите тук са илюстративни, затова заменете с реалния вътрешен адрес на шлюза и реална далечна дестинация и потвърдете, че избраният източник принадлежи на това устройство и е допуснат от политиката на обекта.

Не заемайте адреса на натоварване за теста. Имитирането на хост, който не е назначен на шлюза, създава резултат, който никой не може да възпроизведе, а на някои стекове се проваля по начини, които изглеждат като повреда в тунела.

Четете обратния път, не само заявката

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

Тук също прихващането на пакети помага повече от още един пинг: то показва източника, който далечната страна е видяла, а това е адресът, до който трябва да стигне отговорът ѝ.

След това тествайте натоварването

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

Дръжте резултатите отделно в бележките си: достъпност от шлюза, допускане от политиката за избран източник и препратен трафик. Успешният фиксиран пинг е полезно доказателство, че тунелът носи нещо; той не е доказателство, че всеки препратен поток работи. И автоматично избран източник на шлюза, който не е достъпен, не е доказателство, че тунелът на обекта е спрян.

Не добавяйте общ маршрут за 169.254.0.0/16 само за да получите един диагностичен отговор. Това заменя подвеждащ тест с постоянно решение за маршрутизиране и следващият човек го наследява без контекста.