Туннель GRE по IPsec с обратной петлей
Согласно стандарту, первые три октета являются идентификатором поставщика (Вы уже знаете, что :)) и поставщик свободен выбрать последние, как им нравится (но они должны быть уникальными),
Поэтому, даже если некоторые поставщики действительно используют определенный октет для установки флага беспроводных устройств (который, скорее всего, они не делают), Вы не должны полагаться на это, поскольку поставщики не обязаны уважать ту конвенцию.
Еще раз мне удалось чинить через проблему (но не слишком долго как исходный вопрос, и этот ответ предполагает, что это :). Я был в течение почти месяца, исследовав решение для проблемы, и я оставлю зарегистрированным здесь на всякий случай, любой, оказывается, наталкивается в той же проблеме.
На самом деле петлевой интерфейс действительно, чем я знал, что это было: адрес, присвоенный макету, всегда взаимодействуйте через интерфейс на машине. Проблема возможности соединения между удаленным Маршрутизатором GRE и моим маршрутизатором происходила из-за другой проблемы: GRE активные пакеты.
Оказалось, что удаленный маршрутизатор Cisco на самом деле отправлял мне нечетные GRE-инкапсулированные-пакеты через туннель. Эти пакеты инкапсулировали другой пакет GRE, и они, с другой стороны, несли номер протокола нуля. Быстрый обзор указал, что эти пакеты являются активными пакетами GRE, которые являются, периодически отправляют (в моем случае, каждые 10 секунд почти точно) и, если правильно deencapsulated и перенаправленный одноранговым узлом, должен отреагироваться к отправителю, так как самый внутренний адрес назначения содержал исходный адрес отправителя.
Факт - то, что ядро Linux правильно не подавало deencapsulated активный пакет снова в цепочку маршрутизации. Если бы это сделало, то пакет был бы перенаправлен назад к отправителю без дальнейших сложностей. Вместо этого это поставило пакет пространству пользователя, так, чтобы было возможно записать простую программу, которая слушала такие пакеты в режиме без предварительной обработки и повторила их назад к отправителю. Запуская эту программу и реагирующий на несколько пакетов к маршрутизатору Cisco, туннель GRE пошел на удаленной стороне, маршрутизаторы PIM, которыми обмениваются hellos и я наконец мог слушать многоадресный трафик, который я ожидал слушать.
Я много учился на этом опыте, особенно часть, которую, при питании с неясными протоколами (или, по крайней мере, неясные функции протокола), Вы не можете просто считать вообще на знание однорангового узла. Никакой аналитик единой сети на удаленной стороне не мог помочь мне ни в каком аспекте в этом отношении, вероятно, потому что это поведение было не документировано.
Я не уверен, как многоадресно переданные работы, но я могу сказать Вам, как я получил GRE по работе IPSec. Большинство установок Linux поддерживает gre, таким образом, Вы не должны были бы устанавливать ничего дополнительного для него.
Я создал туннель Host-to-Host IPSec и затем выполнил шаги, упомянутые здесь для создания туннеля. http://lartc.org/lartc.html#LARTC.TUNNEL.GRE
Не забудьте включать пакетную передачу :)