Ipsec prerouting perte ip publique

Bonjour,

J’ai plusieurs serveur ipsec et je n’arrive pas au bout a avoir l’ip publique du client cela me pose des souci pour avoir les stats sur les sites héberger sur apache

ipserveur > ipsec 10.10.9.1/24 10.9.141.1/24 < ipsec ipserveur

le pont ipsec marche bien

distant :

auto eth0:10
iface eth0:10 inet static
        address 176.*.*.*
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up iptables -t nat -A PREROUTING  -d 176.*.*.* -j DNAT --to-destination 10.9.141.101
        post-up iptables -t nat -A POSTROUTING -d 10.9.141.101 -j SNAT --to-source 10.10.27.101

home :

auto vmbr0
iface vmbr0 inet static
        address 10.9.141.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up   iptables -t nat -A POSTROUTING -s '10.9.141.0/24'  -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '10.9.141.0/24'  -j MASQUERADE

Apache/2.4.38 (Debian) Server at 176...* Port 80
[SERVER_SOFTWARE] => Apache/2.4.38 (Debian) [SERVER_NAME] => 176...* [SERVER_ADDR] => 10.9.141.101 [SERVER_PORT] => 80 [REMOTE_ADDR] => 10.10.27.101 [DOCUMENT_ROOT] => /var/www/html [REQUEST_SCHEME] => http [CONTEXT_PREFIX] => [CONTEXT_DOCUMENT_ROOT] => /var/www/html [SERVER_ADMIN] => webmaster@localhost [SCRIPT_FILENAME] => /var/www/html/test.php [REMOTE_PORT] => 60136 [GATEWAY_INTERFACE] => CGI/1.1 [SERVER_PROTOCOL] => HTTP/1.1 [REQUEST_METHOD] => GET [QUERY_STRING] => [REQUEST_URI] => /test.php [SCRIPT_NAME] => /test.php [PHP_SELF] => /test.php [REQUEST_TIME_FLOAT] => 1620211256.7014 [REQUEST_TIME] => 1620211256 ) [GLOBALS] => Array RECURSION [_REQUEST] => Array ( ) [_ENV] => Array ( ) ) L adresse IP de l utilisateur est : 10.10.27.101
Merci de vos lumières

Je suis loin d’avoir tout compris dans ton exposé mais si tu fais du SNAT sur les connexions du client vers le serveur, ça masque forcément l’adresse IP du client.

c’est vrai que l’exposé n’ai pas terrible.

Un client a une adresse IP perso que l’on récupère dans les logs, apache ect…
La dans mon cas je perds l’adresse IP, le SNAT ne change que l’adresse de destination non?

Schématiquement :
IP perso demande google(ip x.x.x.x) on fait du SNAT pour dire que x.x.x.x doit être y.y.y.y, je ne vois pas pourquoi l’ip perso change

Non, c’est DNAT qui change l’adresse de destination. SNAT et MASQUERADE changent l’adresse source.

Mince me suis planter je voulais écrire DNAT

    post-up iptables -t nat -A PREROUTING  -d 176.x.x.x.x -j DNAT --to-destination 10.9.141.101

le client demande 176 .x.x.x je lui dis que c’est plus 176 mais 10.9.141.101 qui lui et un serveur apache avec un boutique prestashop (enfin bref cela peut être n’importe quoi). dans ce qu’a impossible d’avoir l’ip réel du client.

J’ai systématiquement l’ip to destination :

10.10.27.101 - - [05/May/2021:11:17:45 +0000] "GET / HTTP/1.1" 200 10986 "-" "-"
10.10.27.101 - - [05/May/2021:12:13:31 +0000] "GET / HTTP/1.1" 200 11005 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Donc soit c’est iptable qui déconne ou ipsec strongswan

Non, tu as systématiquement l’adresse 10.10.27.101 qui résulte de la règle iptables suivante :

post-up iptables -t nat -A POSTROUTING -d 10.9.141.101 -j SNAT --to-source 10.10.27.101

Quelle est la raison de cette règle ? (je soupçonne que c’est pour le routage retour, mais il y a d’autres moyens pour ça)

