У меня есть действительно Трудно попытаться установить VPN-соединение с помощью туннеля GRE через IPsec. Проблема в том, что это связано с каким-то «кольцевым» соединением, которого я не понимаю, не говоря уже о возможности настройки, и единственная помощь, которую я смог найти, связана с настройкой маршрутизаторов Cisco.
Моя сеть состоит из маршрутизатора и одного хоста, на котором запущен Debian Linux. Моя задача - создать туннель GRE через инфраструктуру IPsec, который специально предназначен для маршрутизации многоадресного трафика между моей сетью, которую мне разрешено настраивать, и удаленной сетью, для которой у меня есть только форма, содержащая некоторую информацию о настройке (IP адреса и фазовая информация для IPsec). На данный момент достаточно установить связь между этим единственным хостом и удаленной сетью, но в будущем будет желательно, чтобы трафик направлялся на другие машины в моей сети.
Как я уже сказал, этот туннель GRE включает в себя "петлевое" соединение, которое я понятия не имею, как настроить. Из моего предыдущего понимания, петлевое соединение - это просто локальное псевдоустройство, используемое в основном для целей тестирования, но в этом контексте это может быть что-то более конкретное, о котором я не знаю.
Мне удалось правильно установить связь IPsec, используя racoon и ipsec-tools, и мне кажется, я знаком с созданием туннелей и добавлением адресов к интерфейсам с помощью ip, поэтому основное внимание уделяется шагу GRE. Хуже всего то, что удаленные узлы не отвечают на запросы ping, а отладка общей настройки очень затруднена из-за зашифрованного характера трафика.
Используются две пары IP-адресов: одна пара для однорангового соединения туннеля GRE и одна пара для части «обратной петли». Также задействован диапазон IP-адресов, который должен быть конечными IP-адресами для хостов внутри VPN.
Мой вопрос: как (или если) можно выполнить эту настройку? Нужно ли мне какое-то специальное программное обеспечение или другой демон, или ядро Linux обрабатывает все аспекты туннелирования GRE / IPsec?
Пожалуйста, сообщите мне, может ли быть полезна дополнительная информация.
Любая помощь приветствуется.
Еще раз, мне удалось решить проблему (но не так долго, как исходный вопрос и этот ответ предполагают, что это так :). Я провел почти месяц, исследуя решение проблемы, и я оставлю его здесь задокументированным на тот случай, если кто-нибудь столкнется с той же проблемой.
На самом деле, интерфейс обратной петли - это действительно то, что я знал: адрес, назначенный фиктивному, всегда активному интерфейсу на машине. Проблема с подключением между удаленным маршрутизатором GRE и моим маршрутизатором возникла из-за другой проблемы: Пакеты проверки активности GRE.
Оказалось, что удаленный маршрутизатор Cisco на самом деле отправлял мне нечетные пакеты, инкапсулированные в GRE, через туннель. Эти пакеты инкапсулированы другой GRE, а они, с другой стороны, несли номер протокола нуль. Быстрый просмотр показал, что эти пакеты Пакеты проверки активности GRE, которые отправляются периодически (в моем случае почти ровно каждые 10 секунд) и, если они правильно деинкапсулированы и перенаправлены одноранговым узлом, должны быть возвращены отправителю, так как самый внутренний адрес назначения содержал адрес отправителя.
Дело в том, что ядро Linux не отправило должным образом деинкапсулированный пакет keep-alive снова в цепочку маршрутизации. Если это так, пакет будет перенаправлен обратно отправителю без дальнейших осложнений. Вместо этого он доставил пакет в пользовательское пространство, так что можно было написать простую программу, которая прослушивала такие пакеты в необработанном режиме и возвращала их отправителю. Запустив эту программу и отправив обратно пару пакетов на маршрутизатор Cisco, туннель GRE на удаленной стороне «поднялся», маршрутизаторы PIM обменялись hellos, и я наконец смог прослушать многоадресный трафик, который я ожидал услышать.
Я многому научился из этого опыта, особенно в той части, что при использовании непонятных протоколов (или, по крайней мере, непонятных протоколов функции), вы не можете просто рассчитывать на взаимное знание. Ни один сетевой аналитик на удаленной стороне не мог мне помочь ни в каком аспекте в этом отношении, вероятно, потому, что это поведение не было задокументировано.
Я не уверен, как работает многоадресная рассылка, но могу рассказать вам, как у меня работает GRE поверх IPSec. Большинство установок Linux поддерживают gre, поэтому вам не нужно для него ничего устанавливать.
Я создал туннель IPSec Host-to-Host, а затем выполнил шаги, упомянутые здесь, чтобы создать туннель. http://lartc.org/lartc.html#LARTC.TUNNEL.GRE
Не забудьте включить пересылку пакетов :)