Согласно многим документам, транспортный режим следует использовать в IPSec типа «хост-хост», в то время как туннелирование используется для подключения шлюзов, а L2TP — для удаленного доступа.
Но мне ничто не мешает использовать транспортный режим в шлюз-шлюз, верно? Один шлюз может прочитать ESP (или AH), удалить его и направить голый IP-пакет в свою сеть.
И я также могу использовать режим туннелирования между моим ПК и сервером базы данных. Вероятно, излишне оборачивать каждый пакет в отдельный UDP, но это можно использовать.
И я могу использовать чистый IPSec (без L2TP) для удаленного доступа, если я единственный пользователь на своем ПК. У меня не будет учета, настройки сети через IPCP и других вещей PPP, но это не всегда требуется.
В конце концов, L2TP можно использовать для соединения двух шлюзов;)
Итак, мой вопрос: почему все эти подходы существуют и дублируют друг друга? Почему транспорт IPSec все еще существует, если почти всегда его можно заменить на туннелирование и наоборот? Не могли бы вы привести пример ситуации, когда один из этих методов является «единственно правильным для использования»?
решение1
Почему транспорт IPSec все еще существует, если почти всегда его можно заменить на туннелирование и наоборот?
Я не вижу, чтобы транспортный режим IPSec использовался в общей популяции пользователей сетевых устройств сегодня. Я думаю, что он так и не набрал достаточного оборота для повсеместного развертывания. Поставщики программного обеспечения и сетей имели мотивацию продавать реализации туннельного режима (плюс обширные бэкэнды) корпоративным клиентам с потребностью в удаленном доступе, но не продвигали транспортный режим никому. Возможности могли существовать, но простота использования все еще оставляет желать лучшего.
Итак, он существует, но актуален ли он до сих пор? Транспортный режим исторически не был доступен большому количеству пользователей. Исключением были люди, работающие со свободным программным обеспечением.
История и статус внедрения оппортунистического шифрования для IPsec
Ссылка выше описывает исторические усилия по повсеместному использованию IPSec и то, как эти усилия были загнаны в угол. Причины можно обобщить как небезопасность инфраструктуры Интернета (то есть DNS) и относительное благодушие тех, кто был вовлечен в ее изменение.
почему все эти подходы существуют и дублируют друг друга?
Все эти подходы существуют в первую очередь из-за независимой идентификации и решения вариаций потребности в безопасном удаленном доступе, примерно в один и тот же период времени. Немного улучшенная версия вашего вопроса могла бы быть "почему все эти подходы все еще используются?"
Вы ответили на свой собственный вопрос о том, почему L2TP все еще используется: учет и настройка. (Возможно, будет интереснее рассмотреть, почему другие протоколы, такие как PPTP, больше не используются.) Во многих случаях, даже если вас не интересуют учет и настройка,
В других случаях ответ не так ясен. Возьмем случай шлюз-шлюз. Вы можете использовать чистый туннельный режим IPSec или использовать туннели GRE поверх IPSec (на самом деле, я считаю, что они поверх транспортного режима IPSec). Я не знаю, есть ли какие-либо преимущества в ту или иную сторону, кроме знакомства. Лично я никогда не настраивал туннельный режим IPSec на маршрутизаторе Cisco. Я всегда использовал зашифрованный GRE. Почему? Потому что все, что я знаю о простом GRE, применимо и к зашифрованному GRE. Так что мне это знакомо.
Не забывайте о VPN/туннелях уровня приложений, таких как OpenVPN или Secure Shell. Они, как правило, имеют худшую производительность, чем реализации на уровне ядра или устройства. Но они были (и есть) в целом проще в использовании и имели преимущество в виде более легкого прохождения через прокси и брандмауэры (по крайней мере, до появления глубокой проверки содержимого). Кроме того, у них часто меньше зависимостей; гораздо проще скомпилировать OpenVPN на старом сервере Linux, чем перекомпилировать ядро для поддержки IPSec.
Не могли бы вы привести пример ситуации, когда один из этих методов является «единственно правильным»?
В сетевых технологиях (как и во многом другом в вычислительной технике) вы никогда не увидите «единственно правильный вариант для использования». В большинстве случаев вы застреваете на том, что осуществимо. Например, все устройства Android работают с VPN на основе L2TP. Так что это осуществимо, даже если вам не нужна настройка или учет. Знакомство с туннелями GRE на устройствах Cisco делает их более простыми для меня в реализации, чем чистый туннельный режим IPSec. И я могу создать OpenVPN или туннель на основе SSH на старом сервере Linux, который я не могу обновить (по той или иной причине).
решение2
- Туннель IPsec против транспортного режима
- туннельный режим имеет больше накладных расходов
- транспортный режим работает только между хостами, поскольку оболочка не содержит дополнительного набора IP-адресов
- являются ли накладные расходы проблемой?
- представьте себе время, когда хосты устанавливают связь IPsec между собой до начала любого взаимодействия ** IPsec будет везде ** в туннельном режиме IP-адреса будут дважды в каждом пакете → пустая трата ресурсов