3 votes

Configurer linux pour acheminer le trafic du réseau interne via un tunnel ipsec (basé sur une politique)

Mon entreprise héberge des services en nuage. Nous avons un partenaire qui héberge également des services en nuage. Nous voulons connecter notre réseau au sien en utilisant ipsec / strongswan. Nos clients devraient être en mesure d'atteindre les serveurs cibles à l'aide de la technologie vpn-router-server comme routeur / passerelle vopn.

La configuration est la suivante :

network setup as described in the text

Comment dois-je configurer mes clients et le système de gestion de l'information ? vpn-router-server ?

3voto

Niraj Bhusal Points 1

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

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X