Autoriser SSH sur un serveur avec un client OpenVPN actif

J'ai un VPS exécutant CentOS 7 auquel je me connecte avec SSH. Je voudrais exécuter un client OpenVPN sur le VPS afin que le trafic Internet soit acheminé via le VPN, mais me permettre toujours de me connecter au serveur via SSH. Lorsque je démarre OpenVPN, ma session SSH est déconnectée et je ne peux plus me connecter à mon VPS. Comment puis-je configurer le VPS pour permettre aux connexions SSH entrantes (port 22) d'être ouvertes sur l'IP réelle du VPS (104.167.102.77), mais toujours acheminer le trafic sortant (comme à partir d'un navigateur Web sur le VPS) via le VPN?

Le service OpenVPN que j'utilise est PrivateInternetAccess, et un exemple de fichier config.ovpn est:

client
dev tun
proto udp
remote nl.privateinternetaccess.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
tls-client
serveur distant-cert-tls
auth-user-pass
comp-lzo
verbe 1
reneg-sec 0
crl-verify crl.pem

Adresse IP de VPS:

1: lo: mtu 65536 qdisc noqueue state UNKNOWN
    lien / bouclage 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever forever_lft forever
    inet6 :: Hôte de portée 1/128
       valid_lft forever forever_lft forever
2: ens33: mtu 1500 qdisc pfifo_fast state UP qlen 1000
    lien / éther 00: 50: 56: être: 16: f7 brd ff: ff: ff: ff: ff: ff
    inet 104.167.102.77/24 brd 104.167.102.255 portée mondiale ens33
       valid_lft forever forever_lft forever
    inet6 fe80 :: 250: 56ff: febe: 16f7 / 64 lien de portée
       valid_lft forever forever_lft forever
4: tun0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    lien / aucun
    inet 10.172.1.6 homologue 10.172.1.5/32 portée globale tun0
       valid_lft forever forever_lft forever

Route IP de VPS:

0.0.0.0/1 via 10.172.1.5 dev tun0
par défaut via 104.167.102.1 dev ens33 métrique statique proto 1024
10.172.1.1 via 10.172.1.5 dev tun0
10.172.1.5 dev tun0 proto kernel scope link src 10.172.1.6
104.167.102.0/24 dev ens33 proto kernel scope link src 104.167.102.77
109.201.154.177 via 104.167.102.1 dev ens33
128.0.0.0/1 via 10.172.1.5 dev tun0

J'ai un problème similaire à celui-ci et j'ai essayé le correctif décrit dans ce message sur le forum .

L'idée est qu'actuellement, lorsque vous vous connectez à votre adresse IP publique, les paquets de retour sont acheminés via le VPN. Vous devez forcer ces paquets à être routés sur votre interface publique.

Nous espérons que ces commandes de route feront l'affaire:

règle ip ajouter à partir du tableau xxxx 128

ip route add table 128 to yyyy / y dev ethX

ip route add table 128 default via zzzz

Où xxxx est votre IP publique, yyyy / y devrait être le sous-réseau de votre adresse IP publique, ethX devrait être votre interface Ethernet publique et zzzz devrait être la passerelle par défaut.

Notez que cela n'a pas fonctionné pour moi (en utilisant Debian et PrivateInternetAccess) mais peut vous aider.

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, on suppose 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.

Sur la base de la réponse @MrK, j'ai écrit un code simple ici pour accélérer le travail afin que vous n'ayez pas à vérifier les interfaces / IP:

ip rule add from $(ip route get 1 | grep -Po '(?<=src )(\S+)') table 128
ip route add table 128 to $(ip route get 1 | grep -Po '(?<=src )(\S+)')/32 dev $(ip -4 route ls | grep default | grep -Po '(?<=dev )(\S+)')
ip route add table 128 default via $(ip -4 route ls | grep default | grep -Po '(?<=via )(\S+)')

J'ai essayé ce script sur 4 de mes VPS et cela fonctionne parfaitement.

hmm sonne comme un chevauchement de sous-réseaux ip .... sans en savoir plus sur votre schéma ip, autre que l'ip public pour votre ternmination vpn comme nl.privateinternetaccess.com, ne peut pas le dire avec certitude.

ainsi, par exemple, si le sous-réseau distant de l'autre côté de nl.privateinternetaccess.com est 10.32.43.0/24, et que votre instance se trouve dans un vpc aws dont le sous-réseau est 10.32.44.0/24. mais votre client ssh source vit sur 10.32.43.0/24 (votre côté de aws vpc), cela ne fonctionnera pas, car le trafic de retour ssh sera poussé par erreur sur vpn vers les pays-bas.

fournir des informations complètes sur ip / sous-réseau pour plus d'aide à ce sujet.

...

ok, donc ... on dirait que votre route par défaut est dans le tunnel, après vous être connecté à nl:

0.0.0.0/1 via 10.172.1.5 dev tun0

vous pouvez donc changer cela après vous être connecté. beaucoup de fois les serveurs VPN vous donnent de fausses routes. spécialement au corps bâclé. dans ce cas, ils vous envoient une route par défaut, donc tout le trafic provenant de la zone vps va vers nl. changez la route par défaut en 104.167.102.x ou quelle que soit la passerelle de sous-réseau ur au fournisseur ur vps.

Lorsque vous amenez le VPN, votre passerelle par défaut est remplacée. Cela signifie que tout trafic généré à partir de ou acheminé via votre box sera transféré vers la passerelle VPN.

Une solution simple consiste à filtrer tout le trafic que vous ne souhaitez pas acheminer via le VPN et à faire autre chose avec. Une possibilité consiste à récupérer le trafic généré à partir de votre box avec votre adresse source locale et à l'acheminer via votre passerelle locale. Cela permet à des services tels que SSH de fonctionner correctement.

Nous le ferons ici. Tout d'abord, créez une nouvelle table de routage et ajoutez une route par défaut qui achemine tout via votre passerelle locale:

# <table> is any number between 2 and 252.
# Check /etc/iproute2/rt_tables for more info.
ip route add default via <gateway> table <table>
ip route add <lan-addr> dev <device> table <table>

Ensuite, créez une nouvelle règle de filtrage de paquets qui marque tout le trafic quittant votre boîte à partir d'une adresse source donnée avec un identifiant.

# <mark> is any number.
iptables -tmangle -AOUTPUT -s<local-addr> -jMARK --set-mark <mark>

Enfin, créez une politique de routage qui sélectionne tout le trafic marqué susmentionné et l'achemine à l'aide du tableau généré ci-dessus.

ip rule add fwmark <mark> table <table>

Encore une fois, les valeurs de <mark>et <table>sont des identificateurs arbitraires de votre choix.

Pour moi, avec l'exécution du serveur OpenVPN moi-même dans pfSense, je devais décocher le paramètre "Forcer tout le trafic IPv4 généré par le client à travers le tunnel".