Дозволити трафік через брандмауер до динамічної адреси IPv6


7

Припустимо, у мене зараз ця конфігурація на IPv4:

Мій маршрутизатор (скринька Linux) підключений до Інтернету на eth0 та до моєї локальної мережі на eth1. Я хочу переслати порт 80 на 10.1.2.3. Ось як я зараз це робив:

iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to 10.1.2.3 iptables -A FORWARD -m conntrack --ctstate DNAT -j ACCEPT

Тепер я хочу зробити еквівалент на IPv6. Припустимо, у мене така ж конфігурація, як і раніше, з цими змінами:

Мій провайдер надає моєму маршрутизатору діапазон 2001: db8: aaaa :: / 64 через делегування префікса. Мій маршрутизатор приймає 2001: db8: aaaa :: 1 для себе на eth1 і передає 2001: db8: aaaa :: 123 хосту, який я хочу, щоб порт 80 був відкритий.

NAT більше не потрібен у випадку IPv6, тому все, що мені потрібно, - це правило брандмауера, щоб дозволити трафік. Ось правило, про яке я можу зробити це:

ip6tables -A FORWARD -i eth0 -d 2001:db8:aaaa::123 -p tcp -m tcp --dport 80 -j ACCEPT

Проблема, з якою я маю це, полягає в тому, що мені довелося вставити жорсткий код 2001: db8: aaaa :: 123 в моє правило брандмауера, а префікс 2001: db8: aaaa :: може змінюватися за примхою мого провайдера. У світі IPv4 єдиний IP, який мені довелося жорстко кодувати, - це внутрішній, тому я знав, що він ніколи не зміниться з-під мене. Чи можна дозволити такий трафік, не змінюючи правило щоразу, коли мій провайдер змінює делегований префікс? (Якщо pf може робити те, що я хочу, але ip6tables не може, я б готовий перейти на BSD для цього.)


Зворотний зв'язок, тому що якщо ви не починаєте з IPv6 адреси, в першу чергу є відключення протоколу.
SDsolar

1
@SDsolar Я не впевнений, що ти маєш на увазі.
Йосиф Сибл

Відповіді:


0

Хоча немає спеціального варіанту, ви можете використовувати загальний u32модуль iptables (див. Iptables-розширення ), щоб відповідати лише частині ідентифікатора інтерфейсу (який завжди починається з байта 32 заголовка IP):

-A FORWARD -m u32 --u32 "32 = 0x11223344 && 36 = 0xAABBCCDD" -j ACCEPT

Це відповідатиме будь-якій адресі призначення, що закінчується :1122:3344:aabb:ccdd.

У заголовках IPv6 адреса джерела починається з байту 8 (мережа в 8, інтерфейс у 16); адреса призначення - 24 (мережа в 24, інтерфейс у 32). Ви можете використовувати бітові операції і для реалізації таких речей, як CIDR-маска u32.


Це разом з DHCPv6, щоб отримати передбачувані локальні адреси. Зрештою, SLAAC може робити все, що завгодно.
Даніель Б

Так може DHCPv6. Немає правила, що говорить, що сервер DHCP не може видавати 15-хвилинну оренду і негайно забувати про них наступного дня.
grawity

Так, звісно. Однак вирішує саме сервер DHCP, а не клієнт. У цьому плані це "передбачувано".
Даніель Б

4
Не можу я просто використати синтаксис? -А ЗАПУСК -d :: 1122: 3344: aabb: ccdd / :: ffff: ffff: ffff: ffff -j ACCEPT "для цього я зробив швидкий тест і, здається, це робиться те саме, що і ваше рішення. Крім того, це рішення означає, що зараз я взагалі ігнорую мережеву частину. Чи не може це стати проблемою, якщо вона в кінцевому підсумку відповідає чимось на зразок багатоадресної або приватної адреси, яка має те саме закінчення?
Йосиф Сибл

2
@JosephSible: Ви все ще можете опублікувати його як відповідь, щоб він виділявся, і перелічував там всі недоліки - відповіді не повинні бути ідеальними, тому є місце для більш ніж однієї відповіді! Я думаю, що для найпоширеніших ситуацій (наприклад, домашніх мереж) ваше рішення працюватиме чудово, тому що ви можете переслати більше трафіку, ніж ви очікуєте, але, ймовірно, не буде жодних хостів, які слухатимуть ці додаткові IP-адреси. Якщо є проблеми з цим рішенням, відповідь - чудове місце, щоб перерахувати їх усіх на користь кожному!
Malvineous
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.