Почему не работает форвардинг на Centos?

Question

[Abdus]

Добрый день.

Бьюсь на задачей роутинга трафика, помогите разобраться, что я делаю не так.
Есть сервер на CentOS 6.5, который должен стать шлюзом в филиале. На нем также стоит DNS, samba, DHCP серверы, но это сейчас не имеет значения.

На нем есть 2 физических интерфейса:
eth0 - интернет
eth1 - локалка
tun0 - openvpn клиент для доступа к ресурсам центрального филиала
форвардинг влючен

Интерфейсы:

ifconfig
eth0      Link encap:Ethernet  HWaddr A0:48:1C:B8:9B:24
          inet addr:192.168.248.99  Bcast:192.168.248.255  Mask:255.255.255.0
          inet6 addr: fe80::a248:1cff:feb8:9b24/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1679 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1176 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:287551 (280.8 KiB)  TX bytes:176587 (172.4 KiB)
          Interrupt:16

eth1      Link encap:Ethernet  HWaddr A0:48:1C:B8:9B:25
          inet addr:192.168.243.1  Bcast:192.168.243.255  Mask:255.255.255.0
          inet6 addr: fe80::a248:1cff:feb8:9b25/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:716 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:106579 (104.0 KiB)  TX bytes:1772 (1.7 KiB)
          Interrupt:17

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4651 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4651 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:431755 (421.6 KiB)  TX bytes:431755 (421.6 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.251.25  P-t-P:192.168.251.26  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:39274 errors:0 dropped:0 overruns:0 frame:0
          TX packets:37107 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:2628370 (2.5 MiB)  TX bytes:4775995 (4.5 MiB)

cat /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
HWADDR=A0:48:1C:B8:9B:25
TYPE=Ethernet
UUID=4e29b9f1-f7b2-47af-aee7-70d33b6fef93
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=static
IPADDR=192.168.243.1
NETMASK=255.255.255.0
GATEWAY=192.168.248.99
NETWORK=192.168.243.0
DHCP_HOSTNAME=server

cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
HWADDR=A0:48:1C:B8:9B:24
TYPE=Ethernet
UUID=c317a2a8-67b5-4908-b32b-4c16d174f162
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=static
IPADDR=192.168.248.99
NETMASK=255.255.255.0
GATEWAY=192.168.248.1
DNS1=127.0.0.1

роутинг и фаерволл:

ip ro show all
192.168.251.26 dev tun0  proto kernel  scope link  src 192.168.251.25
192.168.243.0/24 dev eth1  proto kernel  scope link  src 192.168.243.1
192.168.248.0/24 dev eth0  proto kernel  scope link  src 192.168.248.99
192.168.250.0/24 via 192.168.251.26 dev tun0
169.254.0.0/16 dev eth0  scope link  metric 1002
169.254.0.0/16 dev eth1  scope link  metric 1003
default via 192.168.248.1 dev eth0

iptables-save
# Generated by iptables-save v1.4.7 on Tue May 20 11:19:40 2014
*nat
:PREROUTING ACCEPT [22051:1894583]
:POSTROUTING ACCEPT [563:37112]
:OUTPUT ACCEPT [1043:70981]
-A PREROUTING ! -d 192.168.243.0/24 -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3129
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Tue May 20 11:19:40 2014
# Generated by iptables-save v1.4.7 on Tue May 20 11:19:40 2014
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [658:125819]
-A INPUT -i eth1 -p udp -m udp --dport 137 -j ACCEPT
-A INPUT -i eth1 -p udp -m udp --dport 138 -j ACCEPT
-A INPUT -i eth1 -p udp -m udp --dport 139 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 139 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 138 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 137 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 3129 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -d 192.168.250.0/24 -i eth1 -o tun0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT
COMMIT

В чем проблема:
Недоступны ресурсы центрального офиса (подсеть 192.168.250.0, через интерфейс openvpn) и с интерфейса eth1 нет коннекта в интернет

пинги:

ping -I eth1 192.168.250.102
PING 192.168.250.102 (192.168.250.102) from 192.168.243.1 eth1: 56(84) bytes of data.
From 192.168.243.1 icmp_seq=2 Destination Host Unreachable

ping -I eth1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.168.243.1 eth1: 56(84) bytes of data.
From 192.168.243.1 icmp_seq=2 Destination Host Unreachable

ping -I tun0 192.168.250.102
PING 192.168.250.102 (192.168.250.102) from 192.168.251.25 tun0: 56(84) bytes of data.
64 bytes from 192.168.250.102: icmp_seq=1 ttl=63 time=166 ms

Answer 1

[younghacker]

Вы не показали таблицы маршрутизации центрального сервера. Как можно понять из приведённой информации на нём на VPN интерфейсе есть сеть 192.168.250.0/24, а значит на нём должна быть маршрутизация через vpn в ваши сети которые вы хотите сделать доступными:

192.168.248.0/24
192.168.243.0/24
192.168.251.0/24

В одной консоли запустите
ping -I eth1 192.168.250.102
Во второй
tcpdump -i tun0 host 192.168.250.102
На центральном сервере на tun интерфейсе также запустите
tcpdump -i tun0 host 192.168.250.102
Смотрите что пакеты проходят как в одну так и во вторую сторону.
Ищите где затык.

Мне также жутко не нравится Ваш iptables. В частности цепочки FORWARD

-A FORWARD -d 192.168.250.0/24 -i eth1 -o tun0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT

Запустите пинги из одной консоли и позапускайте посмотрите какие счётчики растут.
# iptables -nvL
Вы цепочкой

-A FORWARD -j REJECT --reject-with icmp-host-prohibited

режете трафик который идёт из tun0.

У вас все адреса локальные поэтому можете попробовать разрешить всё:

-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -o eth0 -j ACCEPT
-A FORWARD -i eth1 -j ACCEPT
-A FORWARD -o eth1 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

Пробуйте.

Comments

[Abdus]

я ниже описал проблему

Answer 2

[Abdus]

iptables я пока что отключил совсем. Когда роутинг настрою, то буду фаерволл мучать.

Затем я tcpdump'ом помониторил интерфейсы. Пакеты запроса уходят с eth1 и все. Ответа нигде нет и никуда дальше пакеты не идут. Я traceroute когда выполняю на любой ip , то там тишина.
Вообще в чем сейчас проблема. У меня нету роутинга от eth1 до tun0 и до eth0.
в веб:

traceroute -i eth1 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 * * *

в центральный офис:

traceroute -i eth1 192.168.250.102
traceroute to 192.168.250.102 (192.168.250.102), 30 hops max, 60 byte packets
1 * * *

с одного интерфейса на другой:

traceroute -i eth1 192.168.248.99
traceroute to 192.168.248.99 (192.168.248.99), 30 hops max, 60 byte packets
 1  * * *

Я сижу гуглю, но ни как не могу найти инфу, как разрешить гнать все пакеты с одного интерфейса на другой. Фовардинг включен:

cat /proc/sys/net/ipv4/ip_forward
1

Comments

[Игорь]

включите iptables с политиками по умолчанию ACCEPT, но добавьте в цепочку POSTROUTING действие MASQUERADE

[Abdus]

сделал. Не помогло

[Abdus]

@merryjane а не подскажите как в принципе сделать роутинг, чтоб один интерфейс мог пинговать другой?

[younghacker]

@Abdus traceroute тут не поможет. Дампить нужно.
Вы обратили внимание на адреса (src dst) пакета который уходит?
Тaaак... И не люблю я эти пинги с интефейсов без адреса.
В одном окне терминала
$ ping -I 192.168.243.1 8.8.8.8
В другом терминала
# tcpdump -n -i eth0 proto ICMP

[younghacker]

Тоесть вместо имени интерфейса используйте адрес привязанный к этому интерфейсу.

[Abdus]

@younghacker вы святой человек! =) пинганул указав адрес вместо имени интерфейса и заработало! И так, на текущий момент пакеты бегают, из eth0 в eth1 и обратно. tcpdum "все ок" говорит.
Прохождения пакетов из сети 192.168.243.0 в подсеть центрального офиса 192.168.250.0 через openvpn идет немного странно. Идет пинг, 1 раз все проходит и далее тишина в эфире.

