openvpn: Невозможно пропинговать клиента, когда он подключен из локальной сети
У нас есть сервер openvpn (я полагаю, на нашем маршрутизаторе) и мобильные клиенты, которые подключаются к Интернету из отдаленных мест, а иногда и из нашего офиса. Эти системы являются автономными, поэтому настраивать их по-разному перед подключением к офисной сети не стоит. Мы хотели бы подключить к ним SSH через их имена хостов avahi независимо от того, где они физически находятся.
Правильно мы можем пинговать и SSH, когда они подключены к Интернету за пределами нашей сети. Когда они подключены изнутри нашей локальной сети, иногда hostname.local решает в 192.168.10.3 (и пинг и SSH не работают), а иногда и 192.168.1.211 (и ping и ssh работают).
При мониторинге wireshark на мобильном клиенте запросы ping на адрес 192.168.10.3 действительно появляются, но не отвечают.
Как мы можем настроить наших клиентов, чтобы они могли быть доступны при подключении изнутри нашей сети?
вывод ifconfig на клиенте (подключен к VPN через локальную сеть нашего офиса):
eth0 Link encap:Ethernet HWaddr 00:04:4b:a7:fa:e5
inet addr:192.168.1.223 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::7a45:f5b1:1b87:c6f0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8964 errors:0 dropped:0 overruns:0 frame:0
TX packets:771 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1847719 (1.8 MB) TX bytes:160760 (160.7 KB)
Interrupt:42
tap0 Link encap:Ethernet HWaddr ce:d4:a6:18:48:21
inet addr:192.168.10.3 Bcast:192.168.10.255 Mask:255.255.255.0
inet6 addr: fe80::ccd4:a6ff:fe18:4821/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1381 errors:0 dropped:0 overruns:0 frame:0
TX packets:58 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:214474 (214.4 KB) TX bytes:7149 (7.1 KB)
вывод route на клиенте (подключен к VPN через локальную сеть нашего офиса):
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
default 192.168.10.1 0.0.0.0 UG 50 0 0 tap0
default 192.168.1.1 0.0.0.0 UG 100 0 0 eth0
link-local * 255.255.0.0 U 1000 0 0 eth1
192.168.1.0 * 255.255.255.0 U 100 0 0 eth0
192.168.2.0 * 255.255.255.0 U 0 0 0 eth1
192.168.10.0 * 255.255.255.0 U 50 0 0 tap0
Последовательный эхо-запрос от другого компьютера в той же локальной сети к нашему мобильному клиенту. По какой-то причине авахи .local имена непредсказуемо преобразуются в IP-адрес VPN или другой. В любом случае, пинг до VPN-IP (второй) просто зависает:
[15:51:25]~$ ping liber0.local
PING liber0.local (192.168.1.223) 56(84) bytes of data.
64 bytes from 192.168.1.223: icmp_seq=1 ttl=64 time=4.00 ms
64 bytes from 192.168.1.223: icmp_seq=2 ttl=64 time=6.09 ms
64 bytes from 192.168.1.223: icmp_seq=3 ttl=64 time=38.8 ms
^C
--- liber0.local ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.003/16.302/38.805/15.935 ms
[15:51:29]~$ ping liber0.local
PING liber0.local (192.168.10.3) 56(84) bytes of data.
^C
--- liber0.local ping statistics ---
27 packets transmitted, 0 received, 100% packet loss, time 26629ms
Файл конфигурации OpenVPN:
client
dev tap
proto udp
remote <redacted>
float
resolv-retry infinite
nobind
persist-key
persist-tun
verb 3
ca <redacted>.pem
cert <redacted>.pem
key <redacted>.key
cipher AES-256-CBC
auth SHA256
1 ответ
Ключевым намеком было то, что ICMP-пакеты поступили на клиент, подключенный к VPN, но не получили ответа. Оказалось, что по умолчанию rp_filter (фильтр обратного пути) строго проверяет и отбрасывает пакеты. добавление net.ipv4.conf.default.rp_filter = 2 в /etc/sysctl.conf устанавливает для rp_filter потерю проверки обратного пути, и все работает.