1 J'aime

oui c’est juste pour le routage retour, d’autre moyen ha ??

Oui, mais il faudrait en dire plus sur la topologique physique et logique complète du réseau.

Une Debian que l’on nome happy et une Debian que l’on nome cornichon, happy n’ai que là pour faire du routage elle a donc plusieurs IP publiques. Quand à cornichon elle et athome avec un proxmox

Le but final et que je dispose de plusieurs IP publique (happy) et que les services (web,mail,ect) sont sur cornichon.

Pour l’instant cela marche sauf que comme dis dans le premier post sur cornichon je ne récupère pas les IP des vrais clients mais 10.9.141.* cela pose donc des soucis dans les log et pour certain service comme par exemple les mail,web.

on commence par happy /etc/ipsec.conf

 #basic configuration 
 config setup
    charondebug="all"
    uniqueids=yes
 
 #connection to happy datacenter
conn happy-to-cornichon
    type=tunnel
    authby=secret
    keyexchange=ikev2
    #happy
    left=52.x.x.x
    leftsubnet=10.10.27.0/24
    #cornichon
    right=83.x.x.x 
    rightsubnet=10.9.141.0/24
    ike=aes256-sha1-modp1024!
    esp=aes256-sha1!
    aggressive=no
    keyingtries=%forever
    ikelifetime=1h
    lifetime=8h
    dpddelay=30
    dpdtimeout=120
    dpdaction=restart
    auto=start

/etc/network/interfaces

auto eth0:10
iface eth0:10 inet static
    address 176.x.x.x
    post-up echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up iptables -t nat -A PREROUTING  -d 176.x.x.x -j DNAT --to-destination 10.9.141.101
    post-up iptables -t nat -A POSTROUTING -d 10.9.141.101 -j SNAT --to-source 10.10.27.101

cornichon /etc/ipsec.conf

#basic configuration
config setup
    charondebug="all"
    uniqueids=yes

#connection to cornichon athome
conn cornichon-to-happy
    type=tunnel
    authby=secret
    keyexchange=ikev2
    #cornichon
    left=%any 
    leftid=83.x.x.x
    leftsubnet=10.9.141.1/24
    #happy
    right=52.x.x.x
    rightsubnet=10.10.27.1/24
    ike=aes256-sha1-modp1024!
    esp=aes256-sha1!
    aggressive=no
    keyingtries=%forever
    ikelifetime=1h
    lifetime=8h
    dpddelay=30
    dpdtimeout=120
    dpdaction=restart
    auto=start

/etc/network/interfaces

auto vmbr0
iface vmbr0 inet static
    address 10.9.141.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up   iptables -t nat -A POSTROUTING -s '10.9.141.0/24'  -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s '10.9.141.0/24'  -j MASQUERADE

Dans les log de la VM de cornichon, on reçois l’ip 10.10.27.101 alors qu’elle devrait être l’ip publique de ma box

10.10.27.101 - - [06/May/2021:04:41:24 +0000] "GET /test.php HTTP/1.1" 200 22408 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"

Et les autres interfaces de ces machines ?
Et les autres machines impliquées dans le cheminement du trafic ? (serveur web, routeurs…)
Et leurs tables de routage ?
Et les liaisons physiques ou virtuelles entre elles ?

heu Pascal IPSEC ça marche donc pas besoin de publier, j’ai aussi accès au service web…ect

happy et cornichon sont correcte

un client donc une box avec une ip x arrivent sur happy, happy renvoi les requêtes sur cornichon , mais sur cornichon je n’ai pas l’ip de la box, j’ai l’ip de happy

Donc de ce que je comprend c’est iptable qui me change la source (ip de la box) alors que je lui demande juste un transfert vers cornichon

J’ai fait d’autre test avec sur happy un nginx la pas de souci je récupère bien l’ip de la box sur cornichon. Seulement sur happy je ne voudrai pas avoir autre chose que le routage car ça me fait des double conf

sur happy : ipsec statusall

