J'ai un serveur privé virtuel, que j'aimerais faire fonctionner 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 chaque minute envoie un ping à un autre VPS à moi, exécutant apache2 Dans les journaux apache2, je peux voir l'adresse IP d'origine changer de 50.1.2.3 à 175.41.42.43, lorsque VPN est actif, donc VPN fonctionne bien
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 faire ssh 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 @
signes 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?
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.
===
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:
Là, "12.345.67.89" doit être la passerelle non VPN d'origine.
la source