Muff's website forum
FreeBSd => Система => Тема начата: BaRRagA от Декабря 17, 2012, 04:00:42 pm
-
Привет!
Есть следующая проблемка - ядерный нат не пробрасывает порт. Всё по этому мануалу:
http://www.lissyara.su/articles/freebsd/tuning/ipfw_nat/
Вот конфиги:
1. Ядро:#my options
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=10
options IPFIREWALL_FORWARD
options IPFIREWALL_NAT
options DUMMYNET
options LIBALIAS
options IPSEC
device crypto
options IPSEC_DEBUG
options IPSEC_FILTERTUNNEL
#######
2.rc.conf:
gateway_enable="YES"
ifconfig_nfe0="inet 192.168.0.209 netmask 255.255.255.0 -rxcsum -txcsum -tso" #inside net
firewall_enable="YES"
firewall_script="/etc/f_test.fw"
firewall_nat_enable="YES"
dummynet_enable="YES"
ppp_enable="YES"
ppp_mode="ddial"
#ppp_nat="YES"
ppp_profile="ukrtel"
3. /etc/f_test.fw :
#!/bin/sh
ipfw -f flush
cmd="/sbin/ipfw add"
host="82.207.116.20"
pif="tun0"
$cmd allow ip from any to any via lo0
$cmd deny ip from any to 127.0.0.0/8
$cmd deny ip from 127.0.0.0/8 to any
#Allow localnet
$cmd allow all from any to any via nfe0
ipfw nat 1 config log if tun0 reset same_ports deny_in redirect_port tcp 192.168.0.49:3389 3389
ipfw add nat 1 ip from any to any via tun0
$cmd allow ip from any to any
4. /etc/sysctl.conf :
net.inet.ip.fw.one_pass=1
Сам нат работает стабильно, из локальной сети в инет пускает, всё гут. А вот порт пробросить - ни в какую..
-
Попробуйте так:
ipfw nat 1 config log if tun0 same_ports redirect_port tcp 192.168.0.49:3389 3389
-
Попробовал, результат тот же.
gate# ipfw show
00100 1306 681218 allow ip from any to any via nfe0
00200 0 0 allow ip from any to any via lo0
00300 0 0 deny ip from any to 127.0.0.0/8
00400 0 0 deny ip from 127.0.0.0/8 to any
00500 0 0 deny ip from me to table(50)
00600 0 0 deny ip from table(50) to me
00700 9 576 allow icmp from any to any out via tun0 keep-state
00800 66 4027 allow icmp from any to any in via tun0 keep-state
00900 1434 704070 nat 1 ip from any to any via tun0
65535 21 3060 deny ip from any to any
gate# ipfw nat show
nat 1: icmp=0, udp=104, tcp=404, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=508
gate# ipfw nat 1 show config
ipfw nat 1 config if tun0 log same_ports redirect_port tcp 192.168.0.49:3389 3389
gate# tcpdump -i tun0 src port 3389
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
^C
0 packets captured
83 packets received by filter
0 packets dropped by kernel
Tcpdump вообще ничего не показывает... ???
-
Попробуй еще открыть файрвол.
ipfw add 1000 alllow all from any to any
-
Открыл, удалил правила брутблока, получилось так:
gate# ipfw show
00100 50704 45395708 allow ip from any to any via nfe0
00200 12 600 allow ip from any to any via lo0
00300 0 0 deny ip from any to 127.0.0.0/8
00400 0 0 deny ip from 127.0.0.0/8 to any
00500 28 1792 allow icmp from any to any out via tun0 keep-state
00600 180 10955 allow icmp from any to any in via tun0 keep-state
00700 55163 45881778 nat 1 ip from any to any via tun0
00800 0 0 allow ip from any to any
65535 73 55752 deny ip from any to any
Результат тот же :(
-
Остается "слушать" траффик tcpdump-ом. Только для начала "ловите" пакеты dst port 3389 на внешнем интерфейсе (или же просто port 3389). А потом "смотрите" на внутреннем интерфейсе что и как:
tcpdump -i nfe0 port 3389
Ну и для эксперимента попробовать "натить" запросы на ip-адресе, а не на интерфейсе:
ipfw nat 1 config log ip nat_ip_here same_ports redirect_port tcp 192.168.0.49:3389 3389
-
ipfw nat 1 config log ip nat_ip_here same_ports redirect_port tcp 192.168.0.49:3389 3389
Так пробовал, безрезультатно.
gate2# tcpdump -i tun0 port 3389
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
13:13:59.737448 IP 82-117-234-176.gpon.sta.kh.velton.ua.43487 > gate.portal.com.ua.rdp: Flags [S], seq 2460290477, win 65535, options [mss 1440,nop,nop,sackOK], length 0
13:14:02.680720 IP 82-117-234-176.gpon.sta.kh.velton.ua.43487 > gate.portal.com.ua.rdp: Flags [S], seq 2460290477, win 65535, options [mss 1440,nop,nop,sackOK], length 0
13:14:08.805640 IP 82-117-234-176.gpon.sta.kh.velton.ua.43487 > gate.portal.com.ua.rdp: Flags [S], seq 2460290477, win 65535, options [mss 1440,nop,nop,sackOK], length 0
Я так понимаю, что пакеты рубятся на правиле 65535, deny all... Почему-то проскакивая мимо ната..
-
А на внутреннем интерфейсе что творится?
tcpdump -ni nfe0 port 3389
-
Ничего.. при попытках подключиться извне.
Интересная вещь - заглянул в ppp.conf, там были строки
nat enable yes # если хотите использовать NAT для локальной сети
nat same_ports yes # если хотите использовать NAT для локальной сети
nat use_sockets yes # если хотите использовать NAT для локальной сети
Попробовал их закаментить и перегрузиться - теперь нат вообще вырубился. Это что ж получается - ядерный нат вообще не использовался? Но судя по выводу ipfw show пакеты в правило попадали... Совсем запутался.
-
Попробуйте в rc.conf добавить строку:
cloned_interfaces="tun0"
И отключить НАТ в ppp.conf.
-
Попробовал, не помогло...
Если отключить нат в ppp.conf, ядерный нат при перезагрузке сервера вообще не включается.. хз почему.
Плюнул на стандартный ppp-клиент, поставил mpd5 и его pppoe клиент, теперь после перезагрузки всё ок, ядерный нат работает, в инет пускает, но порт по-прежнему не пробрасывает.
tcpdump выдаёт то же самое.
Бьюсь головой... :(
Что любопытно - попробовал таким образом пробросить другой порт(40001) - для utorrent - работает!! о_О
ipfw nat 2 config ip 1.2.3.4 log same_ports redirect_port tcp 192.168.0.153:40001 40001 redirect_port tcp 192.168.0.49:3389 3389
-
Странно, всегда работало...
Правда я всегда использовал ethernet при подключении. Возможно дело как раз в ppoe. Как вариант - НАТ пытается запуститься до того, как создан интерфейс...
Попробуй PF - может он справится...
-
Видимо, удар об стену помог :)))
Дело в том что всё это дело происходило на РЕЗЕРВНОМ шлюзе.
Соответственно на сервере терминалов 192.168.0.49 шлюзом по умолчанию стоит IP основного шлюза.
Как только поменял на 192.168.0.209 всё стало чудно пробрасывать.
В общем, на основном сделаю проброс через kernel nat, на резервном - через rinetd(или redir) и буду спать спокойно.
muff спасибо тебе огромное за участие и ответы!!!!!