Маршрутизация трафика через туннель IPSec с хостом-шлюзом

Учитывая вики strongswan , это выглядит быть стандартной проблемой, но я не могу заставить ее работать правильно.

Схема сети

network layout

Локальный узел(clientиgateway)находится под моим контролем, удаленный узел(remote gatewayиremote server)— нет. Туннель IPSec представляет собой разделенный туннель , так что через туннель IPSec отправляются только запросы к подсети 10.10.0.0/16.

Цель

Я хотел бы, чтобы clientобщался с remote server, например. создайте соединение sshили smb.

То, что я уже сделал

  • Я установил туннель IPSec между gatewayи remote gateway.

  • Я включил переадресацию IP-адресов наgateway:

    sysctl net.ipv4.ip_forward=1
    
  • Я создал NAT наgateway:

    iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT
    iptables -t nat -A POSTROUTING -j MASQUERADE
    
  • На clientЯ направил трафик черезgateway:

    ip route del default
    ip route add default via 192.168.144.4
                           # 192.168.144.4 is the gateway
    

Что работает

  • Туннель IPSec установлен и стабилен.
  • При входе-в gatewayя успешно могу pingremote gatewayи remote server. Я также могу pingclient. И я могу ping google.com.
  • При входе-в clientя могу ping google.comи pingмогу gateway. С tcpdump icmpна gatewayя вижу, что ping google.comиз clientпроходит через gateway.

Что не работает, пока

Не могу pingполучить remote serverот clientпо его IP.

client$ ping -c 1 10.10.12.7
PING 10.10.12.7 (10.10.12.7): 56 data bytes

--- 10.10.12.7 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

Из tcpdumpна gatewayпохоже, что pingотправляется, но не пересылается через туннель:

gateway$ tcpdump icmp
13:19:18.122999 IP 192.168.144.7 > 10.10.12.7: ICMP echo request, id 15, seq 0, length 64
13:19:18.123038 IP gateway > 10.10.12.7: ICMP echo request, id 15, seq 0, length 64
13:19:18.127534 IP ac5.nue3.m-online.net > gateway: ICMP net 10.10.12.7 unreachable, length 36
13:19:18.127556 IP ac5.nue3.m-online.net > 192.168.144.7: ICMP net 10.10.12.7 unreachable, length 36

Поскольку ac5.nue3.m-online.netявляется интернет-провайдером -локального сайта Я думаю, что пакет маршрутизируется не через туннель IPSec, а через интернет-соединение gateway, которое, конечно, не может достичь remote server. (Если я сделаю туннель IPSec полным, а не разделенным туннелем,Я получаю тот же результат.)

Будем очень признательны за любую помощь или понимание!

РЕДАКТИРОВАТЬ:ipsec statusallнаgateway

gateway > ipsec statusall
Status of IKE charon daemon (strongSwan 5.8.2, Linux 5.4.0-88-generic, x86_64):
  uptime: 7 minutes, since Oct 08 08:18:24 2021
  malloc: sbrk 3112960, mmap 0, used 1081456, free 2031504
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
  loaded plugins: charon test-vectors ldap pkcs11 tpm aesni aes rc2 sha2 sha1 md5 mgf1 rdrand random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp curve25519 agent chapoly xcbc cmac hmac ctr ccm gcm 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
Listening IP addresses:
  192.168.144.4
Connections:
example-ipsec:  %any...vpn1.example.com  IKEv2, dpddelay=300s
example-ipsec:   local:  [example@example.com] uses pre-shared key authentication
example-ipsec:   remote: [example@example.com] uses pre-shared key authentication
example-ipsec:   child:  dynamic === 0.0.0.0/0 TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
example-ipsec[1]: ESTABLISHED 7 minutes ago, 192.168.144.4[example@example.com]...<public-ip-of-the-remote-gateway>[example@example.com]
example-ipsec[1]: I: 9d7c74f670bbda86_i* c12b3b4a236b7018_r, pre-shared key reauthentication in 2 hours
example-ipsec[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
example-ipsec{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cf66ad72_i af3c9348_o
example-ipsec{1}:  AES_CBC_256/HMAC_SHA2_256_128, 442 bytes_i (4 pkts, 434s ago), 485 bytes_o (6 pkts, 433s ago), rekeying in 38 minutes
example-ipsec{1}:   10.10.102.235/32 === 0.0.0.0/0

Это вывод ipsec statusallна gatewayпосле неудачной отправки pingс clientна remote server. pingиз gatewayне изменяет "байты" в выводе. «Байты» в выводе соответствуют ping, которые я отправил с gatewayна remote server.

РЕДАКТИРОВАТЬ:/etc/ipsec.confнаgateway:

# /etc/ipsec.conf

conn example-ipsec
  left = %defaultroute
  leftsourceip = %config
  leftid = "example@example.com"
  right = vpn1.example.com
  rightid = "example@example.com"
  rightsubnet = 0.0.0.0/0
  leftfirewall = yes
  installpolicy = yes
  keyexchange = ikev2
  type = tunnel
  auto = start
  leftauth = psk
  rightauth = psk
  dpdaction = clear
  dpddelay = 300s
0
задан 7 October 2021 в 13:46
1 ответ

Поскольку соединение использует виртуальный IP-адрес(leftsourceip=%config, что приводит к 10.10.102.235/32как селектор локального трафика ), вы должны направить трафик NAT на этот адрес, а не на физический адрес хоста, который вы получаете через MASQUERADE, чтобы соответствовать политикам IPsec и туннелировать трафик (-I, чтобы вставить его вверху ):

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

. ] Если виртуальный IP-адрес не назначен статически (, например на основе идентификатора клиента)и может измениться, вы можете динамически установить/удалить правило SNAT в пользовательском скрипте updown (, настроенном через leftupdown), которому передается виртуальный IP-адрес в $PLUTO_MY_SOURCEIP.

Поскольку вы изначально сказали, что это должна быть раздельная-установка туннелирования (, которую селектор удаленного трафика 0.0.0.0/0на самом деле не отражает), вы также можете добавить, например. -d 10.10.0.0/16к правилу SNAT, чтобы обрабатывать пакеты только для этой подсети, другой трафик не будет передаваться и туннелироваться (вы можете сохранить правило MASQUERADEдля этого трафика). Это также может быть реализовано с помощью политики IPsec (rightsubnet=10.10.0.0/16), которую вы затем получите в $PLUTO_PEER_CLIENTв сценарии updown.

1
ответ дан 11 October 2021 в 07:49

Теги

Похожие вопросы