Я только начал использовать облачные соединители OpenVPN для создания ячеистых сетей VPN.
Я развернул коннектор и настроил соответствующие протоколы IP-переадресации и NAT, которые позволяют мне получить доступ к сети LAN за машиной с помощью облачного коннектора OpenVPN. Я смог сделать это успешно. (моя информация в основном из этой ссылки https://openvpn.net/cloud-docs/connecting-networks-to-openvpn-cloud-using-connectors/)
Теперь проблема в том, почему я не могу подключиться по SSH к машине, на которой работает облачный коннектор, через свой IP-адрес VPN 100.96.1.18? Как ни странно, я могу пинговать его без проблем.
~$ ssh [email protected]
ssh: подключиться к хосту 100.96.1.18, порт 22: сеть недоступна
~$ пинг 100.96.1.18 -с 4
PING 100.96.1.18 (100.96.1.18) 56 (84) байт данных.
64 байта из 100.96.1.18: icmp_seq=1 ttl=62 время=209 мс
64 байта из 100.96.1.18: icmp_seq=2 ttl=62 время=279 мс
64 байта из 100.96.1.18: icmp_seq=3 ttl=62 время=208 мс
64 байта из 100.96.1.18: icmp_seq=4 ttl=62 время=204 мс
--- Статистика пинга 100.96.1.18 ---
4 пакета передано, 4 получено, 0% потери пакетов, время 3004 мс
rtt min/avg/max/mdev = 203,702/224,971/279,214/31,383 мс
Удивительно, но я могу удаленно (через машину VPN-клиента) подключиться по SSH к машине-коннектору через ее локальный IP-адрес 192.168.18.1
Вот IP-маршруты на машине соединителя.
~$ IP-маршрут
по умолчанию через 192.168.18.1 dev eno1 proto dhcp metric 100
64.120.110.199 через 192.168.18.1 dev eno1
100.80.0.0/12 через 100.96.1.17 dev tun0
100.96.0.0/11 через 100.96.1.17 dev tun0
100.96.1.16/30 dev tun0 ссылка на область ядра proto src 100.96.1.18
169.254.0.0/16 dev eno1 метрика ссылки области видимости 1000
172.17.0.0/16 dev docker0 ссылка на область ядра proto src 172.17.0.1
192.168.0.0/24 через 100.96.1.17 dev tun0
192.168.18.0/24 dev eno1 ссылка на область ядра proto src 192.168.18.88 метрика 100
~$ ifconfig tun0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
инет 100.96.1.18 сетевая маска 255.255.255.252 пункт назначения 100.96.1.18
inet6 fd:0:0:8101::2 prefixlen 126 scopeid 0x0<глобальный>
inet6 fe80::5a84:3a5:f59b:d64f prefixlen 64 scopeid 0x20<ссылка>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX-пакеты 1682 байта 451719 (451,7 КБ)
Ошибки RX 0 отброшено 0 переполнение 0 кадр 0
Пакеты TX 1755 байт 637526 (637,5 КБ)
Ошибки передачи 0 отброшено 0 превышение пропускной способности 0 несущей 0 коллизий 0
Также для отладки здесь приведены IP-маршруты с подключенного клиентского компьютера.
~$ IP-маршрут
по умолчанию через 192.168.31.1 dev wlp2s0 proto dhcp metric 600
25.0.0.0/8 dev ham0 ссылка на область действия ядра proto src 25.56.7.62
100.80.0.0/12 через 100.96.1.1 dev tun0
100.96.0.0/11 через 100.96.1.1 dev tun0
100.96.1.0/28 dev tun0 ссылка на область ядра proto src 100.96.1.2
169.254.0.0/16 dev wlp2s0 метрика ссылки области 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.107.213.76 через 192.168.31.1 dev wlp2s0
192.168.0.0/24 через 100.96.1.1 dev tun0
192.168.18.0/24 через 100.96.1.1 dev tun0
192.168.31.0/24 dev wlp2s0 ссылка на протоядро области src 192.168.31.189 метрика 600
~$ трассировка 100.96.1.18
traceroute до 100.96.1.18 (100.96.1.18), макс. 64 перехода
1 100.96.1.18 265.200 мс !N 109.653 мс !N 105.821 мс !N
Мой главный аргумент заключается в том, что, поскольку 100.96.0.0/11 через 100.96.1.1 dev tun0 маршрут передается клиенту, я должен быть в состоянии добраться до 100.96.1.18 IP и ssh или traceroute и т.д. к нему.
P.S. Спрашиваю об этом здесь, так как поддержка OpenVPN не может ответить.
