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

Openvpn

 , ,


0

1

Помогите разобраться.

Есть две сети соединенные через openvpn:
10.8.0.1 сервер openvpn debian (за ним лок сеть 192.168.1.0/24)
10.8.0.9 клиент openvpn роутер ASUS RT-N66U (за ним сеть 192.168.2.1/24)
10.8.0.3 клиент openvpn без сети

[192.168.2.0/24===10.8.0.9]-----{internet}-----[10.8.0.1===192.168.1.0/24]

[10.8.0.3]
При этом :

1. С адреса 10.8.0.9 (и с адресов локальной сети 192.168.2.0/24) видны все компьютеры (как 10.8.0.3, так и 10.8.0.1(включая локальную сеть 192.168.1.0/24)
2. С адреса 10.8.0.3 видны тоже все машины как за сервером, так и за клиентом.
2. а вот с сервера ни видно клиента 10.8.0.9, но виден клиент 10.8.0.3. Пинг к 10.8.0.9 просто повисает.

Настройки сервера такие (оставил лишь нужную часть):

push "route 192.168.1.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"
client-config-dir ccd
route 192.168.2.0 255.255.255.0
push "dhcp-option DNS 8.8.8.8"
client-to-client
;duplicate-cn
в папке ccd для клиента 10.8.0.9 такие настройкии:
ifconfig-push 10.8.0.9 255.255.255.0
iroute 192.168.2.0 255.255.255.0

Я бы понял, если никто не видел сеть за клиентом 10.8.0.9, но почему один видит другой нет? правила в фаерволе такие:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -p udp -m udp --dport 1194 -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -s 10.8.0.0/24 -p tcp -m tcp -j ACCEPT
iptables -A INPUT -s 10.8.0.0/24 -p udp -m udp -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -p udp -m udp -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -p tcp -m tcp -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -p icmp -j ACCEPT
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -s 192.168.1.0/24 -p udp -m multiport --ports 53 -j ACCEPT
iptables -A FORWARD -s 192.168.1.0/24 -p tcp -m multiport --ports 53,80,8080,443,993,465,587,110,21,22,25 -j ACCEPT



Последнее исправление: dukenukem (всего исправлений: 1)

Пинг к 10.8.0.9 просто повисает

В смысле «повисает»? Запросы-то шлёт? И покажи вывод ip route на сервере. Прошивка на роутере какая?

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

На запросов, ни ответов.

PING 10.8.0.9 (10.8.0.9) 56(84) bytes of data.
^C
--- 10.8.0.9 ping statistics ---
40 packets transmitted, 0 received, 100% packet loss, time 39496ms
Вывод ip route такой
default via {ext_ip} dev enp2s0
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
{ext_ip}/24 dev enp2s0 proto kernel scope link src {ext_ip}
192.168.1.0/24 dev enp1s0 proto kernel scope link src 192.168.1.1
192.168.2.0/24 via 10.8.0.2 dev tun0
На роутере Merlin, последняя.

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

Можно.Такая. Почему два дефолта, не понимаю.

{ext_ip}	10.99.0.1	255.255.255.255	UGH	1	0	0	MAN
10.200.100.1	*		255.255.255.255	UH	0	0	0	WAN
192.168.2.0	*		255.255.255.0	U	0	0	0	LAN
192.168.1.0	10.8.0.1	255.255.255.0	UG	0	0	0	tun11
10.8.0.0	*		255.255.255.0	U	0	0	0	tun11
192.168.0.0	10.8.0.1	255.255.255.0	UG	0	0	0	tun11
10.99.0.0	*		255.255.0.0	U	0	0	0	MAN
default		10.200.100.1	0.0.0.0		UG	0	0	0	WAN
default		10.99.0.1	0.0.0.0		UG	1	0	0	MAN

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

Зашел черз ssh на роутер, в более привычном формате:

{ext_ip} via 10.99.0.1 dev eth0  metric 1
10.200.100.1 dev ppp0  proto kernel  scope link
192.168.2.0/24 dev br0  proto kernel  scope link  src 192.168.2.1
192.168.1.0/24 via 10.8.0.1 dev tun11
10.8.0.0/24 dev tun11  proto kernel  scope link  src 10.8.0.9
192.168.0.0/24 via 10.8.0.1 dev tun11
10.99.0.0/16 dev eth0  proto kernel  scope link  src 10.99.5.218
127.0.0.0/8 dev lo  scope link
default via 10.200.100.1 dev ppp0
default via 10.99.0.1 dev eth0  metric 1

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

а tcpdump-а на роутере нет случайно? Запустить на нем и на сервере и посмотреть что куда недоходит.

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

Спасибо за подсказку!!
Подключил клиентом обычную машину с debian, результат такой же нет пинга(и ssh тоже) с сервера в сторону клиента, с клиента пинг (и ssh) есть.

Попробовал tcpdump. Что выяснилось.

Первый вариант:
1. Запускаем tcpdump на самом сервере (10.8.0.1)
2. Запускаем tcpdump на клиенте (10.8.0.9)
3. Пингуем с машины из сети сервера сам клиент.
4. tcpdump на сервере не видит ответ, запрос виден. Tcpdump на клиенте не видит даже запрос.

Второй вариант:
1. Запускаем tcpdump на самом сервере
2. Запускаем tcpdump на клиенте
3. Пингуем с машины (192.168.1.2) из сети сервера, машину из сети клиента (192.168.0.2)
4. TCPdump на сервере видит запросы, но не видит ответы.
5. TCPdump на клиенте видит и запросы и ответы.

При этом имеет значение какой интерфейс указать tcpdump.

Когда указываю внешний интерфейс на сервере ни видны ни какие запросы/ответы. Указав интерфейс внутренний сети ситуация, описанная выше.

При этом разумеется пинг, например яндекса виден на внешнем интерфейсе.

Получается, что где-то на сервере ответы пропадают.

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

Сервер видит исходящие запросы, клиент ничего не видит.

tcpdump запущен на сервере: tcpdump -i tun0 -tn icmp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
IP {ext_ip} > 10.8.0.9: ICMP echo request, id 18047, seq 1, length 64
IP {ext_ip} > 10.8.0.9: ICMP echo request, id 18047, seq 2, length 64
IP {ext_ip} > 10.8.0.9: ICMP echo request, id 18047, seq 3, length 64
IP {ext_ip} > 10.8.0.9: ICMP echo request, id 18047, seq 4, length 64

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

Да, верно. в iptables есть правило:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source {ext_ip}
Так как в настройках openvpn для клиента стоит

push «redirect-gateway def1 bypass-dhcp»

Нужно что бы весь трафик шел через openvpn-сервер.

Если правило убрать, все пингуется и все видят друг-друга. Но нет доступа в интернет.

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

Заменил это правило

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source {ext_ip}

на

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT MASQUERADE

Все стало работать, но это же менее производительно или по другому просто не получиться сделать?

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

Отличие маскарадинга от сната лишь в том, что последний подставляет указанный адрес, а маскарадинг — тот, который у машины. Влияния на производительность, насколько мне известно, замена одного на другой не несёт.

// Я ещё опцию --random добавляю обычно

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source {ext_ip}

Интерфейс добавьте и будет как надо.

но это же менее производительно

Давно не актуально.

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

Спасибо! Все заработало!

Так и знал, что проблема к какой-нибудь мелочи!

dukenukem
() автор топика
Последнее исправление: dukenukem (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.