Вопрос или проблема
Я экспериментирую с маршрутизацией и сейчас столкнулся с проблемой, которую не могу решить самостоятельно.
eth0
|
|
|
------------------------ br0 ------------------------
| (192.168.100.1) |
| |
| |
| |
lxc_vpn_eth0 lxc_test_eth0
(192.168.100.120) (192.168.100.130)
|
|
tun0
Я хочу отправить некоторые пакеты (UDP) из LXC-контейнера (test) в другой LXC-контейнер (vpn), и оттуда через OpenVPN, запущенный внутри этого контейнера. Это работает, но как-то ядро отмечает ответные пакеты как марсианские и удаляет их с моста br0.
Я проверял с помощью tcpdump во всех трех “местах”, через которые проходят пакеты, и вот результаты:
(в контейнере vpn)
#tcpdump -i eth0
21:25:12.043321 IP 192.168.100.1.55081 > XX.YY.UU.VV.6969: UDP, length 16
21:25:12.097040 IP XX.YY.UU.VV.6969 > 192.168.100.1.55081: UDP, length 16
Как вы видите, я маскирую пакеты на tun0.
Так что пакеты из контейнера test приходят в контейнер vpn, выходят через tun0, и я получаю ответ. Но как только этот ответный пакет оказывается на мосту, я получаю это в системных логах:
kernel: [c0] IPv4: марсианский источник 192.168.100.120 от XX.YY.UU.VV, на устройстве br0
Как я должен настроить маршрутизацию, чтобы ответный пакет не блокировался? Он должен уже находиться на мосту, где контейнер с IP 192.168.100.120 находится, и ждет его…
Заранее благодарю за помощь, буду рад предоставить вам дополнительную информацию… (я не хотел размещать все таблицы маршрутизации, потому что не хотел заполнять постинг, возможно, ненужной информацией)
Извините за этот вопрос …
После часов анализа трафика, отслеживания пакетов и множества попыток и ошибок я заметил, что маскировал пакеты на br0… Я, вероятно, сделал это, потому что с контейнерами есть 2 компьютера на аппаратном коммутаторе, который нуждался в маршрутизации на eth0. В любом случае, это вызвало странные заголовки источников в пакетах…
Маскируя трафик на eth0 вместо br0, мне удалось решить эту проблему.
Поделюсь своим опытом здесь, так как это был один из первых результатов поиска в Google.
Для меня проблема заключалась в zeroconf/avahi, активированном на моем сервере/роутере, который добавлял маршруты для интерфейсов, участвующих в мосте. Я думаю, это все путало.
Следующее решило проблему:
dpkg --remove avahi-autoipd
Я нашел ответ здесь:
https://superuser.com/questions/950751/how-to-turn-off-zeroconf-in-ubuntu
Ответ или решение
Теория
Когда мы говорим о маршрутизации в сетях, важно понимать, как пакеты проходят через различные сетевые интерфейсы и как каждый интерфейс и устройство работают вместе. В контексте вашего вопроса, у вас есть несколько сетевых интерфейсов и мостов, которые связывают различные контейнеры и обеспечивают передачу пакетов.
Мост (bridge): Это сетевой механизм, который соединяет несколько сетевых сегментов, позволяя им действовать как один, тем самым облегчая передачу пакетов между различными сетями или устройствами.
Маршрутизация (routing): Процесс передачи пакетов данных от одной сети к другой или через различные устройства в сети.
Пакеты Martian: Это пакеты, у которых неправильные или неожиданные исходные или целевые IP-адреса. Они могут быть идентифицированы как пакеты, пришедшие с приватных адресных пространств из внешних источников, или же могут быть просто неправильно адресованы из-за конфигурации сети.
Пример
В вашем случае, проблема заключалась в неправильном маскарадинге пакетов на мосте br0, что приводило к тому, что исходные IP-адреса в заголовках пакетов становились некорректными. Рассмотрим пример, когда пакет поступает с IP-адресом, который считается "марсианским":
Вы отправляете UDP-пакеты контейнера lxc_test_eth0 на IP-адрес контейнера lxc_vpn_eth0. Когда пакет достигает VPN-контейнера и отправляется наружу через интерфейс tun0, он становится источником с публичным IP-адресом. Когда ответный пакет возвращается из сети, он снова проходит через интерфейс tun0 в VPN-контейнере. После этого, этот пакет должен быть перенаправлен обратно к контейнеру lxc_test_eth0. Однако, в процессе, система обрабатывает его как "марсианский" из-за неправильных заголовков, до этого образованных на br0. Это происходит вследствие маскарадинга — NAT-процесс уже изменил IP-адрес, и когда пакет проходит через br0, система видит не то, что ожидает.
Применение
Чтобы избежать подобных ошибок в будущем, вместо маскарадинга на уровне бриджа br0, вы должны применять NAT (маскарадинг) на более высоком уровне, ближе к реальной точке выхода и входа из сети (то есть на eth0). Это гарантирует, что все пакеты, которые проходят от контейнеров через мост, не изменяют свои исходные IP-адреса неуместно.
Также важно удостовериться, что все маршруты и посторонние службы, такие как Zeroconf/Avahi, не вмешиваются в маршрутизацию. Оно иногда может создавать дополнительные маршруты или изменять поведение сети, что приводит к таким аномальним проблемам. Если вы используете автоматическую конфигурацию IP, такую как Avahi, убедитесь, что она настроена правильно или даже отключена, чтобы предотвратить конфликты.
Удаление Avahi может помочь, если сбор и назначение маршрутов программой происходят некорректно. Как показано в примере, команда dpkg --remove avahi-autoipd может убрать подобное вмешательство, если оно вас беспокоит.
Заключение
В каждом случае, когда мы ведем дело с комплексной сетевой структурой, такой как комбинация мостов и контейнеров, важно обеспечить правильный процесс NAT и управление маршрутизацией, а также устранить влияние автоматически создаваемых маршрутов и служб. Это позволит обеспечить стабильную и безопасную передачу пакетов без неправильных пометок и потерь.