[РЕШЕНО] PPPoE через EoIP: странное явление.

Возможно, у меня была такая же проблема, и после некоторых тестов я выяснил, что она возникает только при наличии нескольких интерфейсов в бридже. Допустим, клиент подключен через wlan1, а выходной интерфейс – ether1. Просто добавь интерфейсы wlan1 и EoIP в бридж, и все должно работать нормально. (IP, конечно, назначен на ether1) Полагаю, это баг.

Уже настроено именно так. Есть ещё какие-нибудь идеи?

Ребята, реально ни у кого нет возможности помочь Скорчу с нашей проблемой? Если нужны подробности - вот они:

Текущая ситуация: У нас настроена простая сетевая мостовая сеть с подсетью /24, которая является основой нашей сети. IP-адреса основной подсети находятся на интерфейсах моста каждого маршрутизатора.

Наш "остов" (backbone) работает отлично, и все машины в мостовой сети могут пинговать и подключаться по telnet/ssh друг к другу без каких-либо проблем.

```text
       ethernet     Wireless(EoIP)     ethernet     Wireless(EoIP)     Wireless(EoIP)
core_mz----------mz1~~~~~~~~~~~~~~~~sh1----------sh2~~~~~~~~~~~~~~~~ap1~~~~~~~~~~~~~~~~ap2
                                                                    |                  |
                                                                    |____add. EoIP_____|
```

У нас есть центральный маршрутизатор (core_mz), подключенный к интернету, и несколько других маршрутизаторов, подключенных к этому маршрутизатору через нашу мостовую сеть (см. схему выше).

У нас есть два доступа пункта (ap1 и ap2) на удаленных площадках, и наши клиенты подключаются по pppoe. Оба AP подключены к мостовой сети и дополнительно связаны EoIP туннелем (без IP-адресов на интерфейсе туннеля).

PPPoE сервер в данный момент НЕ находится на нашем центральном маршрутизаторе, а на ap1. PPPoE соединения от клиентов, подключенных к ap2, перебрасываются через дополнительный EoIP туннель к ap1, где расположен PPPoE сервер.

У нас есть частная сеть для наших клиентов, которая NAT'ится на общий публичный IP.

Все это работает отлично.

\
\
**Планируемое:**
~~~~~~~~

Теперь мы хотим предоставить нашим клиентам публичные IP-адреса без необходимости маршрутизации публичной сети через нашу основную инфраструктуру. Поэтому нам нужно перенести PPPoE сервер с удаленной площадки (ap1) на наш центральный маршрутизатор (core_mz).

Но именно здесь у нас возникает **проблема с EoIP туннелем**:
Мы попытались настроить такую же конфигурацию, как с ap2 и ap1 (дополнительный EoIP туннель без IP-адреса), на этот раз между ap2 и core_mz.

```text
       ethernet     Wireless(EoIP)     ethernet     Wireless(EoIP)     Wireless(EoIP)
core_mz----------mz1~~~~~~~~~~~~~~~~sh1----------sh2~~~~~~~~~~~~~~~~ap1~~~~~~~~~~~~~~~~ap2
  |                                                                                    |
  |_________________________________additional EoIP____________________________________|
```

Но оно просто не работает так, как мы ожидали:
- PADI пакеты от клиента, подключенного к ap2 через ethernet, доставляются в core_mz нормально.
- Core_mz затем правильно отвечает с PAD0, адресованным MAC-адресу ethernet клиента.

Но PAD0 никогда не доходит до клиента. Он, однако, достигает ap2.

Похоже, что ap2 делает что-то очень плохое с нашими маленькими PAD0 пакетами. Прилагаю файлы захвата пакетов (ap2_ether2.cap, ap2_bridge.cap, ap2_eoip.cap, core_mz_eoip.cap).

Если кому-то покажется, что EoIP не работает (именно так я сначала думал) - я попытался подключиться к EoIP туннелю напрямую с AP2... заработало как по маслу. Значит, EoIP настроен правильно.
\
\
Техническая информация о конфигурации (только релевантные части) приведена ниже:

