Temat: Klient OpenVPN - Routowanie pomiędzy interface'ami

Cześć,

Dwa dni temu instalowałem i konfigurowałem swój router od nowa. Po zakończeniu tych działań, zauważyłem dziwny problem z OpenVPN. Sam serwer VPN działa bardzo dobrze, klienci z Windowsa, Androida i Linuxa nie mają żadnych problemów.

Przedstawie w skrócie swoją sieć:

1. OpenWRT 192.168.1.1/25 + Wan 192.168.1.211/29
2. Te dwie sieci tworzą jedną sieć 192.168.1.1/24 jednej lokalizacji, która jest routowana do VPN
3. Inne lokalizacje różnią się tylko cyfrą na trzecim oktecie
4. Wszystkie moje lokalizacje to 192.168.0-66.0, które są routowane do serwera VPN
5. Serwer VPN: 192.168.100.1
6. Dodatkowo router np. 192.168.1.1 w VPN dostępny jest jako pojedynczy klient vpn 192.168.100.11

Problem jest dosyć dziwny, pierwszy raz się z nim spotkałem, głównie dotyczy on ponownego uruchamiania routera. Na chwilę obecną zauważyłem, że gdy podczas uruchamiania wan połączy się wcześniej niż OpenVPN wszystko działa dobrze. Jeśli stanie się na odwrót, w logach OpenVPN czytam:

Restart pause, 5 second(s)
Restart pause, 5 second(s)
Initialization Sequence Completed

Wtedy najczęściej loguje się na router aby sprawdzić co się dzieje. Pierwsze co sprawdzam, to czy router w tunelu widzi sam siebie:

# ping 192.168.100.11
PING 192.168.100.11 (192.168.100.11): 56 data bytes
64 bytes from 192.168.100.11: seq=0 ttl=64 time=0.473 ms

Następnie sprawdzam, czy router widzi bramę VPN:

# ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
^C

Ale kiedy sprawdzę poprzez konkretny interface:

# ping -I tun0 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: seq=0 ttl=64 time=38.162 ms

Sprawdzam więc tablicę route'ingu, w której nie widzę żadnego problemu.

# route
Kernel IP routing table
Destination        Gateway             Genmask               Flags   Metric    Ref    Use       Iface
default              192.168.1.211    0.0.0.0                   UG       20        0        0       eth2
192.168.0.0       192.168.100.1    255.255.192.0        UG       0         0        0        tun0
192.168.1.0       *                       255.255.255.128     U         0         0        0        br-lan
192.168.1.208   *                       255.255.255.248     U        20        0        0         eth2
192.168.1.211   *                       255.255.255.255     UH       20        0        0        eth2
192.168.64.0     *                       255.255.192.0         U         0         0        0        tun0

I teraz najdziwniejsza kwestia: tak pozostawiony router, czasami po 15 minutach pracy, czasami po kilku godzinach pracy, zaczyna sam z siebie działać - tzn. ma połączenie z bramą, a kiedy ją ma to klienci routera mają pełny dostęp do sieci VPN 192.168.0-127.0

# ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: seq=0 ttl=64 time=38.162 ms

Firewall otwarty w każdą możliwą stronę.
Proszę Was o pomoc, nie mam już pomysłów co mógłbym jeszcze sprawdzić.

2

Odp: Klient OpenVPN - Routowanie pomiędzy interface'ami

Po prostu restartuj openvpn na hotplugu jak wstanie wan. Proste i skuteczne rozwiązanie.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

3

Odp: Klient OpenVPN - Routowanie pomiędzy interface'ami

Cezary napisał/a:

Po prostu restartuj openvpn na hotplugu jak wstanie wan

Rozwiniesz, co masz na myśli? Chodzi Ci o dopisanie odpowiednich komend w init.d ?
W pierwszym poście zapomniałem dopisać, ze "service openvpn restart" nie pomaga...
Muszę albo restartować router do skutku, albo czekać aż zacznie mi pingować brama vpn

4

Odp: Klient OpenVPN - Routowanie pomiędzy interface'ami

O takim skrypcie: https://github.com/ericpaulbishop/gargo … 27-openvpn w np. w pliku etc/hotplug.d/iface/27-openvpn

Ale jeżeli restart openvpn nie pomaga to problem masz chyba w innym miejscu a nie w restarcie wanu.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

5 (edytowany przez tinware 2019-03-17 14:15:00)

Odp: Klient OpenVPN - Routowanie pomiędzy interface'ami

Udało mi się wprowadzić router znowu w ten błąd, tym razem dopiero kiedy odłączyłem go fizycznie od zasilania.
Restart "/etc/init.d/openvpn restart" nic nie pomaga, stąd wnioskuje, że opóźnienie o 15 sekund też nic nie pomoże.
Co mogę jeszcze sprawdzić? Powoli kończą mi się pomysły...

