LINUX.ORG.RU
ФорумAdmin

Forward между двумя tun интерфейсами

 ,


0

0

Здравствуйте, подскажите, возможен ли такой вариант внутри одного сервера? Бьюсь уже неделю, не выходит.

# ifconfig eth0 Link encap:Ethernet HWaddr 00:50:56:9b:7d:01 inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

eth1 Link encap:Ethernet HWaddr 00:50:56:9b:8b:b9 inet addr:xxx.xxx.xxx.xxx Bcast:xxx.xxx.xxx.xxx Mask:255.255.255.0 inet6 addr: fe80::250:56ff:fe9b:8bb9/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1424440 errors:0 dropped:0 overruns:0 frame:0 TX packets:441667 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:784434763 (748.0 MiB) TX bytes:45942510 (43.8 MiB)

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:26 errors:0 dropped:0 overruns:0 frame:0 TX packets:26 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2072 (2.0 KiB) TX bytes:2072 (2.0 KiB)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.188.0.1 P-t-P:10.188.0.1 Mask:255.255.255.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.10.20.8 P-t-P:10.10.20.8 Mask:255.255.255.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Строку происал net.ipv4.ip_forward=1

В iptables все открыл

wireshark при пинге вот что показывает 9 6.000388000 00:ff:0e:00:9c:6d Broadcast ARP 42 Who has 10.10.20.1? Tell 10.188.0.4 И все.

tcpdump на сервере на интерфейсе tun0 вообще никакой активности не показывает, за исключением, когда пингуешь ip tun0

Извините за корявое форматирование текста

serafimk ()

Опишите исходную задачу, как можно более детально.
Hint: ваши попытки и фантазии на тему её решения это не описание задачи

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

Спасибо, что откликнулись. Задача казалось простой. Сервер Debian выступает одновременно в роли сервера и клиента OpenVPN. Надо чтобы трафик ходил между удаленными подключениями 10.10.1.4 и 10.188.0.1.

Debian --------------- ---клиент OpenVPN-------|Сервер OpenVpn | 10.188.0.4 |10.188.0.1 | Windows OS |Клиент OpenVPN |-------Сервер OpenVPN |10.10.20.8 | 10.10.20.1 --------------- Windows OS Конфиг Клиент 10.188.0.4

dev tun proto udp remote x.x.x.x port 11194 client resolv-retry infinite nobind persist-key persist-tun ca ca1.crt cert user.crt key user.key ns-cert-type server comp-lzo log openvpn.log tls-client tls-auth ta.key 1 auth MD5 cipher DES-EDE3-CBC verb 3 auth-user-pass

Конфиг Сервер 10.188.0.1 tmp-dir /etc/openvpn/tmp port 11194 proto udp dev tun ca /etc/openvpn/ca.crt cert /etc/openvpn/server.crt key /etc/openvpn/server.key dh /etc/openvpn/dh2048.pem server 10.188.0.0 255.255.255.0 ifconfig-pool-persist /etc/openvpn/ipp.txt push «route 10.10.20.0 255.255.255.0» keepalive 10 60 tls-server tls-auth /etc/openvpn/ta.key 0 tls-timeout 120 auth MD5 cipher DES-EDE3-CBC comp-lzo persist-key persist-tun script-security 3 system status openvpn-status.log log /etc/openvpn/openvpn_server.log verb 6 auth-user-pass-verify /etc/openvpn/auth.pl via-file topology subnet

Конфиг Клиент 10.10.20.8 client dev tun proto udp remote x.x.x.x ca /etc/openvpn/cag20.crt cert /etc/openvpn/userg20.crt key /etc/openvpn/userg20.key tls-auth /etc/openvpn/tag20.key 1 verb 3 auth-user-pass status /etc/openvpn/openvpn-status_G20.log log /etc/openvpn/openvpn_G20.log

