Перенаправлення (forward) портів iptables
Розглянемо перенаправлення (forward) на двох прикладах:
Причому ми хитрі і хочемо, щоб наш веб-сервер з інтернету не був видно на 443 порту, а був доступний, скажімо, на 1293 порту (приблизно ось так: https://1.2.3.4:1293).
Отже, ми хочемо перенаправити вхідні з інтернету на порт 1293 на порт 443 сервери в локальній мережі.
IF_EXT="eth0" # Зовнішній мережевий адаптер IF_INT="eth1" # Внутрішній мережевий адаптер
IP_EXT="1.2.3.4" # Зовнішній IP IP_INT="192.168.1.1" # Внутрішній IP
FAKE_PORT="1293" # Фейковий порт, доступний з інтернету
LOCAL_SRV="192.168.1.28" # Web сервер у LAN SRV_PORT="443" # Справжній порт
# NAT $IPT -t nat -A PREROUTING -i $IF_EXT -p tcp -d $IP_EXT --dport $FAKE_PORT -j DNAT --to $LOCAL_SRV:$SRV_PORT
# FORWARD $IPT -A FORWARD -i $IF_EXT -o $IF_INT -d $LOCAL_SRV -p tcp --dport $SRV_PORT -j ACCEPT
PREROUTING
Кожен пакет, який потрапляє на інтерфейс, спочатку попередньо обробляється (prerouting). Нам потрібно, щоб до того, як шлюз прийме рішення про маршрутизацію (типу, а що з цим робити?), усім пакетам, що прийшли на зовнішній ($IF_EXT) інтерфейс порту 1293 (наприклад, так: https://1.2 .3.4:1293), було б змінено пункт призначення на IP та порт сервера у внутрішній мережі. Тобто. шлюз "підкоригує" destination пакету, що прийшов так, щоб можна було прийняти правильне рішення про маршрутизацію.
/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp -d 1.2.3.4 --dport 1293 -j DNAT --to 192.168.1.28:443
Далі пакет потрапить у ланцюжок FORWARD.
/sbin/iptables -A FORWARD -i eth0 -o eth1 -d 192.168.1.28 -p tcp --dport 443 -j ACCEPT
Не завжди перенаправлення відбувається з/в локальну мережу. Буває, що необхідно зробити прокиданняз'єднання на сервер, використовуючи проміжний. Це може бути необхідно для додаткової фільтрації клієнтів, що підключаються, для поділу навантаження та інших завдань.
Потрібно, щоб клієнти, які звертаються на 1.1.1.1:25, направлялися б на 2.2.2.2:25, з 1.1.1.1:443 - на 3.3.3.3:443, а з ip 4.4.4.4 звернення на порт 3535 йшли б на 3.3 .3.3:22.
(!) Природно, хости 2.2.2.2 та 3.3.3.3 повинні дозволяти трафік на відповідні порти!
Ось ідея правил iptables на сервері 1.1.1.1:
Коментарі до скрипту:
1) INPUT дозволено лише для 22/tcp, для ssh.
3) Нехай вас не бентежить, що OUTPUT по дефолту DROP, а нижче – все ACCEPT. Звик завжди спочатку ставити DROP на все, а потім за потребою дозволяю. У цьому випадку немає необхідності фільтрувати пакети, що виходять зі шлюзу.
На віддаленому комп'ютері-клієнті запустіть щось на зразок "telnet 1.1.1.1 25". Пакет має прийти на 1.1.1.1:25. Це можна контролювати, запустивши на сервері 1.1.1.1 у консолі команду:
tcpdump -n port 25
Якщо все правильно, на віддаленому клієнті піде сеанс зв'язку з SMTP-сервером 2.2.2.2.