А вы не могли бы пояснить в чем разница между "ping -i eth1" и "ping -i 192.168.243.1"?

[younghacker]

В случае ping -I eth1 пакеты улетают "наружу" непосредственно в интерфейс.
А в случае ping -I 192.168.243.1 используется таблица маршрутизации хоста на котором запущен ping. Тоесть пакет попадает как бы внутрь хоста с адресом источника равным заданному адресу на интерфейсе.

[younghacker]

Но давайте разбираться дальше. Давайте опустим возможности русского языка и относительно ответов команд будем общаться конкретно. tcpdump не говорит OK! :) Он говорит что слышит на интерфейсе и фильтруя по заданному условию. Вы сказали пинг один раз всё проходит. Тоесть стабильно один раз есть запрос и ответ? А потом только запросы, без ответов. При прерывании в стратистике написано сколько отправлено и получен только один ответ. Так?

Если Вы имеете доступ к офисному серверу (или попросите админа) запустите там
# tcpdump -i tunХ proto ICMP
далее смотрите адрес источника и адрес получателя на входящем пакете и на ответе.
Затем посмотрите таблицу маршрутизации на сервере есть ли единственный маршрут в сеть где находится адрес источника. Нет ли какого-то конфликта сетей (например в офисе есть сетка такая же как у вас)?

