Приветствую всех.
Пытаюсь настроить настроить опенвпн клиент для zaborona.help на Debian в качестве шлюза. С горем пополам тунель поднялся, маршруты добавились. Но, к сожалению, пакетики в тунель уходят, а ответа нет. К тому же, не смотря указанные вручную ДНСы в клиент конфиге, очевидно запросы отправляются не в тунель, а к провайдеру. C виндовой машиной за этим роутером, овпн клиент работает отлично.
Куда копать?cat /etc/debian_version
8.10uname -a
Linux 3.16.0-4-686-pae #1 SMP Debian 3.16.43-2 (2017-04-30) i686 GNU/Linux
/etc/openvpn/client.conf
dev tun
proto tcp
remote vpn.zaborona.help 1194
client
resolv-retry infinite
ca "/etc/openvpn/ca.crt"
cert "/etc/openvpn/zaborona-help.crt"
key "/etc/openvpn/zaborona-help.key"
remote-cert-tls server
persist-key
persist-tun
cipher AES-128-CBC
comp-lzo
verb 3
status /var/log/openvpn/openvpn-status.log 1
status-version 3
log-append /var/log/openvpn/openvpn-client.log
push «dhcp-option DNS 74.82.42.42»268: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 192.168.230.100/22 brd 192.168.231.255 scope global tun0
valid_lft forever preferred_lft forever
inet6 2a00:1838:30:6810::1262/112 scope global
valid_lft forever preferred_lft forever
/etc/openvpn/update-resolv-conf
> /etc/openvpn/update-resolv-confспасибо, вопрос с ДНСами поправил, запросы заворачиваются в тунель.
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 192.168.230.140/22 brd 192.168.231.255 scope global tun0
valid_lft forever preferred_lft forever
inet6 2a00:1838:30:7010::128a/112 scope global
valid_lft forever preferred_lft forever
11:57:23.828616 IP 192.168.230.140.44534 > ordns.he.net.domain: 59772+ A? vk.com. (24)
11:57:23.831274 IP 192.168.230.140.46732 > ordns.he.net.domain: 40667+ PTR? 42.42.82.74.in-addr.arpa. (42)
11:57:28.834207 IP 192.168.230.140.41553 > dns.yandex.ru.domain: 40667+ PTR? 42.42.82.74.in-addr.arpa. (42)
11:57:28.834422 IP 192.168.230.140.48711 > dns.yandex.ru.domain: 59772+ A? vk.com. (24)
11:57:31.839397 IP 192.168.230.140.57198 > ordns.he.net.domain: 7938+ PTR? 101.80.138.195.in-addr.arpa. (45)
11:57:32.471862 IP 192.168.230.140.35567 > ordns.he.net.domain: 6261+ PTR? 140.230.168.192.in-addr.arpa. (46)
11:57:37.476950 IP 192.168.230.140.53052 > dns.yandex.ru.domain: 6261+ PTR? 140.230.168.192.in-addr.arpa. (46)
11:57:40.491502 IP 192.168.230.140.56263 > ordns.he.net.domain: 25132+ PTR? 8.8.88.77.in-addr.arpa. (40)
11:57:45.496590 IP 192.168.230.140.37369 > dns.yandex.ru.domain: 25132+ PTR? 8.8.88.77.in-addr.arpa. (40)
11:57:53.377190 IP 192.168.230.140.47057 > dns.yandex.ru.domain: 25203+ A? vk.com. (24)
но как узнать, почему нет ответа?
>> /etc/openvpn/update-resolv-conf
> спасибо, вопрос с ДНСами поправил, запросы заворачиваются в тунель.
> 7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN
> group default qlen 100
> link/none
> inet 192.168.230.140/22 brd 192.168.231.255 scope global tun0
> valid_lft forever preferred_lft forever
> inet6 2a00:1838:30:7010::128a/112 scope global
> valid_lft forever preferred_lft forever
> но как узнать, почему нет ответа?копать в сторону MTU и MSS
> копать в сторону MTU и MSSменял, не помогло.
>> копать в сторону MTU и MSS
> менял, не помогло.НАТ скорее всего недонастроен на точке выхода.
Вот и нет ответа...
>>> копать в сторону MTU и MSS
>> менял, не помогло.
> НАТ скорее всего недонастроен на точке выхода.
> Вот и нет ответа...Что значит недонастроил? как проверить?
Я же привёл кусок дампа, из которого видно, что пакеты в тунель попадают уже с адресом выданным овпн сервером.
>>>> копать в сторону MTU и MSS
>>> менял, не помогло.
>> НАТ скорее всего недонастроен на точке выхода.
>> Вот и нет ответа...
> Что значит недонастроил? как проверить?
> Я же привёл кусок дампа, из которого видно, что пакеты в тунель
> попадают уже с адресом выданным овпн сервером.192.168.230.140 - адрес приватный.
dns.yandex.ru - таки публичный.
Значит где-то между ними должен быть НАТ....
>>>>> копать в сторону MTU и MSS
>>>> менял, не помогло.
>>> НАТ скорее всего недонастроен на точке выхода.
>>> Вот и нет ответа...
>> Что значит недонастроил? как проверить?
>> Я же привёл кусок дампа, из которого видно, что пакеты в тунель
>> попадают уже с адресом выданным овпн сервером.
> 192.168.230.140 - адрес приватный.
> dns.yandex.ru - таки публичный.
> Значит где-то между ними должен быть НАТ....Начните с traceroute.
хотя бы узнаем куда добегаем.
>> 192.168.230.140 - адрес приватный.
>> dns.yandex.ru - таки публичный.
>> Значит где-то между ними должен быть НАТ....192.168.230.140 таки приватный, но выдан он ОВПН-сервером, там же, где и их нат. У меня же подсеть для клиентов другая.
subnet 192.168.80.0 netmask 255.255.255.0 {
range 192.168.80.100 192.168.80.120;Да и проверяется всё с самого сервака.
> Начните с traceroute.
> хотя бы узнаем куда добегаем.Не узнаем. Для того, чтоб понять куда добегают пакеты, надо чтоб узел ответил, и, что в нашей ситуации самое критичное, -это чтоб мы эти ответы получили. И вот дело в том, что ответы я как раз получаю, только они не долетают в tun-интерфейс.
У меня подключение к провайдеру через РРРоЕ
вот пинг на айпишник (не домен) vk.com.
sudo tcpdump -i tun0 icmp -n
11:33:37.931599 IP 192.168.224.163 > 87.240.165.80: ICMP echo request, id 12097, seq 50, length 64
11:33:38.931604 IP 192.168.224.163 > 87.240.165.80: ICMP echo request, id 12097, seq 51, length 64
sudo tcpdump -i ppp0 -n11:41:34.931921 IP my_PPPoE_IP.48616 > 77.73.68.230.1194: Flags [P.], seq 1802921980:1802922115, ack 1843548864, win 23160, options [nop,nop,TS val 64616110 ecr 2385983404], length 135
11:41:34.969854 IP 77.73.68.230.1194 > my_PPPoE_IP.48616: Flags [.], ack 135, win 1031, options [nop,nop,TS val 2385983654 ecr 64616110], length 0
11:41:35.931868 IP my_PPPoE_IP.48616 > 77.73.68.230.1194: Flags [P.], seq 135:270, ack 1, win 23160, options [nop,nop,TS val 64616360 ecr 2385983654], length 135
11:41:35.969437 IP 77.73.68.230.1194 > my_PPPoE_IP.48616: Flags [.], ack 270, win 1031, options [nop,nop,TS val 2385983904 ecr 64616360], length 0
11:41:36.931867 IP my_PPPoE_IP.48616 > 77.73.68.230.1194: Flags [P.], seq 270:405, ack 1, win 23160, options [nop,nop,TS val 64616610 ecr 2385983904], length 135
11:41:36.969806 IP 77.73.68.230.1194 > my_PPPoE_IP.48616: Flags [.], ack 405, win 1031, options [nop,nop,TS val 2385984154 ecr 64616610], length 0
Т.е. сам овпн-сервак отвечает, только вот у меня маршрутизируется уже не правильно. Ответ в ррр тунель приходит, а вот форвардинга в тан, почему-то, нет.sudo sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
ноль байт в тунелеOpenVPN STATISTICS
Updated,Fri Dec 29 13:21:36 2017
TUN/TAP read bytes,104
TUN/TAP write bytes,0
TCP/UDP read bytes,6537
TCP/UDP write bytes,3834
Auth read bytes,0
pre-compress bytes,0
post-compress bytes,0
pre-decompress bytes,0
post-decompress bytes,0
END
/var/log/openvpn/openvpn-status.log (END)
>[оверквотинг удален]
> options [nop,nop,TS val 2385983904 ecr 64616360], length 0
> 11:41:36.931867 IP my_PPPoE_IP.48616 > 77.73.68.230.1194: Flags [P.], seq 270:405, ack
> 1, win 23160, options [nop,nop,TS val 64616610 ecr 2385983904], length 135
> 11:41:36.969806 IP 77.73.68.230.1194 > my_PPPoE_IP.48616: Flags [.], ack 405, win 1031,
> options [nop,nop,TS val 2385984154 ecr 64616610], length 0
> Т.е. сам овпн-сервак отвечает, только вот у меня маршрутизируется уже не правильно.
> Ответ в ррр тунель приходит, а вот форвардинга в тан, почему-то,
> нет.
> sudo sysctl net.ipv4.ip_forward
> net.ipv4.ip_forward = 1Т.е. "length 0" в ответе вас ну ниразу не настораживает??????
Это НЕ ОТВЕТ!!!! это "tcp ack" от OVPN сервера, подтверждающее получение сегмента в рамках TCP сессии и не более того!!!!!
>[оверквотинг удален]
>> 11:41:36.969806 IP 77.73.68.230.1194 > my_PPPoE_IP.48616: Flags [.], ack 405, win 1031,
>> options [nop,nop,TS val 2385984154 ecr 64616610], length 0
>> Т.е. сам овпн-сервак отвечает, только вот у меня маршрутизируется уже не правильно.
>> Ответ в ррр тунель приходит, а вот форвардинга в тан, почему-то,
>> нет.
>> sudo sysctl net.ipv4.ip_forward
>> net.ipv4.ip_forward = 1
> Т.е. "length 0" в ответе вас ну ниразу не настораживает??????
> Это НЕ ОТВЕТ!!!! это "tcp ack" от OVPN сервера, подтверждающее получение сегмента
> в рамках TCP сессии и не более того!!!!!ГДЕ ТРЕЙС???
> Т.е. "length 0" в ответе вас ну ниразу не настораживает??????
> Это НЕ ОТВЕТ!!!! это "tcp ack" от OVPN сервера, подтверждающее получение сегмента
> в рамках TCP сессии и не более того!!!!!да, вы правы, я ошибся.
>ГДЕ ТРЕЙС???
traceroute to 87.240.165.80 (87.240.165.80), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
>> Т.е. "length 0" в ответе вас ну ниразу не настораживает??????
>> Это НЕ ОТВЕТ!!!! это "tcp ack" от OVPN сервера, подтверждающее получение сегмента
>> в рамках TCP сессии и не более того!!!!!
> да, вы правы, я ошибся.
>>ГДЕ ТРЕЙС???
> traceroute to 87.240.165.80 (87.240.165.80), 30 hops max, 60 byte packets
> 1 * * *Вам даже шлюз не ответил.
Пинг на второй хвост тунеля впринципе есть?
> Вам даже шлюз не ответил.
> Пинг на второй хвост тунеля впринципе есть?если коротко, то нет.
77.88.8.8 via 192.168.228.1 dev tun0
--- 192.168.228.1 ping statistics ---
159 packets transmitted, 0 received, 100% packet loss, time 157999msЭто видно в tun-тунеле
14:58:42.978856 IP 192.168.230.206 > 192.168.228.1: ICMP echo request, id 1921, seq 26, length 64
14:58:43.986855 IP 192.168.230.206 > 192.168.228.1: ICMP echo request, id 1921, seq 27, length 64
14:58:44.994858 IP 192.168.230.206 > 192.168.228.1: ICMP echo request, id 1921, seq 28, length 64
14:58:46.002857 IP 192.168.230.206 > 192.168.228.1: ICMP echo request, id 1921, seq 29, length 64Это видно в ррр-тунеле
15:21:52.694173 IP 94.242.59.156.1194 > 85.238.X.X.58747: Flags [.], ack 417404625, win 830, options [nop,nop,TS val 4084682213 ecr 914809], length 0
15:21:53.667126 IP 85.238.X.X.58747 > 94.242.59.156.1194: Flags [P.], seq 1:136, ack 0, win 23160, options [nop,nop,TS val 915061 ecr 4084682213], length 135
15:21:53.705826 IP 94.242.59.156.1194 > 85.238.X.X.58747: Flags [.], ack 136, win 838, options [nop,nop,TS val 4084682466 ecr 915061], length 0
15:21:53.942139 IP 85.238.X.X.58747 > 94.242.59.156.1194: Flags [P.], seq 136:239, ack 0, win 23160, options [nop,nop,TS val 915130 ecr 4084682466], length 103
15:21:53.977314 IP 94.242.59.156.1194 > 85.238.X.X.58747: Flags [.], ack 239, win 838, options [nop,nop,TS val 4084682534 ecr 915130], length 0
15:21:54.675101 IP 85.238.X.X.58747 > 94.242.59.156.1194: Flags [P.], seq 239:374, ack 0, win 23160, options [nop,nop,TS val 915313 ecr 4084682534], length 135
15:21:54.710041 IP 94.242.59.156.1194 > 85.238.X.X.58747: Flags [.], ack 374, win 846, options [nop,nop,TS val 4084682717 ecr 915313], length 0
15:21:55.683088 IP 85.238.X.X.58747 > 94.242.59.156.1194: Flags [P.], seq 374:509, ack 0, win 23160, options [nop,nop,TS val 915565 ecr 4084682717], length 135>попробуй посмотреть mss
>>> копать в сторону MTU и MSS
>> менял, не помогло./etc/openvpn/client.conf
tun-mtu 1400
mssfix 1300P.S. Привет одесситам!
>[оверквотинг удален]
> status-version 3
> log-append /var/log/openvpn/openvpn-client.log
> push «dhcp-option DNS 74.82.42.42»
> 268: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UNKNOWN group default qlen 100
> link/none
> inet 192.168.230.100/22 brd 192.168.231.255 scope global tun0
> valid_lft forever preferred_lft forever
> inet6 2a00:1838:30:6810::1262/112 scope global
> valid_lft forever preferred_lft foreverпопробуй посмотреть mss
>>> копать в сторону MTU и MSS
>> менял, не помогло.
>попробуй посмотреть mss/etc/openvpn/client.conf
tun-mtu 1400
mssfix 1300
>>>> копать в сторону MTU и MSS
>>> менял, не помогло.
>>попробуй посмотреть mss
> /etc/openvpn/client.conf
> tun-mtu 1400
> mssfix 1300Посмотрите на виндовой машине какие параметры выдаются на OVPN тунель и куда маршруты смотрят.
Лично у меня на OVPN клиенте (правда сервер - тоже мой :) )
tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
link/none
inet 192.168.128.6 peer 192.168.128.5/32 scope global tun0
valid_lft forever preferred_lft forever#ip route | grep tun0
172.25.0.0/16 via 192.168.128.5 dev tun0
192.168.128.5 dev tun0 proto kernel scope link src 192.168.128.6Разницу замечаете?
> Разницу замечаете?Честно говоря, нет. Намекните более толсто, можно прямо в лоб.
Если вы про то, что поменяно МТУ и мсс, то это лишь для теста. Убрал принудительные параметры, получил как надо, результат тот же.
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 192.168.231.80/22 brd 192.168.231.255 scope global tun0
valid_lft forever preferred_lft forever
inet6 2a00:1838:30:7380::134e/112 scope global
valid_lft forever preferred_lft foreverА маршруты я получаю правильно, пакетики заворачиваются правильно. В ветке выше это указано.
>[оверквотинг удален]
> для теста. Убрал принудительные параметры, получил как надо, результат тот же.
> 5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN
> group default qlen 100
> link/none
> inet 192.168.231.80/22 brd 192.168.231.255 scope global tun0
> valid_lft forever preferred_lft forever
> inet6 2a00:1838:30:7380::134e/112 scope global
> valid_lft forever preferred_lft forever
> А маршруты я получаю правильно, пакетики заворачиваются правильно. В ветке выше это
> указано.Мой вывод:
tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP>
inet 192.168.128.6 peer 192.168.128.5/32</b>Ваш вывод:
tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP>
inet 192.168.231.80/22 brd 192.168.231.255tun интерфейс у вас как-бы ни разу не бродкастовый, а вы от от него бродкаста хотите (192.168.231.80/22 brd 192.168.231.255 именно это означает) ...
Посмотрите какие параметры у вас на винде при подключении выдаются??
Может у вас TAP интерфейс нужен?
или таки что-то типа
inet 192.168.128.6 peer 192.168.128.5/32должно быть в tun с адресами.