```text
core_mz:
-------
interface eoip> print
5  R name="EoIP -> ap2" mtu=1500 mac-address=00:00:5E:80:13:37
     arp=enabled remote-address=172.16.1.205 tunnel-id=31337

interface bridge port> print
12 EoIP -> ap2 none         128      10

interface pppoe-server server> print
2   service-name="FRED PPPoE Test" interface=EoIP -> ap2
    max-mtu=1492 max-mru=1492 authentication=pap,chap,mschap1,mschap2
    keepalive-timeout=10 one-session-per-host=no max-sessions=0
    default-profile=fred_testprofil_oeffentliche_ips_statisch
```
\
<br>
```text
AP2:
---
interface eoip> print
4  R name="EoIP -> core_mz" mtu=1500 mac-address=00:00:5E:80:13:38
     arp=enabled remote-address=172.16.1.249 tunnel-id=31337

interface ethernet> print
1  R ether2                                 1500  00:0D:B9:01:82:D5 enabled

interface bridge> print
3  R name="PPPoE Bridge -> core_mz" mtu=1500 arp=enabled
     mac-address=00:00:5E:80:13:38 stp=no priority=32768 ageing-time=5m
     forward-delay=15s garbage-collection-interval=5s hello-time=2s
     max-message-age=20s

interface bridge port> print
1 ether2                  PPPoE Bridge -> core_mz 128      10      
8 EoIP -> core_mz         PPPoE Bridge -> core_mz 128      10
```
\
<br>
```text
PPPoE-Client connected to ether2 at AP2:
---------------------------------------
debian linux machine connected directly to ether2 (10mbit half-duplex)
eth0:
mac=00:50:BA:33:91:6C
```

Файлы захвата пакетов с ap2 и core_mz во время попытки установить PPPoE соединение от клиента, подключенного к ether2 на ap2 к core_mz (только MAC-адрес, без IP):
[ap2_ether2.cap](http://www.juchart.de/omnidat/ap2_ether2.cap)
[ap2_bridge.cap](http://www.juchart.de/omnidat/ap2_bridge.cap)
[ap2_eoip.cap](http://www.juchart.de/omnidat/ap2_eoip.cap)
[core_mz_eoip.cap](http://www.juchart.de/omnidat/core_mz_eoip.cap)
\
\
Будем очень благодарны, если кто-нибудь сможет нам помочь с этим!

Спасибо за ответ! Вот что я выяснил о моих маленьких друзьях PADI/PAD0: Как видно из файлов захвата, которые я прикреплял в предыдущем сообщении, PADI проходит напрямую от клиента к core_mz. Возвращающийся PAD0 корректно принимается на интерфейсе EoIP в ap2, но затем неожиданным, каким-то магическим образом преобразуется: На интерфейсе EoIP (ap2_eoip.cap): PADI от src MAC 00:50:ba:33:91:6c (это мой клиент) идёт на broadcast MAC.

PAD0 от src MAC 00:00:5e:80:13:37 (это core_mz) с адресом назначения 00:50:ba:33:91:6c приходит через EoIP туннель в ap2. До сих пор все хорошо… Затем происходит что-то странное на интерфейсе Bridge (ap2_bridge.cap): PADI проходит нормально, как и на интерфейсе EoIP, но
PAD0 от src MAC 00:00:5e:80:22:05 (это backbone интерфейс ap2, где *точно* не запущено PPPoE и который даже не входит в эту группу bridge!) с адресом назначения 01:cd:2f:3e:ba:a9 просто совершенно неправильный. Во-первых, MAC-адрес источника неправильный, во-вторых, MAC-адрес назначения тоже неправильный. Я даже не знаю, какому роутеру принадлежал бы этот MAC-адрес: я проверил все роутеры, но не нашел соответствующего интерфейса. Единственный интерфейс, MAC-адрес которого был достаточно близок, – это ethernet интерфейс на core_mz с 00:11:2F:3E:BA:A9. Но первые два байта не совпадают, и как бы ты ни говорил: правильный PAD0 *действительно* дошёл до ap2! Он просто каким-то образом искажается на bridge… После этого как минимум понятно, почему мой клиент с MAC 00:50:ba:33:91:6c никогда не видит пакет PAD0 - он просто не предназначен для моего клиента! Но: как вообще такое может произойти??? Я уже пытался удалить bridge, интерфейс EoIP и начать настройку с нуля (хотя и не сбрасывал конфигурацию устройства) – ничего не получилось. Не помогло вообще. Может быть, я сброшу конфигурацию устройства и начну установку MT с нуля…

Мы уже проверяли это на другом роутере/AP, который подключен через Ethernet-кабель к gw-core. ARP включен на всех устройствах и бриджах. Перезагружали по много раз, но эффекта нет. Думаю, нужно стереть конфигурацию на обоих (а потом и на всех) системах и перенастроить их. Надеюсь, получится сделать это с помощью export/import (а не backup/restore).

Огромное спасибо за твои советы!!!

Ну… на самом деле, проблема не была решена перенастройкой роутера с нуля. И это не была проблема обновления. Мы выяснили, что как только физический интерфейс ниже EoIP сам находится в группе мостов, EoIP больше не работает так, как ожидалось. Если убрать физический интерфейс из группы мостов – всё просто работает (после того, как правильно настроите маршрутизацию). Пришлось перестраивать всю нашу сеть с мостовой на маршрутную, чтобы использовать EoIP-туннели в качестве транспорта для PPPoE-сессии. Если вам интересно узнать детали – спрашивайте.