Notes :
- Nous ne savons pas vraiment à quoi ressemble en détail la configuration interne du réseau de partenaires et nous ne nous en préoccupons pas. Nous connaissons juste l'adresse IP publique de leur point d'extrémité (
1.1.1.1
), leur réseau interne ( 10.10.10.0/24
) et l'adresse IP de leur(s) serveur(s) (par exemple 10.10.10.1
)
- Notre
vpn-router-server
est un serveur IAAS hébergé par un fournisseur de cloud public. Il dispose d'une adresse IP externe directement accessible ( 2.2.2.2
). Il utilise une passerelle pour atteindre l'internet, mais comme le fournisseur IAAS s'occupe de tout cela, nous ne l'incluons pas dans notre diagramme.
Dans cet exemple, nous nous concentrerons sur le scénario suivant :
- Notre
client1
enverra un ping
a target server1
. Les autres clients et serveurs cibles fonctionnent exactement de la même manière, seuls leurs adresses IP sont différentes.
Sur client1
:
# tell the client to send all traffic for the partner network to the vpn-router-server
$ route add -net 10.10.10.0 gw 192.168.1.1
Sur vpn-router-server
: /etc/ipsec.conf
-configuration
config setup
uniqueids = yes
conn con1
aggressive = no
fragmentation = yes
keyexchange = ikev2
mobike = yes
reauth = yes
rekey = yes
forceencaps = no
installpolicy = yes
left = %any
leftid = 2.2.2.2
leftsubnet = 192.168.1.0/24
leftauth = psk
right = 1.1.1.1
rightid = 1.1.1.1
rightsubnet = 10.10.10.0/24
rightauth = psk
ikelifetime = 86400s
lifetime = 3600s
ike = aes256gcm16-sha512-ecp521!
reqid = 1000
esp = aes256-sha512-ecp521,aes256gcm16-sha512-ecp521,3des-sha512-ecp521,cast128-sha512-ecp521!
auto = start
Set (jeu de mots) iptable
-règles :
$ iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 ! -p esp -j SNAT --to-source 192.168.1.1
-s 192.168.1.0/24
appliquer le SNAT uniquement au trafic provenant de notre réseau interne
-o eth0
appliquer le SNAT uniquement au trafic sortant par l'interface externe eth0
! -p esp
Ne pas SNAT le trafic DSP / ipsec lui-même. C'est la partie la plus importante et je l'avais oubliée auparavant.
-j SNAT
SNAT le trafic
--to-source 192.168.1.1
Utiliser le vpn-router-server
ip interne comme ip source pour les paquets SNATés
T client1
devrait maintenant être en mesure d'envoyer un ping à target server1
:
$ ping 10.10.10.1
Vous pouvez analyser ce qui se passe dans le vpn-router-server
en utilisant tcpdump
:
$ tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
07:10:37.150680 IP 10.10.10.1 > 192.168.1.1: ICMP echo reply, id 7642, seq 1, length 64
07:10:38.152097 IP 10.10.10.1 > 192.168.1.1: ICMP echo reply, id 7642, seq 2, length 64
07:10:39.153237 IP 10.10.10.1 > 192.168.1.1: ICMP echo reply, id 7642, seq 3, length 64
07:10:40.153997 IP 10.10.10.1 > 192.168.1.1: ICMP echo reply, id 7642, seq 4, length 64
07:10:41.154766 IP 10.10.10.1 > 192.168.1.1: ICMP echo reply, id 7642, seq 5, length 64
07:10:42.155937 IP 10.10.10.1 > 192.168.1.1: ICMP echo reply, id 7642, seq 6, length 64
$ tcpdump -n -i eth1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
07:10:46.156162 IP 192.168.1.101 > 10.10.10.1: ICMP echo request, id 7642, seq 10, length 64
07:10:46.161079 IP 10.10.10.1 > 192.168.1.101: ICMP echo reply, id 7642, seq 10, length 64
07:10:47.157485 IP 192.168.1.101 > 10.10.10.1: ICMP echo request, id 7642, seq 11, length 64
07:10:47.162435 IP 10.10.10.1 > 192.168.1.101: ICMP echo reply, id 7642, seq 11, length 64
07:10:48.158920 IP 192.168.1.101 > 10.10.10.1: ICMP echo request, id 7642, seq 12, length 64
07:10:48.163772 IP 10.10.10.1 > 192.168.1.101: ICMP echo reply, id 7642, seq 12, length 64
07:10:49.160364 IP 192.168.1.101 > 10.10.10.1: ICMP echo request, id 7642, seq 13, length 64
07:10:49.165322 IP 10.10.10.1 > 192.168.1.101: ICMP echo reply, id 7642, seq 13, length 64