Status of IKE charon daemon (strongSwan 5.7.2, Linux 4.19.0-5-cloud-amd64, x86_64):
uptime: 3 hours, since May 06 07:09:14 2021
malloc: sbrk 1998848, mmap 0, used 1127664, free 871184
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
loaded plugins: charon test-vectors ldap pkcs11 tpm aesni aes rc2 sha2 sha1 md5 mgf1 rdrand   
random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey 
pem openssl gcrypt af-alg fips-prf gmp curve25519 agent chapoly xcbc cmac hmac ctr ccm gcm 
curl attr kernel-netlink resolve socket-default connmark farp stroke updown eap-identity eap-aka 
eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc xauth-generic xauth-eap 
xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock unity counters
Listening IP addresses:
 177.x.x.x
 52.x.x.x
 2001:x:x:x::x
 Connections:
happy-to-cornichon:  52.x.x.x...82.x.x.x  IKEv2, dpddelay=30s
happy-to-cornichon:   local:  [52.x.x.x] uses pre-shared key authentication
happy-to-cornichon:   remote: [82.x.x.x] uses pre-shared key authentication
happy-to-cornichon:   child:  10.10.27.0/24 10.10.28.0/24 === 10.9.141.0/24 10.9.142.0/24 
TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
happy-to-cornichon[5]: ESTABLISHED 31 minutes ago, 
52.x.x.x[52.x.x.x]...82.x.x.x[82.x.x.x]
happy-to-cornichon[5]: IKEv2 SPIs: 7cd80f30fa15ccba_i* c95c73adcdb0e73c_r, pre-shared key 
 reauthentication in 10 minutes
 happy-to-cornichon[5]: IKE proposal: 
 AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
 happy-to-cornichon{5}:  INSTALLED, TUNNEL, reqid 5, ESP in UDP SPIs: c16c8743_i c3375691_o
 shappy-to-cornichon{5}:  AES_CBC_256/HMAC_SHA1_96, 25132 bytes_i (25 pkts, 1088s ago), 1685 
 bytes_o (22 pkts, 1088s ago), rekeying in 7 hours
happy-to-cornichon{5}:   10.10.27.0/24 10.10.28.0/24 === 10.9.141.0/24 10.9.142.0/24

Ce n’est pas IPSec qui m’intéresse, c’est tout le reste du réseau…

happy : ip route

default via 53.*.*.* dev eth0 
53*.*.* dev eth0 scope link 
176.*.0.0/16 dev eth0 proto kernel scope link src 176.*.*.*

cornichon VM 101 : ip route

default via 10.9.141.1 dev eth0 onlink 
10.9.141.0/24 dev eth0 proto kernel scope link src 10.9.141.101

proxmox : ip route

default via 192.168.1.1 dev enp13s0f0 onlink 
10.9.141.0/24 dev vmbr0 proto kernel scope link src 10.9.141.1 
10.9.142.0/24 dev vmbr2 proto kernel scope link src 10.9.142.1 
192.168.1.0/24 dev enp13s0f0 proto kernel scope link src 192.168.1.155

DNAT = Destination NAT
SNAT = Source NAT

:upside_down_face:

Déjà tester pas de log correcte sur le distant

Je suggère de mettre en place un tunnel IPsec « routé » entre happy et cornichon. Happy serait la passerelle / route par défaut pour cornichon.

Avec Debian Buster, la version de strongSwan oblige à utiliser des interfaces « VTI ». La version de strongSwan dans Debian Bullseye autorisera un fonctionnement encore plus simple avec les interface « XFRM » gérées à partir de strongSwan 5.8.0 . Hélas, la version proposée par Bullseye n’a pas été rétroportée dans buster-backports.

D’autres en parlent mieux que moi et voici un très bon article à ce sujet. Il faut juste ne pas forcément tenir compte de l’aspect « espace de nom réseau » :

https://vincent.bernat.ch/fr/blog/2017-vpn-ipsec-route#vpn-route-avec-linux

La documentation officielle pour ce cas de figure utilise les interfaces xfrm et n’est donc pas encore utilisable.

