Tocmai am început să folosesc conectorii cloud OpenVPN pentru a crea rețele VPN mesh.
Am implementat un conector și am configurat protocoale relevante de redirecționare IP și NAT care îmi permit să accesez rețeaua LAN din spatele mașinii cu conectorul cloud OpenVPN. Am reușit să fac asta cu succes. (informațiile mele sunt în mare parte de la acest link https://openvpn.net/cloud-docs/connecting-networks-to-openvpn-cloud-using-connectors/)
Acum problema este de ce nu pot să fac SSH în mașina care rulează conectorul cloud prin IP-ul său VPN al 100.96.1.18? În mod ciudat, pot să-l pun ping fără probleme.
~$ ssh [email protected]
ssh: conectați-vă la gazda 100.96.1.18 portul 22: rețeaua este inaccesibilă
~$ ping 100.96.1.18 -c 4
PING 100.96.1.18 (100.96.1.18) 56(84) octeți de date.
64 de octeți de la 100.96.1.18: icmp_seq=1 ttl=62 time=209 ms
64 de octeți de la 100.96.1.18: icmp_seq=2 ttl=62 time=279 ms
64 de octeți de la 100.96.1.18: icmp_seq=3 ttl=62 time=208 ms
64 de octeți de la 100.96.1.18: icmp_seq=4 ttl=62 time=204 ms
--- 100.96.1.18 statistici ping ---
4 pachete transmise, 4 primite, 0% pierdere de pachete, timp 3004 ms
rtt min/avg/max/mdev = 203,702/224,971/279,214/31,383 ms
În mod surprinzător, pot de la distanță (printr-o mașină client VPN) SSH în mașina conector prin IP-ul local al 192.168.18.1
Iată rutele IP de pe mașina de conectare.
~$ traseu ip
implicit prin 192.168.18.1 dev eno1 proto dhcp metric 100
64.120.110.199 prin 192.168.18.1 dev eno1
100.80.0.0/12 prin 100.96.1.17 dev tun0
100.96.0.0/11 prin 100.96.1.17 dev tun0
100.96.1.16/30 dev tun0 proto kernel scope link src 100.96.1.18
169.254.0.0/16 dev eno1 scope link metric 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.0.0/24 prin 100.96.1.17 dev tun0
192.168.18.0/24 dev eno1 proto kernel scope link src 192.168.18.88 metric 100
~$ ifconfig tun0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 100.96.1.18 netmask 255.255.255.252 destinație 100.96.1.18
inet6 fd:0:0:8101::2 prefixlen 126 scopeid 0x0<global>
inet6 fe80::5a84:3a5:f59b:d64f prefixlen 64 scopeid 0x20<link>
nespecificat 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
Pachete RX 1682 octeți 451719 (451,7 KB)
Erori RX 0 a scăzut 0 depășiri 0 cadru 0
Pachete TX 1755 octeți 637526 (637,5 KB)
Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0
De asemenea, pentru depanare, aici sunt rutele IP de la o mașină client conectată
~$ traseu ip
implicit prin 192.168.31.1 dev wlp2s0 proto dhcp metric 600
25.0.0.0/8 dev ham0 proto kernel scope link src 25.56.7.62
100.80.0.0/12 prin 100.96.1.1 dev tun0
100.96.0.0/11 prin 100.96.1.1 dev tun0
100.96.1.0/28 dev tun0 proto kernel scope link src 100.96.1.2
169.254.0.0/16 dev wlp2s0 scope link metric 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.107.213.76 prin 192.168.31.1 dev wlp2s0
192.168.0.0/24 prin 100.96.1.1 dev tun0
192.168.18.0/24 prin 100.96.1.1 dev tun0
192.168.31.0/24 dev wlp2s0 proto kernel scope link src 192.168.31.189 metric 600
~$ traceroute 100.96.1.18
traceroute la 100.96.1.18 (100.96.1.18), 64 hop max
1 100.96.1.18 265.200ms !N 109.653ms !N 105.821ms !N
Principalul meu argument este că de atunci 100.96.0.0/11 prin 100.96.1.1 dev tun0 ruta este împinsă către clientul pe care ar trebui să-l pot ajunge 100.96.1.18 IP și ssh sau traceroute etc. la acesta.
P.S. Întrebând acest lucru aici, deoarece suportul OpenVPN nu a putut răspunde.
