LINUX.ORG.RU
решено ФорумAdmin

Проблемы с маршрутами

 ,


0

1

Доброго времени суток.
Возникли проблемы с настройкой маршрутов, на двух компутерах.
есть два компьютера они соединены между собой по openVPN, за одним из них есть сеть. Необходимо, чтоб клиент видел сеть за сервером.
Подключено так:
клиент (tun0:10.0.2.6) <->(tun0:10.0.2.1) сервер (eth0:10.0.1.1) <-> локальная сеть

сервер > netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
0.0.0.0 10.23.48.1 0.0.0.0 UG 0 0 0 eth1
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.2.0 10.0.2.2 255.255.255.0 UG 0 0 0 tun0
10.0.2.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.23.48.0 0.0.0.0 255.255.248.0 U 0 0 0 eth1
95.24.32.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0

клиент > netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth0
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.0.2.0 10.0.2.5 255.255.255.0 UG 0 0 0 tun0
10.0.2.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.0.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0

С клиента пингуется 10.0.1.1 , но дальше не идет. Делал
route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.0.1.1
результатов не дало. Трасировка до любого хоста из 10.0.1.0/24 заканчивается на 10.0.2.1. Дальше никак.

Подскажите, где у меня ошибка.
Заранее благодарен.

Ну судя по маршрутам, все ок. Кто является шлюзом для компов в локалке?
Если 10.0.1.1 - то тут два варианта или fw на шлюзе или возможно вы вин клиентов пингуете. Если вин клиентов то это виндовый fw блокирует. Один из вариантов замаскарадить адреса впн сети на 10.0.1.1
Если не 10.0.1.1 - то прописать на шлюзе роутинг до 10.0.2.0 через 10.0.1.1, или замаскарадить адреса впн сети на 10.0.1.1.
А вообще посмотрите пакеты с eth0 при пинге уходят?

anc ★★★★★ ()

Мне помог вот этот мануал:

https://community.openvpn.net/openvpn/wiki/RoutedLans

При этом маршруты на «гейтах» (компах, что связывают локалки через ВПН) все равно пришлось добавлять руками.

Чтобы ходили пинги нужно, чтобы правильный маршрут был в обе стороны.

ien ()
Последнее исправление: ien (всего исправлений: 1)
Ответ на: комментарий от anc

клиент - 10.0.2.6 (tun0)
сервер - 10.0.2.1 (tun0), 10.0.1.1(eth0)

С машины, стоит в сети за сервером (10.0.1.2) пинг до 10.0.2.6 доходит.
iptables на сервере такой.
:INPUT DROP [434:41475]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -i ppp0 -p tcp -m tcp --dport XXXX -j ACCEPT
-A INPUT -i ppp0 -p tcp -m multiport --ports 49152:65535 -j ACCEPT
-A INPUT -p udp -m udp --dport YYYY -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -i eth0 -o ppp0 -j ACCEPT
-A FORWARD -i ppp0 -o eth0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i tun0 -o eth0 -j ACCEPT
-A FORWARD -i tun0 -o lo -j ACCEPT
-A FORWARD -i eth0 -o tun0 -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A OUTPUT -o tun0 -j ACCEPT
COMMIT
# Completed on Tue Aug 2 23:54:03 2016
# Generated by iptables-save v1.4.21 on Tue Aug 2 23:54:03 2016
*nat
:PREROUTING ACCEPT [408:48523]
:INPUT ACCEPT [42:2831]
:OUTPUT ACCEPT [73:4559]
:POSTROUTING ACCEPT [74:4643]
-A POSTROUTING -s 10.0.1.0/24 -o ppp0 -j MASQUERADE
-A POSTROUTING -s 10.0.2.0/24 -o tun0 -j MASQUERADE
COMMIT

По идее ничего не должно блокировать

telepuz ()
Ответ на: комментарий от telepuz

Вы так и не ответили «Кто является шлюзом для компов в локалке?»
Также читайте все что я написал выше. Посмотрите tcpdump на eth0, что с пакетами?

А вот это у вас зачем? -A POSTROUTING -s 10.0.2.0/24 -o tun0 -j MASQUERADE
Еще раз прочитайте вот это «Если вин клиентов то это виндовый fw блокирует.»

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

шлюзом является 10.0.1.1
пингую коммутатор за шлюзом 10.0.1.254, tcpdump показывает, что запросы icmp приходят, а ответа нету.

Правило то по ошибке было добавлено, оно не влияет. Убрал его

telepuz ()
Ответ на: комментарий от telepuz

Вы написали «коммутатор» я хз что это, но как раз по этой причине и предполагаю нормальное поведение, блокировка доступа из других подсетей.

anc ★★★★★ ()
Ответ на: комментарий от anc

Проблема одна, устройства которые блокируют доступ не из локалки. Варианты решения соответствующие, 1. настроить устройства что бы не блокировали. 2. То, что вы уже сделали, тут нюанс, маскарад, т.е. если нужно на устройстве еще отслеживать кто конкретно обращается не прокатит. Имхо для вашей схемы первого варианта хватит вполне.

anc ★★★★★ ()
Ответ на: комментарий от telepuz

Имхо вот так лучше
iptables -t nat -A POSTROUTING -i tun0 -o eth0 -s 10.0.2.0/24 -j MASQUERADE
или если сеть не волнует то
iptables -t nat -A POSTROUTING -i tun0 -o eth0 -j MASQUERADE

anc ★★★★★ ()
Ответ на: комментарий от anc

iptables -t nat -A POSTROUTING -i tun0 -o eth0 -j MASQUERADE
тут ругается на -i , говорит, что нельзя вместе с POSTROUTING использовать.

Мне просто доступ необходим до этой подсети. Отслеживать никого не надо. Этот вариант вполне устроит. Спасибо за помощь

telepuz ()
Ответ на: комментарий от telepuz

Действительно, чего это я. Конечно нельзя. Ступил. Думал-то об одном, написал о другом. Простите.

anc ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.