Considerând strongswan wiki, aceasta pare a fi o problemă standard, dar nu o pot face să funcționeze corect.
Dispunerea rețelei
Site-ul local (client și poarta de acces) este sub controlul meu, site-ul de la distanță (gateway la distanță și server la distanta) nu este. Tunelul IPSec este un tunel împărțit astfel încât numai cererile către 10.10.0.0/16 subrețeaua sunt trimise prin tunelul IPSec.
Poartă
mi-ar placea client pentru a comunica cu server la distanta, de exemplu. creeaza o ssh sau a cuiva conexiune.
Ceea ce am făcut deja
Am stabilit un tunel IPSec între poarta de acces si gateway la distanță.
Am activat redirecționarea ip pe poarta de acces:
sysctl net.ipv4.ip_forward=1
Am creat un NAT pe poarta de acces:
iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT
iptables -t nat -A POSTROUTING -j MASQUERADE
Pe client Am direcționat traficul prin poarta de acces:
ip route del default
IP route add default prin 192.168.144.4
# 192.168.144.4 este poarta de acces
Ce funcționează
- Tunelul IPSec este stabilit și stabil.
- Când v-ați autentificat în
poarta de acces, Eu pot ping cel gateway la distanță si server la distanta cu succes. pot de asemenea ping cel client. Si eu pot ping google.com.
- Când v-ați autentificat în
client, Eu pot ping google.com si eu pot ping cel poarta de acces. Cu tcpdump icmp pe poarta de acces Văd că ping google.com de la client trece prin poarta de acces.
Ce nu merge, încă
Nu pot ping cel server la distanta de la client prin IP-ul său.
client$ ping -c 1 10.10.12.7
PING 10.10.12.7 (10.10.12.7): 56 de octeți de date
--- 10.10.12.7 statistici ping ---
1 pachet transmis, 0 pachete primite, 100% pierdere de pachete
De la tcpdump pe poarta de acces, se pare ca ping este trimis, dar nu redirecționat prin tunel:
gateway$ tcpdump icmp
13:19:18.122999 IP 192.168.144.7 > 10.10.12.7: Solicitare ecou ICMP, id 15, seq 0, lungime 64
13:19:18.123038 IP gateway > 10.10.12.7: cerere de eco ICMP, id 15, seq 0, lungime 64
13:19:18.127534 IP ac5.nue3.m-online.net > gateway: ICMP net 10.10.12.7 inaccesibil, lungime 36
13:19:18.127556 IP ac5.nue3.m-online.net > 192.168.144.7: ICMP net 10.10.12.7 inaccesibil, lungime 36
La fel de ac5.nue3.m-online.net este furnizorul de servicii de internet al site-ului local, cred că pachetul nu este direcționat prin tunelul IPSec, ci prin conexiunea la internet a poarta de acces, care, desigur, nu poate ajunge la server la distanta. (Dacă fac tunelul IPSec un tunel plin mai degrabă decât un tunel divizat, obțin același rezultat.)
Orice ajutor sau perspectivă ar fi cu adevărat apreciat!
EDITAȚI | ×: ipsec statusall pe poarta de acces
gateway > ipsec statusall
Starea demonului IKE charon (strongSwan 5.8.2, Linux 5.4.0-88-generic, x86_64):
timp de funcționare: 7 minute, din 08 octombrie 08:18:24 2021
malloc: sbrk 3112960, mmap 0, folosit 1081456, gratuit 2031504
fire de lucru: 11 din 16 inactiv, 5/0/0/0 în lucru, coada de joburi: 0/0/0/0, programat: 4
plugin-uri încărcate: charon test-vectors ldap pkcs11 tpm aesni aes rc2 sha2 sha1 md5 mgf1 rdrand aleatoriu nonce x509 constrângeri de revocare pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey agent gmcpc5 afpcr sshkey gmcpc5 afpcr sshkey agent g-mpcrpcs gpcpc5 ntru drbg curl attr kernel-netlink resolve socket-default connmark farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth- generic xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock unity counters
Adrese IP de ascultare:
192.168.144.4
Conexiuni:
exemplu-ipsec: %any...vpn1.example.com IKEv2, dpddelay=300s
example-ipsec: local: [[email protected]] folosește autentificarea cheii pre-partajate
example-ipsec: remote: [[email protected]] folosește autentificarea cu cheie pre-partajată
exemplu-ipsec: copil: dinamic === 0.0.0.0/0 TUNNEL, dpdaction=clear
Asociații de securitate (1 în sus, 0 conexiuni):
exemplu-ipsec[1]: INSTALAT acum 7 minute, 192.168.144.4[[email protected]]...<public-ip-of-the-remote-gateway>[[email protected]]
exemplu-ipsec[1]: I: 9d7c74f670bbda86_i* c12b3b4a236b7018_r, reautentificare cheie pre-partajată în 2 ore
exemplu-ipsec[1]: propunere IKE: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
example-ipsec{1}: INSTALLED, TUNNEL, reqid 1, ESP în UDP SPI-uri: cf66ad72_i af3c9348_o
exemplu-ipsec{1}: AES_CBC_256/HMAC_SHA2_256_128, 442 bytes_i (4 pkts, acum 434s), 485 bytes_o (6 pkts, acum 433s), reintroducere în 38 de minute
exemplu-ipsec{1}: 10.10.102.235/32 === 0.0.0.0/0
Aceasta este rezultatul ipsec statusall pe poarta de acces după ce a trimis fără succes ping din client la server la distanta. The ping de la poarta de acces nu modifică „octeții” din ieșire. „octeții” din ieșire corespund unui a ping Am trimis de la poarta de acces la server la distanta.
EDITAȚI | ×: /etc/ipsec.conf pe poarta de acces:
# /etc/ipsec.conf
conn exemplu-ipsec
stânga = %defaultroute
leftsourceip = %config
leftid = „[email protected]”
dreapta = vpn1.example.com
rightid = "[email protected]"
rightsubnet = 0.0.0.0/0
firewall stânga = da
installpolicy = da
keyexchange = ikev2
tip = tunel
auto = start
leftauth = psk
rightauth = psk
dpdaction = clar
dpddelay = 300s
