Bonjour,
Si vous avez des suggestion a me faire pour le choix du VPN, je mis perd un peu.
Je vais surement prendre 2 serveurs avec un hébergeur qui propose 16ip par machine, j’ai a ma disposition chez moi plusieurs serveurs. Je voudrai faire un VPN entre l’hébergeur et chez moi.
Première IP publique, que la redirection soit sur le réseau local en ex 192.168.10.x et ainsi de suite.
J’ai lu plein de truc différents, du coup c’est le bordel dans ma tête, merci pour vos lumières
d’où la question qui est tout sauf claire 
Si tu cherches un applicatif OpenVpn est la référence…
Entre l’hébergeur et chez moi, ssh (scp, rsync over ssh, …) est nécessaire et suffisant …
Si tu cherches un fournisseur, il y a bcps et il faut regarder les tarfis, les zones proposées et surtout la politique de confidentialité/pays de référence.
En gros je souhaite remonter mes ip local vers un serveur.
1 serveur en location avec proxmox + nginx, je fait du proxy_pass sur des ip local donc qui sont chez moi.
Je pense qu’il faut faire du VPN pour que les ip local (qui sont chez moi) remonter sur les serveur loué. Donc au final je fait de la location de serveur pour avoir 32 IP mes avec les serveurs chez moi at home.
J’ai vu L2TP ethernet pseudowires par contre je ne sais pas si c’est le bon choix
Désoler mais je ne vois pas comment expliquer cela autrement
On remonte une horloge par exemple, mais en 2020 on doit bien pouvoir remonter des IP locales 
Blague à part, il me semble qu’une option -L (ou -R) dans la page
man ssh
devrait être explorée. C’est plus bas niveau et besogneux qu’un Virtual Private Network, mais au moins on peut expérimenter pas à pas.
Il se peut que je sois complètement à côté de la plaque, l’expression “remonter des IP locales vers un serveur” m’échappe complètement.
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
F. Petitjean
Ingénieur civil du Génie Maritime.
« Ce que l’on conçoit bien s’énonce clairement,
Et les mots pour le dire arrivent aisément. »
Boileau De L’Art poétique (Chant I)
« Avant donc que d’écrire, apprenez à penser »
Boileau De L’Art poétique (Chant I)
Bonjour,
Si je comprend bien ton projet, tu souhaite faire un VPN entre ton réseau local et le serveur hébergé?
Voici une bonne réponse, OpenVPN est une bonne référence pour mettre en place un VPN entre 2 serveurs.
Lors de l’installation et configuration d’OpenVPN il me semble que tu as la possibilité d’encapsulé dans le VPN la connexion ssh.
Pour l’instant je fait des tests avec strongswan le tunnel monte bien juste un souci pour le vmbr qui n’arrive pas a communiquer avec l’interface
establishing CHILD_SA athome-vpn{28}
generating CREATE_CHILD_SA request 7 [ SA No KE TSi TSr ]
sending packet: from 148...[4500] to 46...[4500] (576 bytes)
received packet: from 46...[4500] to 148...[4500] (480 bytes)
parsed CREATE_CHILD_SA response 7 [ SA No KE TSi TSr ]
selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
CHILD_SA athome-vpn{28} established with SPIs c74a6032_i ccfa4100_o and TS 10.0.1.0/24 === 10.0.2.1/32
connection ‘athome-vpn’ established successfully
@Doudou67 - Hello, je pense que tu ne maîtrises pas encore tout à fait les différentes couches du modèle OSI mais qu’il est important que tu te penches dessus.
En gros :
Il existe des dizaines de technologies différentes pour faire un tunnel / VPN. Tu utilises apparemment IPSEC/ESP, qui fait transiter de l’IP, de la couche 3.
Il faut donc mettre du routage pour que ta VM faisant fonctionner nginx puisse envoyer des données / des paquets IP à destination des serveurs web situés chez toi.
Si besoin, nous pourrons t’expliquer les bases du routage pour réaliser ce que tu veux faire. Mais il me semblait important de clarifier ces aspects fondamentaux des réseaux informatiques.
–
AnonymousCoward
@AnonymousCoward merci pour les explications
Il faut donc mettre du routage pour que ta VM faisant fonctionner nginx puisse envoyer des données / des paquets IP à destination des serveurs web situés chez toi.
Pour les couches merci des explications, j’avais vraiment du mal a saisir. du coup c’est quand même plus claire dans ma tête.
Je résume : Le VPN c’est ok, IP distant vers IP at home.
Ping de distant vers athome
64 bytes from 10.0.2.1: icmp_seq=1 ttl=64 time=17.3 ms
Pour le test je monte une 2em vmbr sur athome
64 bytes from 10.0.2.2: icmp_seq=1 ttl=64 time=17.0 ms
Yes ça répond 
Install de nginx conf d’un domaine test.****.com
avec proxy_pass http://10.0.2.2:80;
Je passe sur la conf d’apache c’est pas le sujet…
On y va dans la vrai vie navigateur http://test.***.com et bing ça répond avec ma belle page de test
Encore un grand merci pour l’aide, là du coup je vais refaire la manip entièrement histoire de me faire une doc et de publier la solution, ça servira surement pour d’autre personnes.
Je pense qu’il y a surement un moyen plus simple, exemple faire du routage sur le serveur distant pour dire …
genre 78.79.1.2 vers 10.0.2.2
78.79.1.3 vers 10.0.2.3
ect…
IP (distante) = IP local (athome) bien sur en passant par le Vpn, ou bien je suis obliger de passer par un Nginx sur le distant ?
Actuellement, tu utilises nginx en tant que “reverse proxy” pour les serveurs web à ton domicile.
Comme tu as l’air d’avoir souscrit à une adresse IPv4 supplémentaire par serveur hébergé chez toi, tu peux utiliser iptables pour renvoyer tout ce qui arrive pour une IP genre 62.210.1.X vers ton 10.0.2.X à la maison.
Pour cela, il faut que toutes tes IPs supplémentaires soient configurées sur une VM ou directement sur ton hôte Proxmox VE avec un /etc/network/interfaces du genre :
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 195.154.176.66/24
gateway 62.210.0.1
# failover 1
iface eth0 inet static
address 51.15.150.50
# failover 2
iface eth0 inet static
address 51.15.150.51
# failover 3
iface eth0 inet static
address 51.15.150.52
Cet exemple fictif permet de s’assurer que ton système montre au routeur de l’hébergeur (via ARP) que oui, tu réponds pour cette adresse IPv4.
Ensuite, tu fais du Destination NAT (DNAT) en ajoutant une règle comme ci-dessous par adresse IP que tu veux renvoyer :
sudo iptables -t nat -A PREROUTING --dst 51.15.150.50 -j DNAT --to-destination 10.0.2.X
La grosse différence par rapport à nginx avec proxy_pass, c’est que tes machines à la maison vont devoir utiliser le VPN comme route par défaut.
Puisque avec nginx, les requêtes web avaient comme IP source l’adresse du nginx alors que là, l’adresse IP source sera celle du véritable client sur Internet.
–
AnonymousCoward
Donc au programme relire la Doc du modèle OSI, relire et comprendre les différents /layer*, TP sur iptables histoire de pas faire de boulettes, rependre les aspects des différents Vpn cela même si je pense avoir saisie .
Je vais faire une test ce week grandeur nature avec 2 machines propre, histoire de reprendre l’installation du Vpn, proxmox, nginx ect… et iptables-persistent
La grosse différence par rapport à nginx avec
proxy_pass, c’est que tes machines à la maison vont devoir utiliser le VPN comme route par défaut.
Puisque avec nginx, les requêtes web avaient comme IP source l’adresse du nginx alors que là, l’adresse IP source sera celle du véritable client sur Internet.
Effectivement dans la configuration actuelle impossible d’avoir l’IP du véritable client sur athome, on a forcément les IP du VPN.
Encore merci @AnonymousCoward les explications que tu ma donner… c’est du gâteau
Nginx n’est pas capable de transmettre l’adresse IP source d’origine dans un champ de l’en-tête HTTP du genre X-Forwarded-for ?
Non pas forcément. Seulement pour router le trafic retour avec du routage avancé. Il y a différentes techniques pour identifier ce trafic, la plus simple à mon avis étant d’utiliser une adresse IP secondaire pour les communications via le VPN.
@PascalHambourg
Nginx n’est pas capable de transmettre l’adresse IP source d’origine dans un champ de l’en-tête HTTP du genre X-Forwarded-for ?
D’après la doc c’est possible
X-Forwarded-for
J’avais déjà utiliser un truc du genre pour quelque chose de spécifique.
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
C’est toujours possible avec Nginx par contre cela fait une conf de plus, donc inutile.
D’après les explication d’@AnonymousCoward le serveur hébergent les IP servira uniquement au routage, ce qui me convient parfaitement. IP public iptables > Vpn et coter local Vpn Nginx ect…
J’ai quand même fait un test vite fait avec
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
a la réception il reste muet uniquement l’Ip du Vpn
10.0.1.1 - - [21/Feb/2020:10:58:23 +0100] “GET / HTTP/1.1” 200 38 “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36”
Normal, ce log ne contient pas l’en-tête HTTP complet. Il y a peut-être moyen de le personnaliser pour ajouter des champs.
proxy_pass http://10.0.2.2:80;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Real-IP $remote_addr ;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
Ca récupère juste le X-Real-IP
E…-@.@…
…
…P…b.L}R…7…
R.R…&.GET / HTTP/1.1
Connection: upgrade
Host: test.*.com
X-Real-IP: x.x.x.x
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
J’ai fait une re install complète communication avec le VPN ok
ping du distant 10.0.2.2 ok
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_seq=1 ttl=64 time=16.2 ms
un tcpdump de l’autre coter ca réceptionne bien
tcpdump -i any host 10.0.2.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
18:34:36.925056 IP 10.0.1.1 > 10.0.2.2: ICMP echo request, id 3427, seq 1, length 64
Rajout de 2 ip failover sur le distant ca répond, on rajoute la règle Iptables, j’ai bien sur changer l’ip dst
iptables -t nat -A PREROUTING --dst 51.15.150.50 -j DNAT --to-destination 10.0.2.2
Plus de réponse rien nada, tcpdump reste muet le ping aussi
Humm de retour d’un petit resto j’ai fait les test suivant
ping d’une box vers le distant failover bein iptables marche normalement
tcpdump -i any host 10.0.2.2 resultat
22:16:00.816360 IP******.subs.proxad.net > 10.0.2.2: ICMP echo request, id 11668, seq 10227, length 64
Du coup je pense que c’est le VPN qui déconne
J’ai fait un test manuel avec Gre bah la du coup ca marche
coter VPS distant (ip eth0 45.15.22.122 (fictif) et 51.15.150.50(fictif) c’est l’ip failover)
root@vps792393:~# ip tunnel add gre1 mode gre remote 45.15.22.122 local 51.90.59.119 ttl 255
root@vps792393:~# ip link set gre1 up
root@vps792393:~# ip addr add 10.10.10.1/24 dev gre1
root@vps792393:~# iptables -t nat -A PREROUTING -d 51.15.150.50 -j DNAT --to-destination 10.10.10.2
root@vps792393:~# iptables -t nat -A POSTROUTING -o gre1 -d 10.10.10.2 -j SNAT --to-source 10.10.10.1
coter serveur a la maison
root@vzc:~# ip tunnel add gre1 mode gre remote 51.90.59.119 local 45.15.22.122 ttl 255
root@vzc:~# ip link set gre1 up
root@vzc:~# ip addr add 10.10.10.2/24 dev gre1
du coup on monte les interfaces automatiquements
coter VPS distant
auto tun0
iface tun0 inet static
address 10.10.10.1
netmask 255.255.255.0
up ifconfig tun0 multicast
pre-up iptunnel add tun0 mode gre remote 45.15.22.122 local 51.90.59.119 ttl 255
pointopoint 10.10.10.2
post-down iptunnel del tun0
iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6
coter serveur a la maison
auto tun0
iface tun0 inet static
address 10.10.10.2
netmask 255.255.255.0
up ifconfig tun0 multicast
pre-up iptunnel add tun0 mode gre remote 51.90.59.119 local 45.15.22.122 ttl 255
pointopoint 10.10.10.1
post-down iptunnel del tun0
Reboot des 2 serveurs histoire de voir si le Gre monte bien et que les règles iptable sont bien présente pas de souci ca marche.
Donc j’ai bien un souci avec IPSEC, j’ai refait un test avec GRE+IPSEC avec openswan a partir du moment ou j’active ipsec plus rien ne passe j’ai l’impression qu’il manque quelque chose dans la conf d’ipsec
Je vais faire des testes, après là lecture d’ipsec.