Вопрос или проблема
Следующие правила ip6tables:
# ip6tables -t nat -L -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT all eth0 any anywhere 2001:470:4a71:f170::/64 to:fdde:ad00:beef:0:91f5:6dd4:e66f:cf5b
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 19 packets, 1936 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 19 packets, 1936 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all any eth0 fdde:ad00:beef::/64 anywhere
0 0 MASQUERADE udp any eth0 fd11:22::/64 anywhere
0 0 MASQUERADE tcp any eth0 fd11:22::/64 anywhere
Я вижу, что пакеты выходят через eth0 с использованием tshark. Вот один пример пакета (получен на интерфейсе wpan0):
221 480.196225356 fd11:22::703c:ef83:a03d:7e1b ? 2600:1f1c:c93:da00:76c2:1dbd:72c2:d063 TCP 94 [TCP Retransmission] 49998 ? 50000 [SYN] Seq=0 Win=9 Len=0 MSS=474 WS=1 SACK_PERM=1 TSval=2889901 TSecr=0
Я хочу, чтобы эти пакеты проходили через фильтр MASQUERADE, чтобы их исходные адреса были изменены на IPv6-адрес хоста в ethernet (eth0). Однако это не происходит, несмотря на то, что я ожидал, что пакеты будут соответствовать правилам ip6tables. На самом деле, пакет даже не соответствует никаким правилам MASQUERADE (как видно по счетчику pkts). Я не уверен, как это отлаживать — кто-нибудь знает, почему эти пакеты не проходят masquerade?
Что я пробовал:
- Удалить все записи
conntrack:conntrack -f ipv6 -D - Перезагрузить машину.
Спасибо за вашу помощь!
Редактировать:
Вот еще более полезный вывод:
# ip6tables-save -c
# Generated by ip6tables-save v1.6.0 on Sun Sep 2 11:44:06 2018
*filter
:INPUT ACCEPT [1812:134308]
:FORWARD ACCEPT [22:1760]
:OUTPUT ACCEPT [1782:210084]
COMMIT
# Completed on Sun Sep 2 11:44:06 2018
# Generated by ip6tables-save v1.6.0 on Sun Sep 2 11:44:06 2018
*nat
:PREROUTING ACCEPT [1:137]
:INPUT ACCEPT [1:137]
:OUTPUT ACCEPT [41:5757]
:POSTROUTING ACCEPT [41:5757]
[0:0] -A PREROUTING -d 2001:470:4a71:f170::/64 -i eth0 -j DNAT --to-destination fdde:ad00:beef:0:91f5:6dd4:e66f:cf5b
[0:0] -A POSTROUTING -s fdde:ad00:beef::/64 -o eth0 -j MASQUERADE
[0:0] -A POSTROUTING -s fd11:22::/64 -o eth0 -p udp -j MASQUERADE
[0:0] -A POSTROUTING -s fd11:22::/64 -o eth0 -p tcp -j MASQUERADE
COMMIT
# Completed on Sun Sep 2 11:44:06 2018
# ip -6 link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether b8:27:eb:96:eb:75 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether b8:27:eb:c3:be:20 brd ff:ff:ff:ff:ff:ff
4: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 06:8a:53:01:68:f2 brd ff:ff:ff:ff:ff:ff
5: wpan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 500
link/none
# ip -6 -brief address
lo UNKNOWN ::1/128
eth0 UP 2001:470:4a71:f000::11/64 fe80::ba27:ebff:fe96:eb75/64
wpan0 UNKNOWN fdde:ad00:beef:0:cc1e:c6e2:8252:e44b/64 fd11:22::1c4d:925:de45:9d30/64 fe80::1c4d:925:de45:9d30/64 fe80::2ccb:f19:edce:c49e/64
# ip -6 route
2001:470:4a71:f000::/64 dev eth0 proto kernel metric 256 pref medium
fd11:22::/64 dev wpan0 proto kernel metric 256 pref medium
fdde:ad00:beef::/64 dev wpan0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev wpan0 proto kernel metric 256 pref medium
default via 2001:470:4a71:f000::1 dev eth0 metric 1024 pref medium
Оказалось, это из-за неправильной контрольной суммы TCP (в стэке TCP хоста была ошибка). Видимо, tshark не показывает это по умолчанию, но именно это не позволяло ip6tables сделать masquerade исходного адреса.
Спасибо всем за попытки помочь. Относительно предложения kasperd, оказалось, что похожее решение работает в моей ситуации (у меня /60, а не /48), так что я постараюсь отказаться от ip6tables.
Исправлено: настройка теперь работает без NAT. Спасибо за предложение.
У меня была та же проблема. Решение оказалось простым, достаточно выполнить:
ip6tables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Проблема в том, что код ip6tables не загружает модуль conntrack по умолчанию, поэтому правила statefull не работают.
А для тех, кто говорит, что “IPv6 не нуждается в NAT!” – иногда он ДЕЙСТВИТЕЛЬНО нужен, например, если вы хотите запустить контейнеры Docker на AWS. Он не поддерживает DHCP PD, поэтому приходится использовать NAT.
Ответ или решение
Вопрос о том, почему ip6tables не выполняет маскарадинг исходного адреса, является весьма актуальным для специалистов в области информационных технологий, особенно в контексте использования IPv6. Чтобы понять и решить данную проблему, важно проанализировать детали конфигурации и поведения сетей в вашем окружении.
Теория
Маскарадинг использует таблицы NAT (Network Address Translation), чтобы заменить исходный IP-адрес в пакете при его отправке. Это особенно актуально для сценариев, где необходимо перенаправление трафика через общедоступный интерфейс, не раскрывая внутренние адреса сети.
Когда рассматриваются правила ip6tables -t nat -L -v, важно помнить, что технология маскарадинга работает в контексте цепочки POSTROUTING, которая применяет изменения к пакетам, готовым к выходу из системы. Причина того, почему ваши пакеты не проходят через маскарадинг, может заключаться в неправильной конфигурации правил, отсутствии совместимости с conntrack или проблемах с проверкой контрольных сумм в стеке TCP.
Пример
На основании предоставленных данных, проблема может быть связана с несколькими аспектами:
-
Проблемы с
conntrack:conntrack— это модуль, который отслеживает состояния соединений. Если он не загружен или неправильно сконфигурирован, маскарадинг может не работать. -
Некорректные контрольные суммы: Если контрольные суммы TCP неисправны,
ip6tablesможет игнорировать такие пакеты. -
Проверка правил: Возможно, правила
ip6tablesнастроены таким образом, что пакеты не удовлетворяют условиям для маскарадинга.
Применение
Шаги по устранению проблемы:
-
Проверка модуля
conntrack: Убедитесь, что модульconntrackзагружен и работает корректно с IPv6. Добавление правилаip6tables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTможет помочь в отслеживании соединений, что позволит правиламip6tablesработать более предсказуемо. -
Диагностика ошибок TCP: Используйте инструменты анализа, такие как
tshark, с опцией проверки контроля сумм, чтобы увидеть, есть ли проблемы с исходными пакетами. Если контрольные суммы ошибочны, попробуйте обновить или исправить ваш стек TCP. -
Обновление конфигурации правил: Убедитесь, что правила, используемые для маскарадинга, действительно применимы к нужным пакетам. Например, учитывайте правильные указания интерфейсов и диапазонов адресов. Вы можете обновить их на основании актуальных данных о сетевых интерфейсах и маршрутизации.
Альтернативные решения:
В некоторых случаях NAT может быть заменен другими подходами, такими как использование /60 или /48 префиксов, если ваша сеть позволяет это сделать. Такие стратегии требуют изменения архитектуры сети, но могут существенно упростить управление и уменьшить зависимость от маскарадинга.
Заключение
Хотя IPv6 обеспечивает достаточно адресного пространства, чтобы уменьшить необходимость в NAT по сравнению с IPv4, существуют ситуации, где его использование может быть все еще необходимо. Проблемы с ip6tables часто связаны с неправильными конфигурациями или техническими ограничениями, которые могут быть решены тщательной диагностикой и корректировкой правил. Всегда важно проверить модульную поддержку, например conntrack, и удостовериться в правильности всех сетевых конфигураций, чтобы ваша сеть функционировала надежно и эффективно.