iptables: дозволити клієнтам VPN доступ лише до одного хоста

Потрібне правило міститься у FORWARD, а не в INPUT. Дозвольте одне призначення для пулу VPN, відхиліть решту, а потім доведіть це лічильниками та командою відкату.

Два звернення до підтримки, які виглядають не пов’язаними, насправді мають одну причину. У першому адміністратор хоче, щоб сервер приймав з’єднання лише з тунелю; у другому користувачі VPN мають потрапляти на один внутрішній хост і нікуди більше. Обидві політики належать FORWARD, і обидві зазвичай намагаються реалізувати в INPUT. Результат виглядає як міжмережевий екран, а поводиться як заглушка.

Який ланцюг відповідає на ваше питання

Пакети, які клієнт VPN надсилає хосту в локальній мережі або далі в інтернет, ядро пересилає, і вони оцінюються у FORWARD. INPUT і OUTPUT бачать лише трафік, що завершується на самому сервері або походить від нього. Тому відхилення всього, що не надходить на tun0, захищає власні слухачі сервера і також обірве вашу сесію SSH, якщо спочатку не дозволити встановлені потоки. Це ніяк не змінює того, куди клієнтам дозволено ходити.

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

Спочатку стан, потім дозвіл, потім відмова

Список дозволів працює, лише якщо конкретний дозвіл стоїть вище за загальну відмову і якщо зворотний трафік дозволено вище за обидва. Вставляйте правила на явні позиції, а потім виведіть ланцюг за допомогою iptables -S FORWARD, щоб порядок було видно, а не припущено.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Дві деталі вирішують, чи переживе це зіткнення з реальним трафіком. Без правила стану відповіді на щойно дозволені з’єднання самі оцінюються проти відмови й відкидаються. Правило LOG без обмеження може заповнити невеликий розділ під час першого ж сканування, тому додайте -m limit --limit 10/min, перш ніж продовжувати журналювання. REJECT негайно повертає помилку, що зручніше під час налаштування списку; DROP відкидає мовчки, тому кожна помилка виглядає як вичерпаний час очікування. Виберіть одне свідомо й запишіть вибір у журнал змін.

Пересилання та NAT уже мають працювати

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

Де саме маскування, залежить від того, звідки виходять клієнти. Якщо вони виходять через тунель до віддаленої мережі, правило NAT ставиться на цей інтерфейс, а не на інтерфейс WAN. Потім дивіться на лічильники: якщо лічильник POSTROUTING ніколи не рухається, а кількість дозволів у FORWARD зростає, зворотний шлях зламано, а фільтр у порядку. Таке читання економить півдня на переписування правил, які ніколи не були проблемою.

Блок пошти належить до сусіднього ланцюга

Блокування порту 25 в INPUT зупиняє лише пошту, адресовану серверу VPN. Скомпрометований клієнт, який надсилає пошту через тунель, пересилається, тому блок має стояти в FORWARD поруч із 465 і 587. Якщо один застосунок легально пересилає пошту, поставте його призначення та порт вище за це правило.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

Дайте лічильнику відмов попрацювати тиждень, перш ніж щось інше посилювати. Число, яке перестало зростати, і є той легальний потік, який ви щойно зламали.

Перечитайте все назад, а потім доведіть із клієнта

Читайте набір правил так, як його повідомляє ядро, а не так, як його написав ваш скрипт. Почніть із iptables -S FORWARD, потім таблиця NAT за допомогою iptables -t nat -L POSTROUTING -n -v, потім запис conntrack для потоку, який ви перевіряєте. Тримайте під рукою команду відкату або заплановане очищення, поки триває робота. Кожен виклик потребує -w, інакше два адміністратори зіткнуться на блокуванні xtables. Ніщо з цього не є необов’язковим у вікні змін.

Заверште перевіркою з клієнта всередині пулу та з клієнта зовні. Правило, яке працює лише з тієї машини, де ви його набрали, — не політика.

Схожі статті