Не могу пробросить порт. Пакеты пропадают после PREROUTING.
Добрый день. Прошу помочь с проблемой.
Есть VPN сервер, пакеты с одного из его ip идут ко мне (порты 22001-24000). Есть моя машина, имеет статический ip в vpn сети 172.19.0.9 P-t-P:172.19.0.10, интерфейс tun1
Я хочу пробросить порт 22001 своей машины на порт 80 (для начала моей же машины, потом будет ip-камера в локалке)
Настройки моей машины:
iptables -t nat -I PREROUTING -i tun1 -p tcp --dport 22001 -j LOG --log-level INFO --log-prefix "Vhod tun1 22001: " iptables -t nat -A PREROUTING -i tun1 -p tcp --dport 22001 -j DNAT --to-destination 172.19.0.9:80 #мой же ip в vpn сети, потом заменю на ip камеры в локалке iptables -t mangle -A INPUT -p tcp --dport 80 -j LOG --log-level INFO --log-prefix "INPUT 80: "
Форвардинг включен:
without-pc # cat /proc/sys/net/ipv4/ip_forward 1 without-pc # cat /proc/sys/net/ipv4/conf/all/forwarding 1
Стучусь по external_ip_vpn_server:22001, пытаюсь зафиксировать пакеты до маршрутизации и после:
[ 6150.304125] Vhod tun1 22001: IN=tun1 OUT= MAC= SRC=my_inet_ip DST=172.19.0.9 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=9176 DF PROTO=TCP SPT=57076 DPT=22001 WINDOW=5840 RES=0x00 SYN URGP=0 [ 6153.034265] Vhod tun1 22001: IN=tun1 OUT= MAC= SRC=my_inet_ip DST=172.19.0.9 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=49665 DF PROTO=TCP SPT=57075 DPT=22001 WINDOW=5840 RES=0x00 SYN URGP=0 [ 6153.285232] Vhod tun1 22001: IN=tun1 OUT= MAC= SRC=my_inet_ip DST=172.19.0.9 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=9177 DF PROTO=TCP SPT=57076 DPT=22001 WINDOW=5840 RES=0x00 SYN URGP=0
Как можно видеть, сообщений из INPUT не поступило.
Таблица маршрутизации:
without-pc # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface vpn.swamp.ru * 255.255.255.255 UH 0 0 0 eth0 172.18.0.2 * 255.255.255.255 UH 0 0 0 tun0 172.19.0.10 * 255.255.255.255 UH 0 0 0 tun1 10.5.0.1 * 255.255.255.255 UH 0 0 0 ppp0 172.18.0.0 172.18.0.2 255.255.255.0 UG 0 0 0 tun0 172.19.0.0 172.19.0.10 255.255.255.0 UG 0 0 0 tun1 172.16.0.0 * 255.255.0.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default 10.5.0.1 0.0.0.0 UG 0 0 0 ppp0
Порты у меня открыты:
without-pc # iptables -t filter -L INPUT Chain INPUT (policy ACCEPT) target prot opt source destination LOG all -- anywhere anywhere LOG level info prefix `-t filter INPUT -i tun1: '
Вопрос: почему я не вижу пакетов в цепочке INPUT? Куда они деваются после PREROUTING?
В данный момент не является важными маркировка соединений и маршрутизация обратных пакетов (ответов www сервера). Проблемы буду решать по мере поступления.
UPD: В английской википедии нашлась более подробная картинка http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
На ней показан некий "bridging decision". Не могу понять, что это
- Для комментирования войдите или зарегистрируйтесь
я бы посоветовал сначала
я бы посоветовал сначала внимательно прочитать http://ru.wikipedia.org/wiki/Iptables
первое: никогда не видел "--to-destination 172.19.0.9:80"
второе: насколько знаю PREROUTING выполняеться раньше чем INPUT.
Пишите правила правильно.
По этой статье и изучаю
По этой статье и изучаю iptables
1) Как тогда изменить и порт и адрес получателя? Как я понимаю, правило DNAT терминальное. После первого из двух правил, пакет уйдёт из nat PREROUTING
2) Да, хочу:
2.1) Проверить, поступил ли пакет в PREROUTING
2.2) Изменить адрес и порт получателя (пока на свой же адрес)
2.3) Проверить, поступил ли модифицированный пакет в INPUT
1. Пользуйтесь -j LOG 2.
1. Пользуйтесь -j LOG
2. Изучать надо по http://www.iptables.org/ :)
falrus написал(а): Вопрос:
Потому что для этих целей существует правило REDIRECT, который и будет отлавливать и сворачивать на локальный интерфейс. DNAT нужен для транзитных пакетов, то есть тех которые заведомо на локальный интерфейс не попадут.
Спасибо
Спасибо
Честно говоря, всё равно не
Честно говоря, всё равно не отлавливает в INPUT
Отлавливает только в PREROUTING
При этом, пакеты идущие от localhost (а не через vpn сервер) отлично логируются в INPUT.
tcpdump -n -i tun1 port
tcpdump -n -i tun1 port 22001
что дает?
Теперь понятно, ты показал не
Теперь понятно, ты показал не все правила, у тебя между первым и последним правилом в таблице NAT наверное RETURN есть или что-то подобное ... Проверь по счетчику пакетов - вот мой совет.
Если мне моя память ни с кем
Если мне моя память ни с кем не изменяет, то пакеты, попавшие под правило с
-j LOG
, дальше уже никуда не идут.Когда отлаживал правила на некоем сервере, сам долго ломал голову, куда исчезают пакеты. В логах-то они есть.
Я не смог понять твой комментарий...
И по этому поводу решил подарить тебе запятую: ",". Используй её с умом!
неправильно понимаешь, это
неправильно понимаешь, это правило не запрещающее, пакеты будут и дальше проходить по цепочке пока их не остановят или трансформируют
Я тоже так думал. Не знаю,
Я тоже так думал.
Не знаю, может быть, у меня руки не из того места растут или что-то у меня не так настроено. Но пакеты, которые подпадали под правило LOG, исчезали бесследно.
Я не смог понять твой комментарий...
И по этому поводу решил подарить тебе запятую: ",". Используй её с умом!
Не могут они исчезать!...
Не могут они исчезать!... :)
А вам не надо забывать пересобирать iptables при обновлении/модификации ядра.
Вам надо не в ИНПУТ смотреть,
Вам надо не в ИНПУТ смотреть, а в АУТПУТ, так как выходить будет на 80 порт, а не входить.
С уважением.
http://ru.wikipedia.org/wiki/
http://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%B9%D0%BB:Netfilter-diagram-rus.png
Если верить этой таблице, то пакет должен после маршрутизации отправиться в INPUT
Если верить картинке, то да.
Если верить картинке, то да. Но старовата она.
В любом случае Вы правы в том, что пришло время перечитать документацию.
С уважением.
Неправильно! Если верить
Неправильно!
Если верить таблице (я пользуюсь http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES) пакет может отправиться в INPUT, в случае только если цель местная! А может и в FORWARD... Так что кроме рассматривания картинок, читайте первоисточники!..
Все это великолепно, но
Все это великолепно, но маркетологическое слово vpn ни о чем не говорит. На чем оно сделано ?
если это ipsec например, то все немного не по википидийным картинкам
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
OpenVPN Сервер: openvpn.i386
OpenVPN
Сервер: openvpn.i386 2.0.9-1.el5.rf
Конфиг сервера:
Клиент openvpn-2.1_rc15
Конфиг клиента:
включаем udp ( tcp over tcp -
включаем udp ( tcp over tcp - это нечто)
делаем бриджом, переходим на level2 и не парим голову личними проблемами
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Я сейчас читаю документацию,
Я сейчас читаю документацию, пытаюсь понять эту идею.
Получается, что OpenVPN сервер, пограничный роутер (vpn клиент) и машины в моей локальной сети должны иметь IP адреса из одной подсети?
а какой смысл городить
а какой смысл городить микроскопическую по размерам сеть VPN с маршрутизацией и кучей подсетей ?.
Клиент коннейтится к серверу, получает адрес из общей сетки, пишет себе раоутинг на дефаулт и на vpn и работает долго и сщастрливо, не оверхедя всякой фигней и не усложняя схему.
Хорошие оценки за суперсложные, но академически правильные схемы ставят в вузах. В жизни чем проще - тем надежней.
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
emerge net-misc/ferm
emerge net-misc/ferm
P.S.: Linux - это красная таблетка :-) Windows - синяя...
а если в raw-таблице -j TRACE
а если в raw-таблице -j TRACE указать, что в логах показывает?
Нейтральность - высшее достижение сознания!