Ping з IPsec-шлюзу використовує іншу адресу джерела

Надішліть ping на далекий бік з IPsec-шлюзу, не отримайте відповіді й зробіть висновок, що тунель зламано, хоча кожне робоче навантаження за шлюзом передає трафік нормально. Ці два результати не суперечать одне одному. Ping, запущений на шлюзі, — це пакет із локальним джерелом, і шлюз вибирає адресу джерела зі своєї таблиці маршрутизації. Цей вибір може відрізнятися від адрес, які використовує реальний трафік майданчика, а це змінює, яка політика збігається і який зворотний маршрут застосовується. Вирішіть, що тест має довести, перш ніж щось читати в його результаті.

Три різні питання, на які може відповісти ping

Перше питання — чи доступний далекий бік узагалі з цього хоста. Друге — чи пропускають селектори тунелю або політика на основі маршрутів трафік з певного джерела. Третє — чи працює переспрямований трафік від робочого навантаження за шлюзом від краю до краю. Одна команда не може відповісти на всі три, і саме адреса джерела розділяє їх.

Спочатку виберіть питання. Інакше невдалий ping стане доказом тієї теорії, яка у вас уже була.

Чому шлюз вибирає адресу, якої ви не чекали

Коли ви пінгуєте призначення, локальний стек вибирає джерело з маршруту, що йому відповідає. На тунелі на основі маршрутів це може бути адреса ланки інтерфейсу тунелю, яка в багатьох проєктах майданчика є парою 169.254.x.x, вибраною для переходу точка-точка. Ці адреси існують, щоб ланка працювала; на далекому боці вони не оголошуються як мережі-джерела застосунків.

Тож далекий бік може отримати ехо-запит з адреси, зворотного маршруту до якої він не має, або з такої, якій не відповідає жоден селектор. Тунель може бути справним, а ping усе одно може не проходити, і це саме той хибнонегативний результат, про який ця стаття.

Вибирайте джерело свідомо

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

Не позичайте адресу робочого навантаження для тесту. Видавання себе за хост, який не призначений шлюзу, створює результат, який ніхто не зможе відтворити, а на деяких стеках це відмовляє так, що виглядає як несправність тунелю.

Читайте зворотний шлях, а не лише запит

Перевірте, яке джерело насправді приходить на віддалене призначення, включно з будь-яким навмисним перетворенням у дорозі. Потім перевірте зворотний маршрут далекого боку до цього джерела та селектори або політику, які його допускають. Запит, що приходить із неочікуваним джерелом, — це питання маршрутизації та політики, а не криптографії.

Тут також перехоплення пакетів допомагає більше, ніж ще один ping: воно показує джерело, яке побачив далекий бік, а це і є адреса, якої має досягти його відповідь.

Потім перевірте робоче навантаження

Вирішальний тест — це ping від звичайного хоста за шлюзом до звичайного хоста за віддаленим шлюзом. Він задіює роль шлюзу в переспрямуванні, реальне джерело застосунку та справжній зворотний шлях, а саме цей потік і важливий користувачам.

Тримайте результати окремо у своїх нотатках: доступність зі шлюзу, допуск політики для вибраного джерела та переспрямований трафік. Успішний закріплений ping — корисний доказ того, що тунель щось переносить; це не доказ того, що працює кожен переспрямований потік. А автоматично вибране джерело шлюзу, до якого не можна дістатися, не є доказом того, що тунель майданчика не працює.

Не додавайте загальний маршрут для 169.254.0.0/16 лише для того, щоб отримати одну діагностичну відповідь. Це обмінює оманливий тест на постійне рішення про маршрутизацію, і наступна людина успадковує його без контексту.