непонятки с NAT
Доброго всем времени. Имеются проблемы с NAT, не знаю как решить. При обращении с оффтопика за шлюзом Debian на удаленный хост для установления GRE — удаленный хост принимает пакеты с локальным адресом отправителя оффтопика. Происходит это только по GRE, (иногда случается с SIP) остальные соединения идут «как надо».
Описываю направление соединения: Оффтопик(192.168.100.50)>Шлюз Debian(eth1 192.168.100.100 eth0 94.73.222.31) == Интернет == Удаленный хост Ubuntu (eth0 91.234.11.49 eth1 192.168.0.254)>Проброс порта и gre>Оффтопик PPTPD сервер(192.168.0.253)
iptables-save с Debian хоста
root@debian:~# iptables-save # Generated by iptables-save v1.4.14 on Wed Sep 16 09:17:50 2015 *mangle :PREROUTING ACCEPT [44821:42269251] :INPUT ACCEPT [35135:25384906] :FORWARD ACCEPT [9633:16869506] :OUTPUT ACCEPT [33646:18586636] :POSTROUTING ACCEPT [43292:35456966] COMMIT # Completed on Wed Sep 16 09:17:50 2015 # Generated by iptables-save v1.4.14 on Wed Sep 16 09:17:50 2015 *nat :PREROUTING ACCEPT [583:50238] :INPUT ACCEPT [529:36983] :OUTPUT ACCEPT [203:12567] :POSTROUTING ACCEPT [203:12567] -A POSTROUTING -s 192.168.100.0/24 -o eth0 -j SNAT --to-source 94.73.222.31 COMMIT # Completed on Wed Sep 16 09:17:50 2015 # Generated by iptables-save v1.4.14 on Wed Sep 16 09:17:50 2015 *filter :INPUT ACCEPT [29288:21156398] :FORWARD ACCEPT [8175:13724571] :OUTPUT ACCEPT [28030:15147584] :fail2ban-ssh - [0:0] -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A fail2ban-ssh -j RETURN COMMIT # Completed on Wed Sep 16 09:17:50 2015 root@debian:~# root@debian:~# cat /proc/sys/net/ipv4/ip_forward 1 root@ubuntu:~# iptables-save # Generated by iptables-save v1.4.4 on Wed Sep 16 09:32:45 2015 *mangle :PREROUTING ACCEPT [981288281:886622485381] :INPUT ACCEPT [514049277:408826043243] :FORWARD ACCEPT [467153224:477791780858] :OUTPUT ACCEPT [507905675:391722767192] :POSTROUTING ACCEPT [975110085:869520517543] COMMIT # Completed on Wed Sep 16 09:32:45 2015 # Generated by iptables-save v1.4.4 on Wed Sep 16 09:32:45 2015 *nat :PREROUTING ACCEPT [12587510:846306111] :POSTROUTING ACCEPT [9372134:625939879] :OUTPUT ACCEPT [9653170:647997987] -A PREROUTING -i eth0 -p tcp -m tcp --dport 1723 -j DNAT --to-destination 192.168.0.253 -A PREROUTING -i eth0 -p gre -j DNAT --to-destination 192.168.0.253 -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE COMMIT # Completed on Wed Sep 16 09:32:45 2015 # Generated by iptables-save v1.4.4 on Wed Sep 16 09:32:45 2015 *filter :INPUT ACCEPT [514049285:408826049235] :FORWARD ACCEPT [467153195:477791779624] :OUTPUT ACCEPT [507905684:391722772724] -A FORWARD -s 192.168.5.0/24 -d 192.168.0.0/24 -j DROP COMMIT # Completed on Wed Sep 16 09:32:45 2015 root@ubuntu:~# Начинаю «звонить» по PPTP с оффтопика (192.168.100.50) на Ubuntu(91.234.11.49), на Ubuntu запускаю tcpdump и вижу:
root@ubuntu:~# tcpdump -n -i eth0 proto GRE tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 09:10:07.726082 IP 192.168.100.50 > 192.168.0.253: GREv1, call 53771, seq 0, length 37: LCP, Conf-Request (0x01), id 0, length 23 09:10:09.724191 IP 192.168.100.50 > 192.168.0.253: GREv1, call 53771, seq 1, length 37: LCP, Conf-Request (0x01), id 1, length 23 09:10:12.724607 IP 192.168.100.50 > 192.168.0.253: GREv1, call 53771, seq 2, length 37: LCP, Conf-Request (0x01), id 2, length 23 09:10:16.725015 IP 192.168.100.50 > 192.168.0.253: GREv1, call 53771, seq 3, length 37: LCP, Conf-Request (0x01), id 3, length 23 09:10:20.726245 IP 192.168.100.50 > 192.168.0.253: GREv1, call 53771, seq 4, length 37: LCP, Conf-Request (0x01), id 4, length 23 09:10:24.726001 IP 192.168.100.50 > 192.168.0.253: GREv1, call 53771, seq 5, length 37: LCP, Conf-Request (0x01), id 5, length 23 09:10:28.726473 IP 192.168.100.50 > 192.168.0.253: GREv1, call 53771, seq 6, length 37: LCP, Conf-Request (0x01), id 6, length 23 09:10:32.726943 IP 192.168.100.50 > 192.168.0.253: GREv1, call 53771, seq 7, length 37: LCP, Conf-Request (0x01), id 7, length 23 09:10:36.727449 IP 192.168.100.50 > 192.168.0.253: GREv1, call 53771, seq 8, length 37: LCP, Conf-Request (0x01), id 8, length 23 09:10:40.727955 IP 192.168.100.50 > 192.168.0.253: GREv1, call 53771, seq 9, length 37: LCP, Conf-Request (0x01), id 9, length 23 Соединение не устанавливается
Ради интереса звоню на Ubuntu совершенно из другой сети, запускаю tcpdump на Ubuntu и вижу:
root@ubuntu:~# tcpdump -n -i eth0 proto GRE tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 09:09:01.136171 IP 195.28.164.19 > 192.168.0.253: GREv1, call 26605, seq 0, length 37: LCP, Conf-Request (0x01), id 0, length 23 09:09:01.247928 IP 192.168.0.253 > 195.28.164.19: GREv1, call 60072, ack 0, no-payload, length 12 09:09:03.135558 IP 195.28.164.19 > 192.168.0.253: GREv1, call 26605, seq 1, length 37: LCP, Conf-Request (0x01), id 1, length 23 09:09:03.136927 IP 192.168.0.253 > 195.28.164.19: GREv1, call 60072, seq 0, ack 1, length 72: LCP, Conf-Request (0x01), id 0, length 54 09:09:03.136948 IP 192.168.0.253 > 195.28.164.19: GREv1, call 60072, seq 1, length 37: LCP, Conf-Ack (0x02), id 1, length 23 09:09:03.139115 IP 195.28.164.19 > 192.168.0.253: GREv1, call 26605, seq 2, ack 1, length 51: LCP, Conf-Reject (0x04), id 0, length 33 09:09:03.139591 IP 192.168.0.253 > 195.28.164.19: GREv1, call 60072, seq 2, ack 2, length 45: LCP, Conf-Request (0x01), id 1, length 27 09:09:03.141020 IP 195.28.164.19 > 192.168.0.253: GREv1, call 26605, seq 3, ack 2, length 29: LCP, Conf-Nack (0x03), id 1, length 11 09:09:03.141427 IP 192.168.0.253 > 195.28.164.19: GREv1, call 60072, seq 3, ack 3, length 46: LCP, Conf-Request (0x01), id 2, length 28 09:09:03.143043 IP 195.28.164.19 > 192.168.0.253: GREv1, call 26605, seq 4, ack 3, length 46: LCP, Conf-Ack (0x02), id 2, length 28 09:09:03.143082 IP 195.28.164.19 > 192.168.0.253: GREv1, call 26605, seq 5, length 32: LCP, Ident (0x0c), id 2, length 20 09:09:03.143092 IP 195.28.164.19 > 192.168.0.253: GREv1, call 26605, seq 6, length 38: LCP, Ident (0x0c), id 3, length 26 09:09:03.143102 IP 195.28.164.19 > 192.168.0.253: GREv1, call 26605, seq 7, length 38: LCP, Ident (0x0c), id 4, length 26 09:09:03.144685 IP 192.168.0.253 > 195.28.164.19: GREv1, call 60072, seq 4, ack 7, length 44: CHAP, Challenge (0x01), id 0, Value 60aa76abdce7ded367c43285e0788994, Name DELTA 09:09:03.147429 IP 195.28.164.19 > 192.168.0.253: GREv1, call 26605, seq 8, ack 4, length 80: CHAP, Response (0x02), id 0, Value 97884b4443e14b12d226c15dc0a6cce80000000000000000964cd4d22c46dbe4a1[|chap] 09:09:03.156124 IP 192.168.0.253 > 195.28.164.19: GREv1, call 60072, seq 5, ack 8, length 64: CHAP, Success (0x03), id 0, Msg S=1CE5DC51248DA668595E429DA7359A1E[|chap] Соединение устанавливается успешно. С подобной проблемой сталкивался на Микротиках, но там помогало переключение MASQUERADE на SNAT, в данном случае на Debian прописан SNAT, но результата нету.
Уважаемые гуру, прошу Вас помощи.
Не работает NAT в CentOS на KVM
Имеем виртуальную машину работающую на KVM в нутри которой CentOS 7.
В качестве фаерволла используется iptables.
И ко всему прочему на машинке стоит OpenVPN.
Задача трафик приходящий из tun0 натить и отправлять в eth0.
Пытаюсь сделать это таким правилом
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEЗаранее извиняюсь за за некомпетентный вопрос, с Linux машинами в качестве роутеров работаю впервые, до этого опыт только с BSD.
Между tun0 и eth0 как я понимаю?
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth0 -j ACCEPT iptables -A FORWARD -o eth0 -j ACCEPT iptables -A FORWARD -i tun0 -j ACCEPT iptables -A FORWARD -o tun0 -j ACCEPT Кстати, как понять что iptables вообще работает? До этого работал firewalld, он реально работал но делая настройку по одной из статей я отключил firewalld и заменил его на iptables.
В ядре надо разрешить. Правь /etc/sysctl.conf
# System default settings live in /usr/lib/sysctl.d/00-system.conf. # To override those settings, enter new settings here, or in an /etc/sysctl.d/.conf file # # For more information, see sysctl.conf(5) and sysctl.d(5). net.ipv4.ip_forward = 1
Отлично. Теперь маршруты покажи.
Посмотри tcpdump-ом пакеты.
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth0 -o tun0 -m state --state NEW -j ACCEPT iptables -A FORWARD -o eth0 -i tun0 -m state --state NEW -j ACCEPT 2-3 строки лучше так, имхо, если у тебя задача только шлюз VPNLAN. 4-5, ессно, выкинуть в таком случае.
dhameoelin ★★★★★ ( 19.10.15 12:43:57 MSK )
Последнее исправление: dhameoelin 19.10.15 12:44:35 MSK (всего исправлений: 1)
[root@ovpn ~]# sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1 12:50:46.578427 IP OVPN_SERVER.commplex-main > ROUTHER.54091: Flags [P.], seq 190:285, ack 191, win 1028, options [nop,nop,TS val 1056301788 ecr 6630549], length 95 12:50:46.578572 IP ROUTHER > 207.241.224.2: ICMP echo request, id 288, seq 1414, length 36 12:50:46.603152 IP ROUTHER.54091 > OVPN_SERVER.commplex-main: Flags [P.], seq 191:286, ack 285, win 31620, options [nop,nop,TS val 6631571 ecr 1056301788], length 95 12:57:01.201060 IP 10.64.39.253 > 207.241.224.2: ICMP echo request, id 288, seq 1415, length 36 12:57:01.229133 IP 194.68.128.187 > 10.64.39.253: ICMP time exceeded in-transit, length 36 12:57:01.975956 IP 10.64.39.253 > 207.241.224.2: ICMP echo request, id 288, seq 1410, length 36 12:57:01.976008 IP 172.16.64.10 > 10.64.39.253: ICMP time exceeded in-transit, length 64 OVPN_SERVER — внешний IP адрес VPN сервера ROUTHER — внешний IP адрес роутера на котором собственно и нужен nat 207.241.224.2 — узел который мы пингуем. 10.64.39.253 — узел c которого мы пингуем, узел за VPN.
трафик приходящий из tun0 натить и отправлять в eth0.
SNAT работает на выходе, т.е. сначала трафик должен попасть в eth0, а туда он попадет в соотв. с сетевыми маршрутами, возможно сначала понадобится DNAT, чтобы сработали нужные маршруты.
Вобщем, при данном тобой описании задачи — она (задача) не решаема.
Судя по дампам, нат отрабатывает нормально, но есть проблемы с маршрутизацией до хоста где-то между твоим провайдером и этим хостом включительно.
[root@ovpn ~]# traceroute -n 207.241.224.2 traceroute to 207.241.224.2 (207.241.224.2), 30 hops max, 60 byte packets 1 x.x.x.x 10.044 ms 10.014 ms 9.993 ms 2 77.73.25.13 0.512 ms 0.503 ms 0.502 ms 3 87.245.229.193 0.504 ms 1.248 ms 1.239 ms 4 87.245.233.134 24.443 ms 24.447 ms 24.478 ms 5 194.68.128.187 24.725 ms 25.238 ms 25.201 ms 6 72.52.92.81 47.538 ms 48.282 ms 48.332 ms 7 72.52.92.13 58.345 ms 58.365 ms 57.654 ms 8 184.105.213.93 140.188 ms 141.125 ms 132.040 ms 9 184.105.213.177 189.637 ms 188.656 ms 199.902 ms 10 184.105.81.86 211.942 ms 212.325 ms 211.812 ms 11 65.49.10.214 196.331 ms 196.306 ms 196.286 ms 12 207.241.224.2 206.515 ms 211.341 ms 211.235 m Митика но, если с самого роутера пинговать то все нормально.