Passer sur un tunnel IPsec routé permettra de supprimer la règle iptables qui pose problème ainsi que l’a très justement souligné PascalHambourg dans sa précédente réponse.


AnonymousCoward

1 J'aime

merci, ça fait peur quand même la premier image du site de Vincent, je ne suis pas spécialiste du réseau des choses me semble encore obscure.

Merci encore pour vos informations, la du coup je sais quoi déconne.
Après si vous avez d’autre façon de faire comme la dit Pascal je suis preneur

Bon j’ai refait ma conf avec la base d’un tunnel gre

avec la règle iptable 176.x.x.x c’est l’ip publique

iptables -t nat -A PREROUTING -d 176.*.*.*/32 -j DNAT --to-destination 10.10.10.2

de l’autre coter (10.10.10.2) je reçois bien les logs de la box :slight_smile:

07:54:52.144472 IP 10.9.141.2 > 82.x.x.x: ICMP echo reply, id 105, seq 9, length 64

Après plusieurs test je n’arrive pas a faire la règle retour de l’ip 10.10.10.1 vers l’ip publique si vous avez une suggestion merci.

Bonjour,

J’ai trouver une solution qui me conserve les LOG sur le dernier serveur :slight_smile: avec la bonne IP

Pour rappel j’ai un serveur avec une IP principale 51.x.x.x et plusieurs IP failover, l’idée et de rediriger les failover vers un serveur Proxmox at-home (derrière une Freebox) qui répond sur un ip local, les failover devant aller directement sur les VM.

Pour cela dans un premier temps j’utilise un tunnel GRE, on fera du ipsec over GRE après

On y va pour la conf :

sur les 2 serveurs :

apt install iptables iproute2

echo '100 GRE' >> /etc/iproute2/rt_tables
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf

#Tête de pont ou il y a les failover

ip tunnel del gre1
ip rule flush table GRE
ip tunnel add gre1 mode gre local 51..x.x.x remote  82.x.x.x ttl 255
ip addr add 10.0.0.1/24 dev gre1
ip link set gre1 up
ip route add default via 10.0.0.2 table GRE
ip rule add from 176.y.y.y table GRE
iptables -t nat -A PREROUTING -d 176.y.y.y ! -i gre1 -j DNAT --to 10.0.0.2

#FREE at-home on redirige les ports 4500 et 500 sur 192.168.1.155 (le Proxmox), c’est pour le tunnel GRE

ip tunnel add gre1 mode gre local 192.168.1.155 remote 51.x.x.x ttl 255
ip addr add 10.0.0.2/24 dev gre1
ip link set gre1 up
ip route add default via 10.0.0.1 table GRE
ip rule add from 176.y.y.y/32 table GRE
iptables -t nat -A PREROUTING -d 10.0.0.0/24  -i gre1 -j DNAT --to-destination 176.y.y.y

sur le Proxmox

auto vmbr0
iface vmbr0 inet static
    address 176.y.y.1/30
    bridge-ports none
    bridge-stp off
    bridge-fd 0

et la VM

auto eth0
iface eth0 inet static
address 176.y.y.y/30
# --- BEGIN PVE ---
post-up ip route add 10.0.0.2 dev eth0
post-up ip route add default via 10.0.0.2 dev eth0
pre-down ip route del default via 10.0.0.2 dev eth0
pre-down ip route del 10.0.0.2 dev eth0
# --- END PVE ---

en faite sur la VM depuis l’interface Proxmox on lui donne juste l’ip failover 176.y.y.y/30, passerelle 10.0.0.2, il remplira comme un grand eth0

on fait un curl comme un internaute lambda et on regarde les logs d’apache.

curl 176.y.y.y

Log d’apache

33.b.b.b - - [23/May/2021:15:46:32 +0000] "GET / HTTP/1.1" 200 10986 "-" "curl/7.68.0"

Il me reste a faire le contraire pour que la VM sorte avec l’ip 176.y.y.y pourquoi, simplement si c’est un serveur de mail ou autre que l’ip soit 176.y.y.y et non pas l’ip de la Freebox 82.x.x.x