Особенности роутинга в CentOS или рассказ о кривых руках. Что я делаю не так?

Question

[greefon]

Дано

Есть две сети: 192.168.3.0/24 и 192.168.10.0/24. Назовем их, для удобства, сеть А и сеть Б.

В сети А роль шлюза выполняет машинка на CentOS, имеющая два физических интерфейса: eth0 (Интернет, белый IP) и eth1 (3.1, LAN). Default gateway, что вполне очевидно, eth0.

В сети Б шлюзом является DLink 250.

Нужно объединить эти две сети с помощью OpenVPN. На данный момент сервером является DLink 250, в качестве локальной сети указана 10.0, в качестве удаленной 3.0. Клиентом выступает CentOS, соединение устанавливается штатно, появляется новый интерфейс tun0 (свой IP 128.10.0.6, IP другого конца 128.10.0.5). В таблице маршрутизации появляются три новых маршрута:
— маршрут к 128.10.0.5 через tun0,
— маршрут к сети 128.10.0.0 через 128.10.0.5 и tun0
— маршрут к сети 192.168.10.0 через 128.10.0.5 и tun0

Проблема

С интерфейса 128.10.0.6 сеть Б прекрасно пингуется. Но, если пытаться пинговать ее с интерфейса 3.1 или вообще из сети А — пакет дохнет где-то после PREROUTING. Он не появляется ни на одном из интерфейсов, кроме входящего, и не отлавливается ни в одном правиле, кроме PREROUTING. Такое ощущение, что ядро эти пакеты молча выбрасывает в мусор.

ЧЯДНТ?

Comments

[greefon]

Еще раз уточню, OpenVPN тут, насколько я понимаю, вообще не при чем. Проблема с тем, что роутинг не работает. Если я меняю выход для пакета на интерфейс eth0, например, он все равно после PREROUTING исчезает. Такое ощущение, что именно эта целевая сеть «особенная». При этом, для других случаев — все ок

[greefon]

Причина обнаружена. Админ сервера пытался сначала сделать туннель IPSEC через racoon. Не получилось. Тогда он переключился на OpenVPN. При этом, не смотря на наличие отсутствия IPSEC тоннеля и убитый процесс енота SPD вполне себе оставались живы и ядро честно пыталось отправить пакет туда, откуда солнце не светит. После setkey -FP пакеты полетели туда, куда полагается, т.е. в tun0.

Answer 1

[greefon]

Причина обнаружена. Админ сервера пытался сначала сделать туннель IPSEC через racoon. Не получилось. Тогда он переключился на OpenVPN. При этом, не смотря на наличие отсутствия IPSEC тоннеля и убитый процесс енота SPD вполне себе оставались живы и ядро честно пыталось отправить пакет туда, откуда солнце не светит. После setkey -FP пакеты полетели туда, куда полагается, т.е. в tun0.

Всем ответившим огромная благодарность (и не только) за человеческое участие.

Answer 2

[pcdesign]

Наверное, стоит выложить результаты команд

ifconfig
ip r
iptables -nvL
iptables -t nat -nvL

Конфиги и логи опенвпн.
И вам помогут быстрее.

Ну а если лень, то попробуйте просто послушать что там происходит, например так:

ngrep -W byline -d tun0 host xxx.xxx.xxx.xx and port xxxx

P.S. И вы не забыли сделать так

echo "1" > /proc/sys/net/ipv4/ip_forward

Или более глобально в файле /etc/sysctl.conf в строке

net.ipv4.ip_forward = 1

Comments

[Dormidont]

Плюсую net.ipv4.ip_forward = 1

[greefon]

Выложить я, конечно, могу. Но, во первых, вывод того же iptables размером с две простыни будет, а во вторых, всю полезную информацию я уже, кажется дал. Повторюсь:
1. Роутинг работает. Например, пользователи LAN прекрасно маскарадятся в WAN (Не совсем роутинг), а если из сети A пинговать конце тоннеля в сети Б, то я вижу, что пакетики попадают в тоннель.
2. /proc/sys/net/ipv4/ip_forward — тут уже единичка
3. вывод ip r

172.16.1.5 dev tun0 proto kernel scope link src 172.16.1.6
XX.XX.XX.XX/30 dev eth0 proto kernel scope link src XX.XX.XX.YY
192.168.3.0/24 dev eth1 proto kernel scope link src 192.168.3.1
172.16.1.0/24 via 172.16.1.5 dev tun0
192.168.10.0/24 via 172.16.1.5 dev tun0
169.254.0.0/16 dev eth1 scope link
default via XX.XX.XX.XX dev eth0

4. во всех цепочках iptables (включая таблицу nat) первое правило — журналировать все icmp пакеты. Простыни того же FORWARD выкладывать смысла не вижу, все равно до внутренних правил дело не доходит, в логах пусто. Если интересует что-то конкретное — могу выложить это куском.
5. Интерфейсы я слушаю tcpdump'ом. В туннель пакет не приходит.

[greefon]

Конфиги сервера выложить не могу, там веб интерфейс. Конфиги клиента абсолютно стандартные, да и туннель работает, с конца туннеля пингуется сеть за других концом.

[greefon]

XX и YY это внешние белые IP

[pcdesign]

А как там SELinux наш любимый поживает?

[greefon]

SELINUX=disabled

Answer 3

[ivnik]

Может добавить в таблицу маршрутизации маршрут к 192.168.3.0 через 128.10.0.5 и tun0?

Comments

[greefon]

зачем?

[ivnik]

Неправильно понял схему сети. А какие правила в цепочке FORWARD? Может там режется?