Конфиг Сервер OpenVPN 10.10.20.1 dev tun server 10.10.20.0 255.255.255.0 tls-server ifconfig-pool-persist ./ipp.txt 600000 ca ./ca.crt cert ./server.crt key ./server.key dh ./dh2048.pem tls-auth ./ta.key 0 keepalive 10 60 script-security 3 verb 3 status openvpn-status.log auth-user-pass-verify ./auth.vbs topology subnet log openvpn_server.log

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

Что же с форматированием, совсем не читабельное, сейчас попробую поправить

serafimk ()

интересные туннели 10.188.0.1 P-t-P:10.188.0.1 и 10.10.20.8 P-t-P:10.10.20.8. А смысл ?

«ip tu» это вторая часть конфигурации туннелей. Без нее трудно понять что у тебя за туннели.

Маршруты через эти туннели есть ? Без них трафик туда не пойдет.

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

Это дает параметр в конфигах сервера topology subnet, вот без него

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.188.0.1 P-t-P:10.188.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.10.20.10 P-t-P:10.10.20.9 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:252 (252.0 B) TX bytes:252 (252.0 B)

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

Маршруты через эти туннели есть ? Без них трафик туда не пойдет.

Вот вся маршрутизация

Это на клиенте 10.188.0.6 (убрал topology subnet, ip поменялся)

Сетевой адрес Маска сети Адрес шлюза 10.10.20.0 255.255.255.0 On-link 10.188.0.6 21 10.10.20.0 255.255.255.0 10.188.0.5 10.188.0.6 20

На сервере 10.10.20.1 Сетевой адрес Маска сети Адрес шлюза 10.188.0.0 255.255.255.0 10.10.20.1 1

Debian route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.188.0.2 * 255.255.255.255 UH 0 0 0 tun0 10.10.20.1 10.10.20.9 255.255.255.255 UGH 0 0 0 tun1 10.10.20.9 * 255.255.255.255 UH 0 0 0 tun1 10.188.0.0 10.188.0.2 255.255.255.0 UG 0 0 0 tun0

ip route 10.188.0.2 dev tun0 proto kernel scope link src 10.188.0.1 10.10.20.1 via 10.10.20.9 dev tun1 10.10.20.9 dev tun1 proto kernel scope link src 10.10.20.10 10.188.0.0/24 via 10.188.0.2 dev tun0

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

Вот схема

Сервер Debian выступает одновременно в роли сервера и клиента OpenVPN.
Надо чтобы трафик ходил между удаленными подключениями 10.10.1.4 и 10.188.0.1.

                            Debian
                         ---------------
 ---клиент OpenVPN-------|Сервер OpenVpn | 
     10.188.0.4          |10.188.0.1     |
      Windows OS         |Клиент OpenVPN |-------Сервер OpenVPN
                         |10.10.20.8     |         10.10.20.1
                          ---------------           Windows OS


Конфиг Клиент 10.188.0.4
 dev tun
 proto udp
 remote x.x.x.x 
 port 11194
 client
 resolv-retry
 infinite
 nobind
 persist-key
 persist-tun
 ca ca1.crt
 cert user.crt
 key user.key
 ns-cert-type server
 comp-lzo
 log openvpn.log
 tls-client
 tls-auth ta.key 1
 auth MD5
 cipher DES-EDE3-CBC
 verb 3 
 auth-user-pass

Конфиг Сервер 10.188.0.1
 tmp-dir
 /etc/openvpn/tmp
 port 11194
 proto udp
 dev tun
 ca /etc/openvpn/ca.crt
 cert /etc/openvpn/server.crt
 key /etc/openvpn/server.key
 dh /etc/openvpn/dh2048.pem
 server 10.188.0.0 255.255.255.0
 ifconfig-pool-persist /etc/openvpn/ipp.txt
 push «route 10.10.20.0 255.255.255.0»
 keepalive 10 60
 tls-server
 tls-auth /etc/openvpn/ta.key 0
 tls-timeout 120
 auth MD5
 cipher DES-EDE3-CBC
 comp-lzo persist-key
 persist-tun
 script-security 3 system
 status openvpn-status.log
 log /etc/openvpn/openvpn_server.log
 verb 6
 auth-user-pass-verify /etc/openvpn/auth.pl via-file
 topology subnet

