înregistrare Logare
Puncte:0
avatar Server

Dirijați traficul prin tunelul IPSec cu gazdă gateway

drapel pk
fiedl

Considerând strongswan wiki, aceasta pare a fi o problemă standard, dar nu o pot face să funcționeze corect.

Dispunerea rețelei

aspectul 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: [example@example.com] folosește autentificarea cheii pre-partajate
example-ipsec: remote: [example@example.com] 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[example@example.com]...<public-ip-of-the-remote-gateway>[example@example.com]
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 = „example@example.com”
  dreapta = vpn1.example.com
  rightid = "example@example.com"
  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
227
0 + 0
drapel cn
ecdsa
Care este selectorul de trafic local negociat pentru `gateway`? (adică postați ieșirea de stare a lui strongSwan, fie `ipsec statusall`, fie `swanctl -l`)
1
Răspunde
drapel pk
fiedl
Mulțumesc @ecdsa, am postat rezultatul `ipsec statusall`.
0
Răspunde
drapel pk
fiedl
Oh, cred că s-ar putea să te gândești la ceva! Dacă ultima linie a ieșirii `ipsec statusall` este, de asemenea, un selector de trafic, s-ar putea să nu se potrivească cu NAT-ul meu. Dar de fapt, nu știu de unde provine acest interval `10.10.102.235/32`, pentru că nu este din propria mea configurație. Poate, acesta este un selector impus de gateway-ul la distanță :/
0
Răspunde
drapel pk
fiedl
Asta este @ecdsa, am adăugat `iptables -t nat -A POSTROUTING -j SNAT --to-source 10.10.102.235; iptables -t nat -A POSTROUTING -m policy --dir out --pol ipsec -j ACCEPT` (adoptat de pe https://wiki.strongswan.org/issues/2355) și apoi funcționează! Vrei să scrii un răspuns corect?
0
Răspunde
drookie avatar
drapel za
drookie
Se pare că ai selectorul de trafic configurat greșit. Adăugați câteva configurații legate de aceasta.
0
Răspunde
drapel pk
fiedl
Mulțumesc, @drookie, am adăugat `/etc/ipsec.conf`.
0
Răspunde
Puncte:1
avatar Server
drapel cn
ecdsa

Deoarece conexiunea folosește o adresă IP virtuală (leftsourceip=%config, ceea ce are ca rezultat 10.10.102.235/32 ca selector de trafic local), trebuie să NAT traficul către acea adresă, nu pe cea fizică a gazdei prin care o primiți MASCARADĂ, pentru a se potrivi politicilor IPsec și a tunelului traficul (-Eu pentru a o introduce în partea de sus):

iptables -t nat -I POSTROUTING -j SNAT --to-source 10.10.102.235

Dacă IP-ul virtual nu este atribuit static (de ex.pe baza identității clientului) și s-ar putea schimba, puteți instala/șterge regula SNAT în mod dinamic într-un script updown personalizat (configurat prin stânga în sus în jos) la care este transmis IP-ul virtual $PLUTO_MY_SOURCEIP.

După cum ați spus inițial, aceasta va fi o configurație de tunel divizat (pe care selectorul de trafic de la distanță al 0.0.0.0/0 nu reflectă de fapt), puteți adăuga și de ex. -d 10.10.0.0/16 la regula SNAT pentru a procesa numai pachetele către acea subrețea, alt trafic nu va fi controlat și tunelizat (puteți păstra MASCARADĂ regula pentru acel trafic). Acest lucru ar putea fi, de asemenea, aplicat prin politica IPsec (rightsubnet=10.10.0.0/16), în care apoi intri $PLUTO_PEER_CLIENT în scriptul updown.

0 + 0
drapel pk
fiedl
Vă mulțumesc foarte mult pentru ajutor și pentru acest răspuns grozav, care arată nu numai ce trebuie să faceți, ci și de ce trebuie să faceți acest lucru!
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.