Wrzucę jeszcze loga z połączenia klienta:

Sun Mar 17 14:06:40 2019 OpenVPN 2.4.4 mips-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sun Mar 17 14:06:40 2019 library versions: OpenSSL 1.0.2q  20 Nov 2018, LZO 2.10
Sun Mar 17 14:06:40 2019 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Sun Mar 17 14:06:40 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:1194
Sun Mar 17 14:06:40 2019 Socket Buffers: R=[163840->163840] S=[163840->163840]
Sun Mar 17 14:06:40 2019 UDP link local: (not bound)
Sun Mar 17 14:06:40 2019 UDP link remote: [AF_INET]XXX.XXX.XXX.XXX:1194
Sun Mar 17 14:06:40 2019 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:1194, sid=289872b2 c3da81f8
Sun Mar 17 14:06:40 2019 VERIFY OK: depth=1, C=PL, ST=Mazowieckie, L=Warszawa, O=Serwer, OU=Serwer, CN=Serwer CA, name=server, emailAddress=admin@example.com
Sun Mar 17 14:06:40 2019 VERIFY OK: nsCertType=SERVER
Sun Mar 17 14:06:40 2019 VERIFY OK: depth=0, C=PL, ST=Mazowieckie, L=Warszawa, O=Serwer, OU=Serwer, CN=server, name=server, emailAddress=admin@example.com
Sun Mar 17 14:06:40 2019 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Sun Mar 17 14:06:40 2019 [server] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:1194
Sun Mar 17 14:06:41 2019 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Sun Mar 17 14:06:41 2019 PUSH: Received control message: 'PUSH_REPLY,topology subnet,route-gateway 192.168.100.1,route 192.168.0.0 255.255.192.0,dhcp-option DNS 192.168.100.1,ping 5,ping-restart 10,ifconfig 192.168.100.11 255.255.192.0,peer-id 0,cipher AES-256-GCM'
Sun Mar 17 14:06:41 2019 OPTIONS IMPORT: timers and/or timeouts modified
Sun Mar 17 14:06:41 2019 OPTIONS IMPORT: --ifconfig/up options modified
Sun Mar 17 14:06:41 2019 OPTIONS IMPORT: route options modified
Sun Mar 17 14:06:41 2019 OPTIONS IMPORT: route-related options modified
Sun Mar 17 14:06:41 2019 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Mar 17 14:06:41 2019 OPTIONS IMPORT: peer-id set
Sun Mar 17 14:06:41 2019 OPTIONS IMPORT: adjusting link_mtu to 1624
Sun Mar 17 14:06:41 2019 OPTIONS IMPORT: data channel crypto options modified
Sun Mar 17 14:06:41 2019 Data Channel: using negotiated cipher 'AES-256-GCM'
Sun Mar 17 14:06:41 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun Mar 17 14:06:41 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun Mar 17 14:06:41 2019 TUN/TAP device tun0 opened
Sun Mar 17 14:06:41 2019 TUN/TAP TX queue length set to 100
Sun Mar 17 14:06:42 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Mar 17 14:06:42 2019 /sbin/ifconfig tun0 192.168.100.11 netmask 255.255.192.0 mtu 1500 broadcast 192.168.127.255
Sun Mar 17 14:06:42 2019 /sbin/route add -net 192.168.0.0 netmask 255.255.192.0 gw 192.168.100.1
Sun Mar 17 14:06:42 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Mar 17 14:06:42 2019 Initialization Sequence Completed

Widzę, że moja teoria się nie sprawdziła, bo tym razem nie było "Restart pause, 5 second(s)", a znowu nie mogę pingować bramy VPN. Chociaż restartowałem samego klienta ręcznie, więc poprzednie logi mogły się nadpisać.

6

Odp: Klient OpenVPN - Routowanie pomiędzy interface'ami

tinware napisał/a:

...
Restart "/etc/init.d/openvpn restart" nic nie pomaga, stąd wnioskuje, że opóźnienie o 15 sekund też nic nie pomoże....

W pierwszej części Twojego zdania - do pierwszego przecinka - masz rację, pewnie że nie pomaga.
Jeżeli porównasz to co proponuje Ci Cezary to zauważysz że restart serwera/klienta Openvpn następuje gdy WAN jest PODNIESIONY.
dodatkowo jest sleep 15, zanim nastąpi restart.

W Twoim przypadku WANu jeszcze nie ma i zwykły restart OpenVPN nie działa, a więc końcówka zdania: "że opóźnienie o 15 sekund też nic nie pomoże...." już nie jest prawdą.
Chyba że Twój WAN wstaje 20 sekund wtedy masz rację smile