Вот ещё что можно попробовать.
Можете добавить в iptables правило
-A POSTROUTING -o tun0 -j MASQUERADE
Только добавьте аксептирующие правила input и forward (вы говорили что отключали iptables) лишнее закоментируйте и запустите iptables.
Это включит NAT в сторону VPN и исключит необходимость серверу-получателю знать про маршрутизацию в вашу сетку. Ему хватит роута который добавил VPN сервер. Если заработает — значит проблема в маршрутизации на стороне сервера.

[Abdus]

@younghacker Интересная ситуация.... вчера, когда я говорил, что пинг 1 раз идет было так. Я работал из дома я видел, что пинг идет 1 раз, tcpdump писал, что есть request и есть reply, стабильно только 1 раз. Может это было связанно что вчера я из дома сам по openvpn подключался.

Сегодня же в эфире есть есть только request. Ответа нет. Включил NAT, пинг идет

12:29:06.342370 IP 192.168.251.25 > 192.168.250.102: ICMP echo request, id 38152, seq 4, length 64
12:29:06.402197 IP 192.168.250.102 > 192.168.251.25: ICMP echo reply, id 38152, seq 4, length 64

.
Выключил - не идет.

tcpdump -i tun0 proto  ICMP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
12:07:32.998919 IP 192.168.243.1 > 192.168.250.102: ICMP echo request, id 29704, seq 73, length 64

в дампе же на интерфейсе сервера openvpn в это время тишина

[younghacker]

Вы не написали, что говорит tcpdump на стороне сервера.
По ощущению если с NAT-ом пинг работает а без него нет значит скорее всего на сервере нет маршрута в вашу сеть.

Поясню.
На сервере в директории /etc/openvpn/ccd должен лежать файлик который описывает маршрут в вашу сеть. Имя файла должно совпадать с CommonName сертификата вашего хоста-клиента vpn (дубликаты CN не подойдут! тоесть сертификат уникальный)
Содержимое файла по-моему должно быть для вас таким:
iroute 192.168.243.0 255.255.255.0
ifconfig-push 192.168.251.25 192.168.251.26

В конфиге OpenVPN сервера должна быт опция
client-config-dir ccd

После этого рестартануть OpenVPN сервер. Он должен будет подхватить конфиг. После соединения клиента он должен создать маршрут в вашу сетку на стороне openvpn сервера.

Для проверки можете прописать маршрут руками.
ip route add 192.168.243.0/24 via 192.168.251.25 dev tunX
Пинги должны забегать без NAT.

[younghacker]

ой не увидел. про сторону сервера. это странно.

[younghacker]

Если tcpdump полностью молчит на стороне сервера либо ошибка (не тот интерфейс или фильтр) или vpn не установился (включите уровень логирования vpn verbose 6 и посмотрите в лог vpn).
Также стоит посмотреть на стороне сервера iptables. Может там режется с левым по его мнению адресом 192.168.243.0/24

Посмотрите адрес интерфейса сервера и пинганите его со стороны клиента без указания адреса источника. Пинг пойдёт между адресами VPN туннеля. Сервер должен ответить если firewall не запрещает и если VPN поднят.

Также на том сервере должен быть включён роутинг в ядре.

[Abdus]

Проблема решена. На стороне сервера все было в порядке. Проблема оказалась в том что между этим ВПН и сервером был еще один ВПН. После его отключения маршруты все заработали. Пока решал проблему разобрался в роутинге на линукс наконец. Спасибо огромное за помощь )