Конфиг Клиент 10.10.20.8
 client dev
 tun proto
 udp remote x.x.x.x
 ca /etc/openvpn/cag20.crt
 cert /etc/openvpn/userg20.crt
 key /etc/openvpn/userg20.key
 tls-auth /etc/openvpn/tag20.key
 1 verb 3 auth-user-pass
 status /etc/openvpn/openvpn-status_G20.log
 log /etc/openvpn/openvpn_G20.log

Конфиг Сервер OpenVPN 10.10.20.1
 dev tun
 server 10.10.20.0 255.255.255.0
 tls-server
 ifconfig-pool-persist ./ipp.txt 600000
 ca ./ca.crt
 cert ./server.crt
 key ./server.key
 dh ./dh2048.pem
 tls-auth ./ta.key 0
 keepalive 10 60
 script-security 3
 verb 3
 status openvpn-status.log
 auth-user-pass-verify ./auth.vbs
 topology subnet
 log openvpn_server.log

serafimk ()
Ответ на: Вот схема от serafimk

Re: Вот схема

Если не требуется прям разных подсетей - объедини tun/tap'ы в бридж и не парь людям моск.

Строку прописал net.ipv4.ip_forward=1

Куда прописал? В файлик - мало, он применится автоматом только после перезагрузки, включи вручную: sysctl -w net.ipv4.ip_forward=1

На клиенте 10.188.0.4 должен быть маршрут 10.10.20.1/24 via 10.188.0.1.

На «сервере» 10.10.20.1 тоже должен быть маршрут до сети 10.188.0.0/24 или какая она там, иначе «сервер» не будет знать, куда отправлять ответные пакеты.

anonymous ()
Ответ на: Re: Вот схема от anonymous

Маршруты есть. Эта схема вообще имеет право на жизнь?

serafimk ()

Включить forwad, в iptables разрешить FORWARD между 2-я подсетями. ip ro ls показать тут.

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

ip ro ls показать тут

Debian route Kernel IP routing table
Destination	 Gateway	 Genmask		Flags 	Metric 	Ref	Use	 Iface 
10.188.0.2	 * 		255.255.255.255 	UH 	0 	0 	0 	 tun0
10.10.20.1       10.10.20.9     255.255.255.255         UGH     0       0       0 	 tun1
10.10.20.9	 *		255.255.255.255		UH	0	0	0	 tun1
10.188.0.0 	10.188.0.2	255.255.255.0 		UG	0	0	0	 tun0

ip route
10.188.0.2 dev tun0 proto kernel scope link src 10.188.0.1
10.10.20.1 via 10.10.20.9 dev tun1
10.10.20.9 dev tun1 proto kernel scope link src 10.10.20.10
10.188.0.0/24 via 10.188.0.2 dev tun0
serafimk ()
Ответ на: комментарий от anonymous

Прописал все что можно

 iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A INPUT -i eth1 -p udp -m state --state NEW -m udp --dport 11194 -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -i tun1 -j ACCEPT
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i tun0 -o tun1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun1 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun1 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -i tun1 -j ACCEPT
-A OUTPUT -o tun+ -j ACCEPT
-A OUTPUT -o tun1 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

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

Конфиг Сервер OpenVPN 10.10.20.1 - не хватает
push «route 10.188.0.0 255.255.255.0»

Не совсем верно, получается что эта сеть лежит за 10.10.20.1, а должна лежать за Клиент 10.10.20.8. На 10.10.20.1 прописываю руками route add 10.188.0.0 mask 255.255.255.0 10.10.20.1.
Тcpdump на интерфейсах tun0 и tun1 вообще ничего не показывает, когда пытаюсь проверить связь между 10.188.0.6 и 10.10.20.8

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

sysctl -w net.ipv4.ip_forward=1 было сделано сразу при реализации задачи

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

откуда такая чудесная таблица машрутизации ?

vel ★★★★★ ()

Спасибо всем за участие в обсуждении. Вопрос решил. Forward между двумя tun интерфейсами работает. Проблема была в маршрутизации.

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