Tunnel IPsec Installé, mais la circulation ou le ping est impossible

J'ai déjà cherché des heures à ce sujet et de nombreux autres sites, et bien que les gens avaient des problèmes similaires, je n'ai trouvé personne qui pourrait résoudre mon problème.

J'essaie de mettre en place du tunnel IPsec de votre ordinateur à la machine virtuelle sur le serveur en utilisant strongswan (by swanctl.conf). J'ai précédemment établi la connexion IPsec, Mais d'un autre appareil. J'utilise la même configuration (swanctl.conf), Mais quelque chose d'autre ne me va pas. Ma voiture (10.3.72.29) Obtient une adresse IP virtuelle (172.13.14.2) et établit une connexion au périphérique serveur (10.3.218.62) Avec votre propre adresse IP virtuelle (192.168.122.2)

Ma configuration actuelle:

Mon ordinateur (initiateur) swanctl.conf:

connections {
ch_vti0 {
send_cert = always
encap = yes
vips = 0.0.0.0
remote_addrs = 10.3.218.62
local {
round = 1
id = 10.3.72.29
auth = psk
certs =
}
remote {
auth = psk
id = 10.3.218.62
certs =
}
children {
ch_vti0 {
mark_in = 42
mark_out = 42
remote_ts = 192.168.122.2/24
local_ts = dynamic
inactivity = 300s
mode = tunnel
esp_proposals = 3des-sha1-modp2048
updown = /usr/local/etc/swanctl/updown.sh 0
}
}
version = 1
proposals = des-md5-modp768, des-md5-modp1024, des-md5-modp1536
} }
secrets {
eap-xauth {
eap_id = test1
id = test1
secret = password
}
xauth-local {
id = test1
secret = password
}
ike-sec {
id = %any
secret = test
}
ike-local {
id = 10.3.72.29
secret = test
}
}

Machine virtuelle du serveur swanctl.conf:

connections {
ch_vti0 {
send_cert = always
encap = yes
pools = pools_users
#aggressive = yes
local {
round = 1
id = 10.3.218.62
auth = psk
certs =
}
remote {
auth = psk
id = %any
certs =
}
children {
ch_vti0 {
local_ts = 192.168.122.2/24
inactivity = 120s
mode = tunnel
esp_proposals = 3des-sha1-modp2048
updown = /usr/local/libexec/ipsec/_updown iptables
}
}
version = 0
proposals = des-md5-modp768, des-md5-modp1024, des-md5-modp1536
} }
pools {
pools_users {
addrs = 172.13.14.2/24
}
}
secrets {
eap-xauth {
eap_id = test1
id = test1
secret = password
}
xauth-local {
id = test1
secret = password
}
ike-sec {
id = %any
secret = test
}
ike-local {
id = 10.3.218.62
secret = test
}
}

Si quelqu'un est intéressé, scénario updown.sh Crée une interface vti0 et roues

Résultat ipsec statusall Sur mon PC:

