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

Не работает маршрутизация после OVPN

 , , ,


0

1

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

Собрана такая схема:

OVPNClient(172.10.0.6)-----(172.10.0.1)tun-S1-eth(2.2.2.1)-----(2.2.2.2)eth-S2

На S1: net.ipv4.ip_forward=1
На S2 прописан маршрут: 172.10.0.0/24 via 2.2.2.1
На клиенте прописант маршрут: 2.2.2.0/24 via 172.10.0.1
S1 и S2 - ubuntu server 16.04

С Клиента пингуется 2.2.2.1
С S2 пингуется 172.10.0.1

Запускаем с клиента ping 2.2.2.2, на S1 в tcpdump:

# tcpdump -nni any icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
00:00:29.152268 IP 172.10.0.6 > 2.2.2.2: ICMP echo request, id 1, seq 34391, length 40

На S2 в tcpdump при такой же команде совершенно ничего не видно

Ещё такой момент: у тебя OPVN работает в каком режиме: tap или tun? Во втором надо маршрут делать не через адрес сервера, а через парный адрес PPP-соединения

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

Во втором надо маршрут делать не через адрес сервера, а через парный адрес PPP-соединения

Не совсем верно. От топологиии зависит.

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

ЕМНИП, в tun не-PPP пока находится в экспериментальной стадии, поэтому условно считаю tun — PPP, а tap — обычной сетью

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

Везде стоят единички, кроме lo

cat /proc/sys/net/ipv4/conf/all/rp_filter
1

seregakhv
() автор топика
Ответ на: комментарий от XMs

Нат отсутствует(настройки докера не в счёт):

# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DOCKER all  — anywhere anywhere >ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DOCKER all  — anywhere !127.0.0.0/8 >ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all  — 172.17.0.0/16 anywhere
MASQUERADE all  — 172.18.0.0/16 anywhere

Chain DOCKER (2 references)
target prot opt source destination
RETURN all  — anywhere anywhere
RETURN all  — anywhere anywhere

seregakhv
() автор топика
Ответ на: комментарий от XMs

Работает через tun, Вопрос канала связи прозрачен для маршрутизации, лишь бы gw был доступен(если мы указываем gw в виде ip)

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

Спасибо тебе добрый человек!

Нашел проблему, была политика forward по умолчанию в drop - просмотрел среди цепочек докера:

# iptables -L FORWARD
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all  — anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all  — anywhere anywhere
ACCEPT all  — anywhere anywhere >ctstate RELATED,ESTABLISHED
DOCKER all  — anywhere anywhere
ACCEPT all  — anywhere anywhere
ACCEPT all  — anywhere anywhere
ACCEPT all  — anywhere anywhere >ctstate RELATED,ESTABLISHED
DOCKER all  — anywhere anywhere
ACCEPT all  — anywhere anywhere
ACCEPT all  — anywhere anywhere

Oсталось непонимание, зачем докер монопольно вписывает свои правила в forward, а не вносит конкретные правила для контейнеров, оставляя политику в accept.

Всем спасибо!

seregakhv
() автор топика
Ответ на: комментарий от XMs

Если рассматривать данный случай. Достаточно указания dev tunX без всякого via IP. IP здесь вообще роли не играет, кроме того факта что при выполнении ip route add без указания dev выбирается нужный интерфейс. Так вот в случае топологий p2p и subnet "...via 172.10.0.1" как раз и даст желаемый результат. В p2p это один из адресов P2P соединения, в subnet пофигу что указывать из выделяемой сети, а в случае net30 вам и не дадут указать 172.10.0.1. Итого: формулировку «На клиенте прописант маршрут: 2.2.2.0/24 via 172.10.0.1» можно считать верной в не зависимости от tun/tap или топологии.

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

Нат отсутствует
MASQUERADE all — 172.17.0.0/16 anywhere
MASQUERADE all — 172.18.0.0/16 anywhere

Но вообще мне понятней выхлоп iptables-save, тут могу путаться

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