IKEv2 проти L2TP/IPsec: який профіль працює на вашому сервері?
Одна назва приховує два стеки, три види секрету й різну поведінку під час зміни адреси. Розберіться з шарами, перш ніж порівнювати меню.
Ці дві назви стоять поруч у тому самому спадному списку, що схиляє до вибору між рівними. Вони не рівні. L2TP — це протокол тунелювання без власної конфіденційності, а захист у сервісі L2TP/IPsec походить від шару IPsec, що його обгортає. IKEv2 безпосередньо узгоджує IPsec-асоціацію і не має кроку «тунель у тунелі». Знання того, який стек пропонує ваш сервер, визначає профіль, запити й те, що станеться, коли ноутбук змінить мережу.
Два стеки, одна назва в клієнті
L2TP переносить сеанс «точка-точка» через UDP на порт 1701 і залишає шифрування тому, хто його обгортає. Поєднайте його з IPsec, і ви отримаєте два шари: IPsec-асоціацію, що захищає шлях, і всередині неї сеанс L2TP, який переносить кадри канального рівня користувача та автентифікацію PPP.
IKEv2 створює керівну асоціацію, а потім одну або кілька дочірніх асоціацій, що захищають трафік, — усе в одній родині обмінів на UDP 500 і 4500. Внутрішнього протоколу тунелювання та переговорів PPP немає.
Облікові дані: три секрети на трьох шарах
Саме тут зникає більша частина часу підтримки. Профіль L2TP/IPsec може запитати попередньо розділений ключ для шару IPsec і ім'я користувача з паролем для внутрішнього сеансу PPP, і те й те перевіряють різні компоненти. Спільний ключ належить шлюзу загалом, тож він нікого не ідентифікує; він лише доводить, що друга сторона знає секрет.
IKEv2 зазвичай використовує сертифікати або EAP з іменем користувача й паролем, а також може використовувати попередньо розділений ключ. Ці варіанти не взаємозамінні з парою L2TP. Скидання пароля, яке виправляє відхилений вхід через EAP, нічого не робить для простроченого клієнтського сертифіката, і скільки б разів ви не вводили пароль облікового запису заново, хибний ключ шлюзу це не задовольнить. Коли з'являється запит, якого ви не чекали, запитайте оператора, якому шару він належить, перш ніж гадати.
| Question | L2TP/IPsec | IKEv2 |
|---|---|---|
| What encrypts the traffic | A wrapping IPsec association | The child association |
| Ports you must permit | UDP 500/4500 and UDP 1701 inside | UDP 500 and 4500 |
| Typical secrets | Gateway PSK plus PPP credentials | Certificate, EAP, or PSK |
| Address change | Tunnel breaks, reconnect needed | Can migrate with MOBIKE |
Що змінює MOBIKE, а що ні
IKEv2 може перенести асоціацію на нову адресу, якщо обидва кінці підтримують MOBIKE, що охоплює випадок, коли ноутбук переходить із Wi-Fi у точку доступу телефона, не розриваючи асоціацію безпеки.
Це не зберігає життя кожному застосунку під час такого перенесення. Транспортний потік усе одно змінює адресу, сокети, прив'язані до старої, усе одно ламаються, а політика, що прив'язує трафік до інтерфейсу, усе одно може його відкинути. Перевірте перехід, який справді виконуєте, чи то вихід із мережі, пробудження зі сну або повернення після тривалого простою, і стежте за застосунком, а не за позначкою «Підключено».
Форми відмови, що їх розділяють
Профіль L2TP/IPsec, який доходить до шлюзу і зупиняється, зазвичай зазнає невдачі на одному з двох запитів: спільному ключі або облікових даних PPP. Хибний ключ зазвичай не показує в журналі клієнта нічого корисного, тоді як хибний пароль дає явну відмову автентифікації, і ця різниця каже вам, де шукати.
Профіль IKEv2 відмовляє раніше й гучніше, коли хибні ідентичність або сертифікат, бо керівна асоціація так і не завершується. Якщо асоціація завершується, а трафік усе одно не йде, проблема перемістилася в дочірню асоціацію, селектори трафіку або маршрут, і жодна зміна облікових даних не допоможе.
Де кожен ще доречний
L2TP/IPsec тримається, бо він є майже на кожному клієнті й не потребує додаткового програмного забезпечення, що важливо для підрядника на пристрої, яким ви не керуєте. Ціна — зайвий шар, модель спільного секрету й перепідключення після кожної зміни адреси.
IKEv2 краще пасує керованим пристроям: ідентичність за сертифікатом, чистіша мобільність і одна родина асоціацій, про яку треба думати. Він також відмовляє жорсткіше, коли клієнт старий, тож перевірте підтримуваний платформою метод автентифікації, перш ніж будувати навколо нього.
Перевірка виданого вам профілю
Спершу підтвердьте режим на боці сервера, потім виберіть клієнтський профіль, що йому відповідає. Перевіряйте з точним іменем хоста й обліковими даними, виданими для цього профілю, і переконайтеся в доступі до приватного ресурсу, а не до публічного сайту.
Якщо з'єднання встановлюється, а нічого не завантажується, тунель працює, а маршрут, DNS або селектор трафіку — ні. Зміна протоколу в цей момент перезапускає діагностику замість того, щоб просунути її.