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 или селекторът на трафик не. Смяната на протокола в този момент рестартира диагностиката, вместо да я придвижи.