[greefon]

Пакет в FORWARD не появляется вообще. Равно как и в INPUT.

Answer 4

[ivnik]

Покажите тогда правила iptables

Comments

[greefon]

Зачем? Во всех цепочках сейчас первым правилом стоит логирование ICMP пакетов. Дело не в том, что они где-то в цепочке отбрасываются, дело в том, что они после PREROUTING исчезают.

Answer 5

[smartlight]

стоит выбрать сеть класса С для openvpn ибо

whois 128.10.0.5
#
# Query terms are ambiguous.  The query is assumed to be:
#     "n 128.10.0.5"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=128.10.0.5?showDetails=true&showARIN=false&e                                                                                             xt=netref2
#

NetRange:       128.10.0.0 - 128.10.255.255
CIDR:           128.10.0.0/16
OriginAS:
NetName:        PURDUE-CS-EN
NetHandle:      NET-128-10-0-0-1
Parent:         NET-128-0-0-0-0
NetType:        Direct Assignment
RegDate:        1984-08-01
Updated:        2009-06-19
Ref:            http://whois.arin.net/rest/net/NET-128-10-0-0-1

OrgName:        Purdue University
OrgId:          PURDUE
Address:        Information Technology
Address:        155 S. Grant Street
City:           West Lafayette
StateProv:      IN
PostalCode:     47907-2114
Country:        US
RegDate:
Updated:        2010-09-20
Ref:            http://whois.arin.net/rest/org/PURDUE

OrgNOCHandle: PNOC-ARIN
OrgNOCName:   Purdue Network Operations Center
OrgNOCPhone:  [phone]
OrgNOCEmail:  [e-mail]
OrgNOCRef:    http://whois.arin.net/rest/poc/PNOC-ARIN

OrgAbuseHandle: PUISP-ARIN
OrgAbuseName:   Purdue University STEAM-CIRT
OrgAbusePhone:  [phone]
OrgAbuseEmail:  [e-mail]
OrgAbuseRef:    http://whois.arin.net/rest/poc/PUISP-ARIN

OrgTechHandle: PURDU-ARIN
OrgTechName:   Purdue Hostmaster
OrgTechPhone:  [phone]
OrgTechEmail:  [e-mail]
OrgTechRef:    http://whois.arin.net/rest/poc/PURDU-ARIN

RTechHandle: DT50-ARIN
RTechName:   Trinkle, Daniel
RTechPhone:  [phone]
RTechEmail:  [e-mail]
RTechRef:    http://whois.arin.net/rest/poc/DT50-ARIN

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#

Comments

[greefon]

заменил на 172.16.1.0/24, не помогло

Answer 6

[smartlight]

В спеках к Д-линку не указано, что он умеет openvpn.

Comments

[greefon]

он умеет
DSR-250N

Answer 7

[smartlight]

плз вывод: ip ro на 3.1

маршрут на сеть В передаете средствами openvpn?

конфиги сервера и клиента openvpn не помешают

Comments

[smartlight]

сорри вверху не увидел.

подозреваю, что проблемма в iptables.
сбросьте все политики в ACCEPT и попробуйте.
для тунеля главноый минимум это:
роутинг — он у вас есть
2. FORWARD ACCEPT
и всё

[greefon]

habrahabr.ru/qa/24981/#answer_101781

[greefon]

я не могу «сбросить», это боевой сервер, на нем люди сидят
кроме того, повторюсь еще раз, все цепочки начинаются с правила, которое пишет любой icmp пакетик в лог, после PREROUTING пакет не попадает ни в одну другую цепочку

Answer 8

[greefon]

вывод ip ro в комментах выше
маршрут (три маршрута, если быть точным) передается средствами openvpn

конфиг сервера показать не могу (там только веб-интерфейс), конфиг клиента:

client
nobind
remote ZZ.ZZ.ZZ.ZZ 1194
proto udp
resolv-retry infinite
dev tun
log /etc/openvpn/openvpn.log
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/1.crt
key /etc/openvpn/1.key
cipher AES-128-CBC
auth SHA1
verb 7
route-delay 6

Answer 9

[alz]

Не вижу этому предпосылок, но попробуйте

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter

Comments

[greefon]

предпосылок я тоже не вижу, но уже пробовал :) нулевой эффект
не написал про это, т.к. вроде как чистое шаманство, относительно данного случая

[greefon]

да, впн тут совсем не виноват
убил маршрут в сеть Б, сделал заново, указав в качестве выхода WAN интерфейс и гейтвей за ним
так же дохнет после PREROUTING

Answer 10

[smartlight]

тогда сделайте наоборот.
центос сервером а длинк клиентом и посмотрите

Comments

[greefon]

Я попробую. Но, как мне кажется, дело вообще не в OpenVPN. Какая собственно разница, ну поднимет интерфейс сервер, а не клиент. Почему роутинг то после этого должен заработать?

[greefon]

да, впн тут совсем не виноват
убил маршрут в сеть Б, сделал заново, указав в качестве выхода WAN интерфейс и гейтвей за ним
так же дохнет после PREROUTING

[smartlight]

так а маршрут в Б вы руками делаете?
это не правильно.
openvpn сам умеет.
серверная опция client-config-dir

[greefon]

Выше написано, что автоматом. Руками я его прибил и другой сделал, для эксперимента.

Answer 11

[smartlight]

тогда берите еще комп, который сделайте клиентом и тестируйте там

Comments

[greefon]

На другом компе такой проблемы нет. CentOS настраивал не я, тонкостей я про него не знаю, но что-то там явно не так.