Xiaomi AX3000T @ Netgear R6220
* DVBT2 - T230C *

7 (edytowany przez tinware 2019-03-17 16:05:31)

Odp: Klient OpenVPN - Routowanie pomiędzy interface'ami

Więc zacznijmy od początku:

# ls /etc/hotplug.d/iface
00-netstate       15-mwan3          16-mwancustombak
10-qos            15-teql           20-firewall

Dodaje i zapisuje skrypt:

# nano /etc/hotplug.d/iface/27-openvpn

#!/bin/sh

config_load "network"
config_get wan_proto "wan" "proto"

if [ "$INTERFACE" = "wan" ] && [ "$ACTION" = "ifup" ]
then
        sleep 60
        /etc/init.d/openvpn restart
fi

Następnie:

# reboot

Po upłynięciu 5 minut loguje się na router. Sprawdzam na tun0:

# ping -I tun0 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: seq=0 ttl=64 time=44.721 ms
^C

I na wszystkich interface:

# ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
^C

ja chyba czegoś mocno nie rozumiem...

Może to ma związek z niedawno instalowanym przeze mnie pakietem mwan3.
wan - eth0 - rj45 - niepodłączony kabel
wan2 - eth2 - usb - podłączony modem
wan3 - eth3 - usb - niepodłączony modem
wan4 - eth4 - usb - niepodłączony modem
wan5 - eth5 - usb - niepodłączony modem

8

Odp: Klient OpenVPN - Routowanie pomiędzy interface'ami

No to może wywal mwan3 i zobacz czy openvpn działa... Bo tak masz za dużo zmiennych.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

9 (edytowany przez tinware 2019-03-17 19:11:08)

Odp: Klient OpenVPN - Routowanie pomiędzy interface'ami

Cezary napisał/a:

No to może wywal mwan3 i zobacz czy openvpn działa

Po wyczyszczeniu konfiguracji w "/etc/config/mwan3", "uci commit mwan3" i kilku restartach i testach wszystko działa.

Postanowiłem stopniowo dodawać wany, aby wyeliminować problem. Podczas utworzenia konfiguracji dla dwóch wanów, czyli wan (niepodłączony rj45) + wan2 (podłączony modem usb) już jest problem z OpenVPN.

Postanowiłem więc wprowadzić konfigurację tylko dla tego co mam - czyli wan2 (nie wiem, czy tak można):

config interface 'wan2'
        option enabled '1'
        list track_ip '8.8.8.8'
        list track_ip '8.8.4.4'
        option reliability '2'
        option count '1'
        option timeout '1'
        option interval '0'
        option down '2'
        option up '4'

config member 'wan2_m2_w100'
        option interface 'wan2'
        option metric '2'
        option weight '100'

config policy 'failover'
        list use_member 'wan2_m2_w100'

config rule 'default_rule'
        option dest_ip '0.0.0.0/0'
        option use_policy 'failover'

Taka konfiguracja również powoduje problemy z OpenVPN.
Zakomentowanie "option use_policy 'failover'" usuwa ten problem ;-)

W tej konfiguracji zainteresowała mnie linijka:

option dest_ip '0.0.0.0/0'

Sprawdzając status mwan3, widzę że cała moja sieć VPN wpada do mwan3:

# mwan3 status
Interface status:
 interface wan2 is online and tracking is active

...

Directly connected ipv4 networks:
 ...
 192.168.127.255 - adres rozgłoszenia sieci VPN
 192.168.64.0 - adres sieci VPN
 192.168.100.11 - mój adres klienta VPN
 192.168.64.0/18 - sieć VPN
 192.168.0.0/18 - routowana sieć do VPN

Czy nie powinienem ustawić tam adresu mojego routera?

option dest_ip '192.168.1.0/25'

... lub routera + wany?

option dest_ip '192.168.1.0/24'

W takiej konfiguracji mój OpenVPN działa prawidłowo, ale czy nie zaburzy to pracy mwan3?
Cezary, proszę o Twoją opinie...

10

Odp: Klient OpenVPN - Routowanie pomiędzy interface'ami

Dostałem się dziś na mój drugi router (192.168.2.0/25) z dwoma modemami E3372h.
Router jest idealnym klonem tego pierwszego pod względem konfiguracji ze zmianami adresacji oczywiście.
Failover działa w nim dobrze przy konfiguracji:

config rule 'default_rule'
        option dest_ip '0.0.0.0/0'
        option use_policy 'failover'

Jedynym problemem, który zauważyłem to działanie OpenVPN, gdy pierwszy WAN jest offline.
Mój klient VPN jakby nie słuchał się reguł mwan3 i potrafił korzystać tylko z pierwszego WAN.
Oczywiście po powrocie łącza na pierwszym WAN - klient vpn łączy się ponownie do serwera.