No se puede realizar SSH en la máquina del conector de nube OpenVPN a través de IP VPN

No se puede realizar SSH en la máquina del conector de nube OpenVPN a través de IP VPN

Recién comencé a usar conectores en la nube OpenVPN para crear redes VPN en malla. Implementé un conector y configuré el reenvío de IP y los protocolos NAT relevantes que me permiten acceder a la red LAN detrás de la máquina ejecutando el conector en la nube OpenVPN. Pude hacerlo con éxito. (mi información proviene principalmente de este enlacehttps://openvpn.net/cloud-docs/connecting-networks-to-openvpn-cloud-using-connectors/)

Ahora el problema es ¿por qué no puedo conectarme por SSH a la máquina que ejecuta el conector de la nube a través de su IP VPN de 100.96.1.18? Curiosamente, puedo hacer ping sin problema. ingrese la descripción de la imagen aquí

~$ ssh [email protected]
ssh: connect to host 100.96.1.18 port 22: Network is unreachable
~$ ping 100.96.1.18 -c 4
PING 100.96.1.18 (100.96.1.18) 56(84) bytes of data.
64 bytes from 100.96.1.18: icmp_seq=1 ttl=62 time=209 ms
64 bytes from 100.96.1.18: icmp_seq=2 ttl=62 time=279 ms
64 bytes from 100.96.1.18: icmp_seq=3 ttl=62 time=208 ms
64 bytes from 100.96.1.18: icmp_seq=4 ttl=62 time=204 ms

--- 100.96.1.18 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 203.702/224.971/279.214/31.383 ms

Sorprendentemente, puedo acceder mediante SSH de forma remota (a través de una máquina cliente VPN) a la máquina del conector a través de su IP local de192.168.18.1

Aquí están las rutas IP en la máquina del conector.

~$ ip route
default via 192.168.18.1 dev eno1 proto dhcp metric 100 
64.120.110.199 via 192.168.18.1 dev eno1 
100.80.0.0/12 via 100.96.1.17 dev tun0 
100.96.0.0/11 via 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 via 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  destination 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>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 1682  bytes 451719 (451.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1755  bytes 637526 (637.5 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

También para depurar aquí están las rutas IP desde una máquina cliente conectada

~$ ip route
default via 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 via 100.96.1.1 dev tun0 
100.96.0.0/11 via 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 via 192.168.31.1 dev wlp2s0 
192.168.0.0/24 via 100.96.1.1 dev tun0 
192.168.18.0/24 via 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 to 100.96.1.18 (100.96.1.18), 64 hops max
  1   100.96.1.18  265.200ms !N  109.653ms !N  105.821ms !N

Mi principal punto de discusión es que, dado que 100.96.0.0/11 via 100.96.1.1 dev tun0la ruta se envía al cliente, debería poder acceder a la 100.96.1.18IP y enviarle ssh o traceroute, etc.

PD: Pregunto esto aquí ya que el soporte de OpenVPN no pudo responder.

Respuesta1

En caso de que alguien tenga el mismo problema: este problema no tiene nada que ver con el firewall de su lado, ya que la conexión se interrumpe en el lado de la nube. Según la idea de la nube de OpenVPN, usted utiliza "conectores de red" para conectarse a alguna red como cliente y "conectores de host" para permitir que los clientes se conecten a usted. Entonces, si desea conectarse a su servidor a través de la nube OpenVPN, ese servidor debe estar conectado a la VPN a través del "conector de host" y no a través del "conector de red", ya que solo el "conector de host" tendrá un firewall abierto para las conexiones entrantes en el lado de la nube.

Para verificar si esto se aplica a usted, asegúrese de que su servidor openssh esté escuchando en todas las interfaces (0.0.0.0:22 o :::22 para ipv6) usando "netstat -pan | grep ssh" o al menos en su interfaz VPN. Luego use (asumiendo que vpn está en la interfaz tun0) "tcpdump -pni tun0 tcp port 22" para ver si recibe alguna solicitud de conexión ssh de vpn. Puede soltar el "puerto 22" e intentar hacer ping a su "servidor" para asegurarse de que haya tráfico. Normalmente, con el "conector de red" obtendrá su pase de ping, pero para las solicitudes ssh no será visible nada ya que la nube no permitirá el tráfico ssh. Si establece una conexión a través de la nube utilizando el "conector de host", funcionará.

https://openvpn.net/cloud-docs/owner/servers/hosts/adding-a-host.html

información relacionada