L2TP, GRE чи IPsec: який рівень має нести сесію?

Два питання заплутуються, щойно L2TP, GRE та IPsec потрапляють до однієї проєктної нотатки: яку сесію я несу і який рівень її захищає? Помилка в першому залишає все нижче внутрішньо узгодженим, поки розв’язується не та задача — маршрутизоване накладення, збудоване там, де користувачам треба було дзвонити, або концентратор віддаленого доступу замість шлюзу між майданчиками. Таблиця нижче змушує провести цю відмінність до того, як хтось увійде на пристрій. Заповніть її по порядку, і кожен рядок стане тим, що можна перевірити окремо.

Почніть із сесії, а не зі списку протоколів

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

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

Дайте кожному рівню рівно одне завдання

L2TPv2 несе сесії PPP між двома кінцевими точками. PPP веде узгодження каналу і, коли воно узгоджується, автентифікацію користувача; L2TP не додає жодної криптографії, тому голий демон L2TP не реалізує жодної частини відношення безпеки IPsec і належить лише всередину каналу, якому ви вже довіряєте.

GRE — це інкапсуляція між двома адресами. Вона несе пакети мережевого рівня через логічне накладення і сама по собі не дає ні конфіденційності, ні автентифікованої ідентичності вузла. Це не дефект: заголовок спроєктовано простим, щоб він залишався дешевим в обробці на обладнанні пересилання. Наслідок у тому, що GRE відповідає на питання «як перемістити цей пакет між двома адресами» і ні на що більше — саме те питання, яке йому варто ставити.

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

Опишіть шлях пакета до конфігурації

Візьміть один пакет і перелічіть кожен додаваний заголовок у порядку додавання, називаючи пристрій, який його додає. Для віддаленого користувача це зазвичай PPP усередині L2TP усередині IPsec; для накладення майданчиків — внутрішній пакет IP усередині GRE усередині IPsec. Якщо два пристрої додають той самий заголовок, у вас петля або дубльований тунель, і жодне редагування політики це не виправить.

Той самий список вирішує питання MTU, бо корисний внутрішній розмір — це виміряний MTU шляху мінус щойно перелічені заголовки і нічого більше. Не копіюйте число з повідомлення на форумі: складіть накладні витрати зовнішнього IP, UDP і ESP, потім GRE або L2TP, потім PPP там, де він застосовується, і відніміть від MTU шляху, який ви справді виміряли. Симптоми, що з’являються лише за великих передач, або сесії, які встановлюються й потім гинуть на першій великій відповіді, зазвичай ведуть до того, що це додавання зробили на око.

Перевіряйте кожен рівень окремо, ззовні всередину

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

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

На обладнанні Cisco еквівалент залежить від ролі, а точний синтаксис залежить від платформи й версії: show crypto session для вузлів IPsec, лічильники інтерфейсу для інтерфейсу GRE або тунелю та перевірка VPDN або PPP для ролі віддаленого доступу. Набір команд, що завершує PPP, нічого не доводить про підтримку GRE, а робочий інтерфейс GRE нічого не доводить про службу PPP, тому перевіряйте роль, яку ви справді налаштували, а не ту, що на схемі.

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

Упорядкуйте демонтаж, потім перевірте знову

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

Після перебудови повторіть чотири приймальні спостереження по одному: зовнішня досяжність, установлене об’єднання IPsec, установлена сесія PPP там, де проєкт її передбачає, і внутрішнє пересилання на реальну адресу призначення. Один зелений сигнал не доводить решту три, і ця прогалина — збій, що найдовше живе в експлуатації: тунель піднято, зашифровано й нічого не пересилає, бо внутрішній маршрут так і не додали.

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