web-dev-qa-db-fra.com

ssh dans un serveur connecté à un service VPN

J'ai un serveur privé virtuel, que je voudrais exécuter un serveur Web pendant que mon serveur est connecté à un service VPN

Lorsque la connexion VPN à mon fournisseur n'est pas établie, je peux faire tout ce que je veux avec ce serveur, ssh, scp, http etc.

Une fois que openvpn est en cours d'exécution et connecté au service VPN du fournisseur, le serveur n'est plus accessible par aucun moyen et bien sûr pour une bonne raison

L'image ressemble à ceci:

           My VPS                             ------------
         +----------------+                  /            \
         |                |                 /   Internet  /       101.11.12.13
         |        50.1.2.3|-----------------\   cloud    /----<--- me@myhome
         |                |                  /           \
         |     10.80.70.60|                 /             \
         +----------------+                 \              \
                        :                    \_____________/
                        :                           :
                        :                           :
                        :                           :
                        :                           :
                  +------------------+              :
                  |     10.80.70.61  |              :
                  |               \  |              :
                  |                \ |              :
                  | 175.41.42.43:1197|..............:
                  |   175.41.42.43:yy|   
                  |       .....      |
                  |   175.41.42.43:xx|
                  +------------------+



Legend                  
------ Line No VPN connection present
...... Line VPN connection established

Choses à clarifier:

  • Toutes les adresses IP et numéros de port ci-dessus et ci-dessous sont fictifs
  • Les lignes avec les numéros de port xx, yy et quoi que ce soit entre les deux sont mon hypothèse, pas quelque chose que je connais pour un fait.
  • J'ai mis en place un travail cron qui s'exécute toutes les minutes pings un autre VPS à moi, exécutant Apache2 Dans les journaux Apache2, je peux voir l'adresse IP d'origine passer de 50.1.2.3 à 175.41.42.43, lorsque VPN est actif, donc VPN fonctionne correctement

Les journaux OpenVPN les montrent:

UDPv4 link remote: [AF_INET]175.41.42.43:1197
[ProviderName] Peer Connection Initiated with [AF_INET]175.41.42.43:1197
TUN/TAP device tun0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 local 10.80.70.60 peer 10.80.70.61

À ce stade, je voudrais pouvoir passer de myhome à My VPS dans l'image, alors que le VPN est en place et utilise PuTTY.

Dans le passé, dans l'un de mes lieux de travail, on m'a donné une séquence très étrange pour ssh dans un serveur extrêmement sécurisé qui avait trois @ signe dans la chaîne. Donc, je sautais de boîte en boîte comme j'imagine, mais comme les boîtes de saut exécutaient une version de Windows OS et une application propriétaire sur ceux-ci, je n'avais aucune visibilité pour voir ce qui se passait sous les enveloppes. Je n'ai donc pas fait très attention. Maintenant je commence à réaliser que je peux être dans la même situation ou une situation similaire.

À l'aide des adresses IP et des ports du diagramme et/ou de l'extrait de journal, quelqu'un peut-il me dire comment je peux traverser ce tunnel et accéder à mon serveur?

sshopenvpnssh-tunnelingtunneling
24
Scott

Vous êtes verrouillé hors de votre VPS car une fois le service VPN activé, vos paquets ssh sont acheminés via le VPN et non l'IP 50.2.1.3 public de votre VPS.

Supposons que votre serveur:

  • L'IP publique est 50.1.2.3 (selon votre exemple d'installation)
  • Le sous-réseau IP public est 50.1.2.0/24
  • La passerelle par défaut est x.x.x.1
  • eth0 est le périphérique vers la passerelle

Procédez comme suit à l'aide d'iproute2:

ip rule add table 128 from 50.1.2.3
ip route add table 128 to 50.1.2.0/24 dev eth0
ip route add table 128 default via x.x.x.1

Exécutez ensuite votre configuration client OpenVPN: openvpn --config youropenvpn-configfile.ovpn &

Vous pourrez ensuite vous connecter à votre serveur pendant que votre serveur est connecté au service vpn.

Vous devrez ajouter les filtres iptables appropriés pour restreindre l'accès à votre IP publique à partir de sessions non-ssh: 22.

10
hcb

C'est peut-être un peu tard, mais ...

Le problème est que la passerelle par défaut est modifiée par OpenVPN, et cela rompt votre connexion SSH actuelle, sauf si vous configurez des itinéraires appropriés avant de démarrer OpenVPN.

Ce qui suit fonctionne pour moi. Il utilise iptables et ip (iproute2). Ci-dessous, il est supposé que l'interface de passerelle par défaut avant le démarrage d'OpenVPN est "eth0". L'idée est de s'assurer que lorsqu'une connexion à eth0 est établie, même si eth0 n'est plus l'interface de passerelle par défaut, les paquets de réponse pour la connexion reviennent à nouveau sur eth0.

Vous pouvez utiliser le même numéro pour la marque de connexion, la marque de pare-feu et la table de routage. J'ai utilisé des nombres distincts pour rendre les différences entre eux plus apparentes.

# set "connection" mark of connection from eth0 when first packet of connection arrives
Sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234

# set "firewall" mark for response packets in connection with our connection mark
Sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321

# our routing table with eth0 as gateway interface
Sudo ip route add default dev eth0 table 3412

# route packets with our firewall mark using our routing table
Sudo ip rule add fwmark 4321 table 3412

===

MISE À JOUR:

Ce qui précède fonctionne bien pour moi sur Debian Jessie. Mais sur un ancien système Wheezy, je viens de découvrir que je dois ajouter "via" à l'entrée de la table de routage:

# our routing table with eth0 as gateway interface
Sudo ip route add default dev eth0 via 12.345.67.89 table 3412

Là, "12.345.67.89" doit être la passerelle non VPN d'origine.

2
John Doe