Хост iptables лише через VPN: назвіть пристрій tun, а не tun+

tun+ відповідає кожному тунелю на машині. Закріпіть одну назву пристрою, поставте виняток для endpoint першим і зберігайте шлях відновлення, поки перевіряєте політику.

Написати -o tun+ здається точною інструкцією, а насправді це шаблон, що відповідає кожному тунелю в ядрі. Другий клієнт VPN, міст контейнерів або інтерфейс, залишений сеансом, що впав, — усі вони задовольняють його, і хост починає пропускати трафік, який політика мала не пустити. Процедура нижче закріплює одну назву пристрою, вибудовує винятки так, щоб тунель справді міг піднятися, і залишає шлях назад, якщо правила ляжуть невдало. Кожен крок досить короткий, щоб скасувати його окремо.

Крок 1: запишіть правила, які є зараз

Перш ніж змінювати типову політику, збережіть поточний стан, щоб відкат був командою, а не спогадом. iptables-save > /root/iptables.pre записує кожну таблицю у файл, який можна відновити, а другий термінал з відкритим root-сеансом — не параноя, коли задавана політика рве з'єднання, яке її несе. Якщо ви працюєте віддалено, заплануйте ще й flush як аварійний вимикач.

Потім перелічіть інтерфейси, бо ім'я, яке ви припустили, — це ім'я, яке слід було прочитати: ip -br link показує, що є прямо зараз, а тунель з'явиться лише після підняття. Записуйте назви пристроїв у міру читання.

Крок 2: дайте тунелю власну назву

OpenVPN приймає dev tun_work у конфігурації клієнта, і тоді Linux створює інтерфейс саме з цим ім'ям замість того, щоб виділяти tun0. Ім'я залишається стабільним між перепідключеннями, поки ніщо інше на нього не претендує, і саме це робить правило, що називає пристрій, осмисленим.

Там, де ім'ям не можна керувати, зіставляйте натомість адресу тунелю або мітку пакета. Обидва варіанти працюють, обидва важче читати, і обидва тихіше відмовляють, коли тунель перенумеровується. У будь-якому разі зіставляйте одну річ і прямо скажіть, яку.

Крок 3: напишіть політику, поставивши виняток для endpoint першим

Хост лише через VPN — це хост із забороною за замовчуванням і коротким списком винятків, і найважливіший виняток — той, що дозволяє тунелю існувати. Будуйте його в цьому порядку, з правилом для endpoint перед правилом для пристрою тунелю, щоб рукостисканню було куди йти:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Буквальна адреса endpoint і порт належать вашому постачальнику, а не цій сторінці. Якщо endpoint — ім'я хоста, розв'яжіть його один раз і закріпіть результат, бо правило не вміє шукати ім'я, а змінна відповідь мовчки зламає політику після наступної зміни DNS. Перевірте й порт, бо постачальники, які переводять вас на TCP 443, інакше вимагатимуть правила, якого ніхто не записав. Тунель, що працює лише за одним протоколом, зазвичай і є цим пропуском, а не несправністю міжмережевого екрана.

На маршрутизаторі та сама форма йде в ланцюжок FORWARD для клієнтів за ним, а власному трафіку маршрутизатора потрібні власні правила. Набір правил, що покриває лише переслані пакети, залишає SSH і DNS на старому шляху, і саме так маршрутизатор стає недоступним у момент, коли тунель піднімається.

Крок 4: перевірте порядок, а не лише наявність

Правила оцінюються по порядку, тому ACCEPT, що стоїть раніше, просто приховує REJECT, доданий після. Зіставлення established і related дозволяє відповідям на ваші власні вихідні запити повертатися, не відкриваючи загальний вхідний шлях, а розміщення його після прийняття тунелю означає, що тунель, який упав, усе ще пропускає зворотний трафік на своєму інтерфейсі.

Тримайте кількість правил достатньо малою, щоб прочитати їх на одному екрані. Набір правил, який ви не можете перевірити аудитом, — це той, який ви будете латати, додаючи винятки згори, і саме так політики заборони за замовчуванням поступово набувають краю дозволу за замовчуванням. Порахуйте ACCEPT до і після зміни.

Крок 5: зробіть так, щоб він пережив завантаження і родину адрес

Правила, введені вручну, зникають під час перезавантаження, тому завантажуйте їх зі служби міжмережевого екрана дистрибутива або з unit, який запускається після появи інтерфейсу тунелю. Посилання на tun_work у скрипті, що виконується до старту OpenVPN, — поширений спосіб отримати цикл завантаження зі скинутим трафіком.

Потім перевірте IPv6 окремо, бо добра політика заборони за замовчуванням для IPv4 нічого не говорить про іншу родину. ip -6 route покаже, чи має хост маршрут, який міг би нести трафік в обхід тунелю, що обробляє лише IPv4, а ip6tables або nftables потребують власних еквівалентних правил. Тестуйте з призначенням IPv6-only, а не покладайтеся на симетрію набору правил.

Крок 6: перевірте і будьте готові відновити

Підніміть тунель, переконайтеся, що потрібна служба працює, потім спробуйте те, що політика має відхилити. Відновіть за допомогою iptables-restore < /root/iptables.pre, якщо відповідь вас здивує, і лише після цього починайте правити правила. Стійкість плюс перевірений шлях відновлення — це те, що робить це зміною, яку можна виконати двічі.

Схожі статті