IPsec VPN Site à site: Comment dois-je configurer les fichiers ipsec.conf sur les deux sites pour obtenir le tunnel?
Ce que j'essaie de faire, c'est créer un VPN IPsec Site à site entre mon réseau et le réseau de mon ami. Nous avons tous les deux un routeur et deux ordinateurs sur chaque routeur, avec tous les ordinateurs exécutant Linux. Donc je suppose que la topologie ressemble à ceci
[myPC1 + myPC2] --- MyRouter ------ Internet ----- HisRouter --- [HISPC1 + HISPC2]
Les deux routeurs sont bon marché, ils n'ont donc rien d'aimer OpenWrt.
Donc, la configuration - je suppose que cela devrait être fait sous Linux des deux côtés.
Jusqu'à présent, nous avons essayé avec Openenswan à la fois avec des clés RSA et des PSK, mais après la commande
ipsec auto --up net-to-net
nous obtenons l'erreur "Aucune connexion nommée Net-to-Net" ou l'erreur "Nous ne pouvons pas nous identifier avec une extrémité de cette connexion."
Je suppose que nous configurons le fichier ipsec.conf faux. Quelqu'un pourrait-il expliquer comment nous devrions le configurer correctement pour atteindre cette topologie, s'il vous plaît?
ÉDITER...
Voici quelques faits qui pourraient vous aider à mieux comprendre mon cas.
[.____] Celles-ci sont toutes de l'exemple PSK que nous avons testé.
Mon ifconfig:
eth0 Link encap:Ethernet HWaddr 00:0C:29:1B:F5:1C
inet addr:192.168.1.78 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe1b:f51c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:829 errors:0 dropped:0 overruns:0 frame:0
TX packets:704 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1213737 (1.1 MiB) TX bytes:57876 (56.5 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:53 errors:0 dropped:0 overruns:0 frame:0
TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3664 (3.5 KiB) TX bytes:3664 (3.5 KiB)
Son ifconfig
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:240 (240.0 b) TX bytes:240 (240.0 b)
p2p1 Link encap:Ethernet HWaddr 08:00:27:2A:F1:F5
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe2a:f1f5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:21104 errors:0 dropped:0 overruns:0 frame:0
TX packets:12458 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16079321 (15.3 MiB) TX bytes:1012204 (988.4 KiB)
Le fichier ipsec.conf, nous avons tous deux utilisé exactement le même fichier, nous l'avons également placé dans /etc/init.d
version 2.0
config setup
protostack=netkey
nat_traversal=yes
#virtual_private=
oe=off
conn net-to-net
authby=secret # Key exchange method
left=212.251.112.115 # Public Internet IP address of the
leftsubnet=10.0.2.0/24 # Subnet protected by the LEFT VPN device
leftnexthop=%defaultroute # correct in many situations
right=79.103.7.114 # Public Internet IP address of
rightsubnet=192.168.1.0/24 # Subnet protected by the RIGHT VPN device
rightnexthop=%defaultroute # correct in many situations
auto=start # authorizes and starts this connection
Nous avons également utilisé exactement les mêmes IPsec.Secrets, que nous avons tous deux placés dans /etc/init.d
212.251.112.115 79.103.7.114 : PSK "123"
nous avons obtenu ces IP avec CURL IFCONFIG.ME après cette configuration que nous exécutons:
service ipsec restart
ipsec verify
et nous avons eu le même message d'échec dans les send_redirects, qui ont refusé de changer à 0
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path [OK]
Linux Openswan U2.6.37/K3.1.0-7.fc16.x86_64 (netkey)
Checking for IPsec support in kernel [OK]
SAref kernel support [N/A]
NETKEY: Testing XFRM related proc values [FAILED]
Please disable /proc/sys/net/ipv4/conf/*/send_redirects
or NETKEY will cause the sending of bogus ICMP redirects!
[FAILED]
Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
or NETKEY will accept bogus ICMP redirects!
[OK]
Checking that pluto is running [OK]
Pluto listening for IKE on udp 500 [OK]
Pluto listening for NAT-T on udp 4500 [OK]
Checking for 'ip' command [OK]
Checking /bin/sh is not /bin/dash [OK]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]
ensuite, nous avons procédé avec
ipsec auto --up net-to-net
et nous avons tous les deux obtenu
022 "net-to-net": We cannot identify ourselves with either end of this connection.
Je ne sais pas si cela aide, peut-être que vous avez déjà remarqué ce qui ne va pas, mais voici une dernière chose, le statut d'IPSec:
ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo ::1
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 192.168.1.78
000 interface eth0/eth0 192.168.1.78
000 %myid = (none)
000 debug none
000
000 virtual_private (%priv):
000 - allowed 0 subnets:
000 - disallowed 0 subnets:
000 WARNING: Either virtual_private= is not specified, or there is a syntax
000 error in that line. 'left/rightsubnet=vhost:%priv' will not work!
000 WARNING: Disallowed subnets in virtual_private= is empty. If you have
000 private address space in internal use, it should be excluded!
000
000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64, keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8, keysizemin=40, keysizemax=128
000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448
000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8, keysizemin=160, keysizemax=288
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
000 algorithm ESP auth attr: id=6, name=AUTH_ALGORITHM_HMAC_SHA2_384, keysizemin=384, keysizemax=384
000 algorithm ESP auth attr: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512, keysizemin=512, keysizemax=512
000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
000
000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=131
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000 algorithm IKE dh group: id=22, name=OAKLEY_GROUP_DH22, bits=1024
000 algorithm IKE dh group: id=23, name=OAKLEY_GROUP_DH23, bits=2048
000 algorithm IKE dh group: id=24, name=OAKLEY_GROUP_DH24, bits=2048
000
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0}
000
000 "net-to-net": 10.0.2.0/24===212.251.112.115<212.251.112.115>[+S=C]---192.168.1.254...192.168.1.254---79.103.7.114<79.103.7.114>[+S=C]===192.168.1.0/24; unrouted; eroute owner: #0
000 "net-to-net": myip=unset; hisip=unset;
000 "net-to-net": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "net-to-net": policy: PSK+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 24,24; interface: ;
000 "net-to-net": newest ISAKMP SA: #0; newest IPsec SA: #0;
Une autre question concerne la manière dont le problème NetKey [Échec] pourrait être résolu, si nécessaire!
Ma parole, vous avez votre travail découpé. D'ACCORD; Voici une sorte d'apprêt de contour, car au moment où vous avez les principes fondamentaux si mal que les détails ne comptent pas.
Avant toute autre chose, le fait que vous n'aviez pas d'adresses publiques statiques pour chacune de vos connexions Internet est un problème. IPsec ne supporte pas facilement les tunnels dans de telles configurations [1], vous allez donc finir par éditer votre ipsec.conf à chaque fois de vos adresses changements. D'ACCORD?
Maintenant, quand je vous ai demandé si chaque point d'extrémité OpenSwan avait une adresse IP publique et que vous avez dit de manière confiant "oui", il s'avère - comme je soupçonnais - que vous aviez tort. Votre sortie ifconfig me montre qu'une extrémité a l'adresse 192.168.1.78 et l'autre a l'adresse 10.0.2.15. Vous me dites aussi qu'une extrémité est (actuellement) derrière L'adresse IP publique 212.251.112.115 et l'autre est derrière le 79.103.7.114. Vous ne dites pas ce qui est lequel, donc je supposerai le 192.168.1.78 est derrière le 212.251.112.115 et 10.0.2.15 est derrière le 79.103.7.114. Si tel est faux, inversez simplement la correspondance. Je vais aussi appeler l'ancienne paire gauche et la dernière paire à droite. Cela ne fait aucune différence qui, mais cela nous aidera à garder notre réflexion droite, ce qui serait un vraiment bonne idée à propos de maintenant.
Vous aurez besoin de configurer les routeurs publics aux deux extrémités pour transférer UDP/500 et des protocoles 50 et 51 (juste pour l'exhaustivité) aux points d'extrémité openswan à l'intérieur de chaque adresse publique. Si vous ne pouvez pas gérer les deux percheminements de protocole, recherchez le doco sur NAT Traversal et Transférer UDP/4500.
Premièrement, c'est une exigence que chaque extrémité trouve sa propre adresse IP dans la configuration, de sorte que chaque extrémité puisse savoir lequel de gauche et de droite est quand il commence. Tellement laissé besoin d'avoir un ipsec.conf cela contient
conn net-to-net
authby=secret
left=192.168.1.78
leftsubnet=192.168.1.0/24
leftnexthop=%defaultroute
right=79.103.7.114
rightsubnet=10.0.2.0/24
et un ipsec.secrets ça dit
192.168.1.78 79.103.7.114: PSK "123"
alors que le droit doit avoir un ipsec.conf cela contient
conn net-to-net
authby=secret
left=212.251.112.115
leftsubnet=192.168.1.0/24
right=10.0.2.15
rightsubnet=10.0.2.0/24
rightnexthop=%defaultroute
et un ipsec.secrets ça dit
10.0.2.15 212.251.112.115: PSK "123"
Chaque extrémité a vraiment besoin de savoir qui c'est vraiment, tandis que cela peut prétendre que cela ne se soucie pas que la fin distante soit derrière une nat. Est-ce que tu vois?
En outre, vous devrez configurer tous les clients à chaque extrémité de manière à ce qu'ils aient un itinéraire vers le réseau RFC1918 distant via le point d'extrémité local OpenSwan. Vous devrez vérifier que /proc/sys/net/ipv4/ip_forward est défini sur 1 sur chaque point d'extrémité. Et ce serait une très bonne idée d'éteindre tout pare-feu sur les deux points de terminaison, au moins pour le moment. Vous devrez peut-être également activer certaines variables de configuration qui indiquent à chaque point de terminaison de ne pas prendre en charge que le point d'extrémité distant pense qu'il a une adresse IP différente de ce que le noeud final local le pense; De la mémoire, ce sont leftid= et rightid=, mais vous allez devoir travailler cela pour vous-même.
C'est donc les bases. Si vous obtenez la topologie et les concepts fondamentaux, le reste ne fait que déboguer les détails. Bonne chance avec ça.
[1] Ce n'est pas tout à fait vrai. Les implémentations de Swan prennent en charge le cryptage IPsec opportuniste, mais cela nécessite que vous contrôlez votre DNS inverse aux deux extrémités, et je suppose que vous ne le faites pas. Encore une fois, lisez les pages de l'homme si vous voulez en savoir plus à ce sujet.