OpenVPN - Клиент Linux не мог получить доступ к Интернету, проблеме маршрутизации
Я установил сервер OpenVPN долгое время движение с опцией шлюза, что весь интернет-трафик направляется через.
Это хорошо работает для клиентской машины как Windows и моего телефона на базе Android, но та же Открытая конфигурация клиента VPN на моем ноутбуке Ubuntu, кажется, не работает. клиент соединяется, но интернет-трафик, кажется, не направляется.
Проверка с помощью ping-запросов сервера действительно работает: ping 10.8.0.1
так не уверенный, что отсутствует. Я попробовал до сих пор следующие опции
- добавленный к клиенту конфигурация маршрута: маршрут 10.8.0.0/24
- добавленный через консоль конфигурация маршрута: маршрут sudo добавляет - сеть 10.8.0.0/24 gw 10.8.0.1 dev tun0
- выключенный брандмауэр на клиенте
Любая справка или подсказки ценятся.Спасибо
конфигурация сервера:
port 443
proto tcp
dev tun
ca ...
cert ...
key ...
dh ...
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypasss-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status ...
log ...
verb 3
клиентская конфигурация:
client
dev tun
proto tcp
remote www.serverdomain.com 443
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 3
remote-cert-tls server
# route 10.8.0.0/24 --> adding such a route made no difference
клиент ifconfig:
tun0
Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.10 P-t-P:10.8.0.9 Mask:255.255.255.255
inet6 addr: fe80::b393:268c:61db:72d4/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:47 errors:0 dropped:0 overruns:0 frame:0
TX packets:93 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:4394 (4.3 KB) TX bytes:7012 (7.0 KB)
wlp1s0
Link encap:Ethernet HWaddr a4:34:d9:5c:9d:06
inet addr:192.168.0.130 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::5e97:3a8f:9596:8c30/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:24879 errors:0 dropped:0 overruns:0 frame:0
TX packets:17473 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14983497 (14.9 MB) TX bytes:2721828 (2.7 MB)
клиентский журнал произвел:
Thu Nov 3 21:03:25 2016 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb 2 2016
Thu Nov 3 21:03:25 2016 library versions: OpenSSL 1.0.2g-fips 1 Mar 2016, LZO 2.08
Thu Nov 3 21:03:25 2016 Socket Buffers: R=[87380->87380] S=[16384->16384]
Thu Nov 3 21:03:25 2016 Attempting to establish TCP connection with [AF_INET]188.62.xx.xx:443 [nonblock]
Thu Nov 3 21:03:26 2016 TCP connection established with [AF_INET]188.62.xx.xx:443
Thu Nov 3 21:03:26 2016 TCPv4_CLIENT link local: [undef]
Thu Nov 3 21:03:26 2016 TCPv4_CLIENT link remote: [AF_INET]188.62.xx.xx:443
Thu Nov 3 21:03:26 2016 TLS: Initial packet from [AF_INET]188.62.xx.xx:443, sid=ff1258e5 f87eeaf5
Thu Nov 3 21:03:26 2016 VERIFY OK: depth=1, C=CH, ST=ZH, L=Hinwil, O=xxx, OU=IT, CN=xxxx, name=xxxx, emailAddress=xxxx.ch
Thu Nov 3 21:03:26 2016 Validating certificate key usage
Thu Nov 3 21:03:26 2016 ++ Certificate has key usage 00a0, expects 00a0
Thu Nov 3 21:03:26 2016 VERIFY KU OK
Thu Nov 3 21:03:26 2016 Validating certificate extended key usage
Thu Nov 3 21:03:26 2016 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu Nov 3 21:03:26 2016 VERIFY EKU OK
Thu Nov 3 21:03:26 2016 VERIFY OK: depth=0, C=CH, ST=ZH, L=Hinwil, O=xxxx, OU=IT, CN=xxxx, name=xxxxx, emailAddress=xxxx.ch
Thu Nov 3 21:03:26 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 3 21:03:26 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 3 21:03:26 2016 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 3 21:03:26 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 3 21:03:26 2016 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Thu Nov 3 21:03:26 2016 [xxxx] Peer Connection Initiated with [AF_INET]188.62.xx.xx:443
Thu Nov 3 21:03:28 2016 SENT CONTROL [diabolo]: 'PUSH_REQUEST' (status=1)
Thu Nov 3 21:03:29 2016 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Thu Nov 3 21:03:29 2016 OPTIONS IMPORT: timers and/or timeouts modified
Thu Nov 3 21:03:29 2016 OPTIONS IMPORT: --ifconfig/up options modified
Thu Nov 3 21:03:29 2016 OPTIONS IMPORT: route options modified
Thu Nov 3 21:03:29 2016 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Nov 3 21:03:29 2016 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=wlp1s0 HWADDR=a4:34:d9:5c:9d:06
Thu Nov 3 21:03:29 2016 TUN/TAP device tun0 opened
Thu Nov 3 21:03:29 2016 TUN/TAP TX queue length set to 100
Thu Nov 3 21:03:29 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Nov 3 21:03:29 2016 /sbin/ip link set dev tun0 up mtu 1500
Thu Nov 3 21:03:29 2016 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5
Thu Nov 3 21:03:29 2016 /sbin/ip route add 188.62.79.43/32 via 192.168.0.1
Thu Nov 3 21:03:29 2016 /sbin/ip route add 0.0.0.0/1 via 10.8.0.5
Thu Nov 3 21:03:29 2016 /sbin/ip route add 128.0.0.0/1 via 10.8.0.5
Thu Nov 3 21:03:29 2016 /sbin/ip route add 10.8.0.0/24 via 10.8.0.5
Thu Nov 3 21:03:29 2016 Initialization Sequence Completed
клиент netstat-rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.8.0.9 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 wlp1s0
10.8.0.0 10.8.0.9 255.255.255.0 UG 0 0 0 tun0
10.8.0.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
128.0.0.0 10.8.0.9 128.0.0.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wlp1s0
188.62.xx.xx 192.168.0.1 255.255.255.255 UGH 0 0 0 wlp1s0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlp1s0
5
задан Kristopher Ives
9 September 2019 в 06:35
поделиться
1 ответ
Я мог решить проблему путем понижения "метрик" моей карты Ethernet/Wi-Fi. можно понизить метрики (приоритет) записей маршрутизации для сетевой платы через команду "маршрута", или при помощи дополнительного инструмента" ifmetric" (sudo склонный - получают установку ifmetric), т.е. ifmetric eth0 100 (0 = самый высокий приоритет)
После этого, я распознал, что записи DNS с openvpn сервера не были приняты, когда соединение VPN было установкой. таким образом, я погуглил вокруг, и я нашел ответ, что необходимо прибавить клиент человечности следующие строки на ее файле конфигурации:
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
Это обновляет записи DNS в /etc/resolv.conf, когда соединение VPN устанавливается при помощи продвинутых записей с сервера.
, Таким образом, это работает теперь как очарование.
4
ответ дан Zanna
23 November 2019 в 09:31
поделиться