Listening IP addresses:
10.3.72.29
fdc8:c2cb:4586:cc11::8f00:5a9
172.13.14.2
Connections:
ch_vti0: %any...10.3.218.62 IKEv1
ch_vti0: local: [10.3.72.29] uses pre-shared key authentication
ch_vti0: remote: [10.3.218.62] uses pre-shared key authentication
ch_vti0: child: dynamic === 192.168.122.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
ch_vti0[1]: ESTABLISHED 13 minutes ago, 10.3.72.29[10.3.72.29]...10.3.218.62[10.3.218.62]
ch_vti0[1]: IKEv1 SPIs: 7fa996a60f87e923_i* 4faa8dbdd74a5927_r, rekeying in 3 hours
ch_vti0[1]: IKE proposal: DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_768
ch_vti0{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c393a4bb_i c392a387_o
ch_vti0{1}: 3DES_CBC/HMAC_SHA1_96/MODP_2048, 65772 bytes_i (783 pkts, 0s ago), 0 bytes_o, rekeying in 42 minutes
ch_vti0{1}: 172.13.14.2/32 === 192.168.122.0/24

Dispositif serveur:

Listening IP addresses:
192.168.122.2
10.3.218.62
fdc8:c2cb:4586:cc12::e49c:faf8
Connections:
ch_vti0: %any...%any IKEv1/2
ch_vti0: local: [10.3.218.62] uses pre-shared key authentication
ch_vti0: remote: [%any] uses pre-shared key authentication
ch_vti0: child: 192.168.122.0/24 === dynamic TUNNEL
Security Associations (1 up, 0 connecting):
ch_vti0[1]: ESTABLISHED 14 minutes ago, 10.3.218.62[10.3.218.62]...10.3.72.29[10.3.72.29]
ch_vti0[1]: IKEv1 SPIs: 7fa996a60f87e923_i 4faa8dbdd74a5927_r*, rekeying in 3 hours
ch_vti0[1]: IKE proposal: DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_768
ch_vti0{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c392a387_i c393a4bb_o
ch_vti0{1}: 3DES_CBC/HMAC_SHA1_96/MODP_2048, 0 bytes_i, 68880 bytes_o (820 pkts, 0s ago), rekeying in 44 minutes
ch_vti0{1}: 192.168.122.0/24 === 172.13.14.2/32

Itinéraires sur mon ordinateur:

root@malz:/usr/local/etc/swanctl# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.3.127.1 0.0.0.0 UG 100 0 0 enp2s0
10.3.0.0 0.0.0.0 255.255.0.0 U 100 0 0 enp2s0
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 vti0

Itinéraires sur le périphérique serveur:

root@server-automation-2:/etc/swanctl# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.3.127.1 0.0.0.0 UG 0 0 0 ens4
10.3.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ens4
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 ens3

J'ai permis aux ports qui utilisent IPsec (500,4500,4500 / udp, 500 / udp), J'ai essayé d'éteindre les pare-feu sur les deux, effacé iptables Et a tout permis:

iptables -F
iptables -I INPUT -j ACCEPT
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

J'ai aussi vérifié les paramètres sysctl Pour laisser tomber les paquets (surtout ceux relatifs aux demandes icmp)

Si j'essaie d'intercepter des colis avec tcpdump, Je vois que je les reçois du périphérique serveur (ping Paquets ICMP), Mais mon ordinateur ne répond pas

Si j'essaie d'envoyer des paquets, le périphérique serveur ne les intercepte pas et le nombre de packs d'erreur TX Interface IPsec Mon PC augmente. De ifconfig:

vti0: flags=209<up,pointopoint,running,noarp>  mtu 1480
inet 172.13.14.2 netmask 255.255.255.255 destination 172.13.14.2
inet6 fe80::5efe:a03:481d prefixlen 64 scopeid 0x20<link/>
tunnel txqueuelen 1000 (IPIP Tunnel)
RX packets 1063 bytes 89292 (89.2 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 57 dropped 0 overruns 0 carrier 57 collisions 0

En conclusion, j'ai défini la connexion ipsec Entre les deux machines, mais je ne peux pas comprendre pourquoi l'un d'entre eux ne peut pas transférer des emballages et ne répond pas aux pinges des autres. Je suis tout à fait sûr que la raison de tout cela n'est pas dans la configuration. ipsec, Parce que j'ai déjà mentionné plus tôt que je l'ai déjà testé, et cela fonctionne avec le même fichier conf (Sauf pour le changement IPS).

Si quelqu'un peut me donner même un indice, je serais très reconnaissant.
</up,pointopoint,running,noarp>
Invité:

Babette

Confirmation de:

Étapes de persécution Dépannage (vers le haut):

Lancer tcpdump. Vous devez voir des paquets propres et cryptés. (ESP).

Vérifiez la connexion IP entre les extrémités du tunnel ipsec.

Vérifiez le routage. Défaut strongswan Définit des itinéraires supplémentaires sur une table de routage séparée. Courir

ip -4 r ls table 220

. Explorez la sortie. Pour vérifier les itinéraires actuels, utilisez

ip route get <dst>

équipe. Ne pas utiliser

route -n

équipe - Renvoie une représentation incomplète.

Vérifier la sortie

ip -s -s xfrm state list

et

ip -s -s -d xfrm policy list

. Il montre le système SADB (Base de données d'association de sécurité) et base de données politicienne. Dans votre interface vti Il y a des erreurs d'opérateur de service. Erreur de l'opérateur de communication sur l'interface vti Moyens:

Politiques appropriées ipsec pas trouvé. Vérifier

ip x p get ...

équipe.

L'itinéraire approprié n'a pas été trouvé. Vérifier

ip route get ...

équipe.

Qui convient SA N'ont pas trouvé. Vérifier

ip x s ls

équipe.


Vérifiez le pare-feu. Équipe iptables Fonctionne par défaut avec

filter

table, Mais il y a d'autres tables (raw, nat, mangle). Meilleur usage

iptables-save -c

La commande d'afficher un ensemble complet de règles. Après avoir changé les règles nat Nettoie la table conntrack de

conntrack -F

équipe. Circulation ipsec Deux fois passe la chaîne du pare-feu: on passe comme crypté, l'autre - aussi propre. Donc, explorer les règles. Vous pouvez également insérer

NFLOG

Règles ciblées pour la capture de trafic

tcpdump -ni nflog...

équipe.
</dst>

Pour répondre aux questions, connectez-vous ou registre