1

Я настраиваю VPN в одной из сетей наших клиентов. В связи с требованием об их окончании мы не можем получить трафик (кажется) с частного IP-адреса. Мне удалось настроить туннель с нашим клиентом, но у меня возникла проблема с настройкой NAT для работы по мере необходимости. В целях тестирования я смоделировал среду в AWS, используя 2 VPC, и наблюдал за трафиком, используя tcpdump или tshark, чтобы увидеть, что представляет собой адрес from ip. Вот копия установки с разными IP-адресами.

(Simulated Customer Side VPC - 172.16.0.0/16)
Customer Test Server - 172.16.0.20
AWS Hardware VPN - 1.1.1.1
|
|
|
(Internet)
|
|
|
(Our VPC - 10.10.10.0/16)
OpenSwan VPN server - 2.2.2.2 and 10.10.10.10
Internal Test Server - 10.10.10.20

Файл ipsec.conf для OpenSwan ....

conn Tunnel1
  authby=secret
  auto=start
  left=%defaultroute
  leftid=2.2.2.2
  right=1.1.1.1
  type=tunnel
  ikelifetime=8h
  keylife=1h
  phase2alg=aes128-sha1;modp1024
  ike=aes128-sha1;modp1024
  auth=esp
  keyingtries=%forever
  keyexchange=ike
  leftsubnet=10.10.10.0/16
  rightsubnet=172.16.0.0/16
  dpddelay=10
  dpdtimeout=30
  dpdaction=restart_by_peer

и файл секретов выглядит так ....

2.2.2.2 1.1.1.1: PSK "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Я также установил следующие значения в /etc/sysctl.conf

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0

Делая это, я могу заставить туннель подняться, и я могу общаться между тестовыми экземплярами, используя частные ip-адреса другого тестировщика (с обеих сторон). Это показывает (для ping и ssh), что связь происходит с частного IP-адреса другого тестового сервера. Например, пинг с 10.10.10.20 по 172.16.0.20 показывает (через tshark) пинг с 10.10.10.20.

Чтобы трафик выглядел так, как будто он поступает с внешнего IP-адреса сервера OpenSwan, я добавил запись ip-таблиц в экземпляр OpenSwan.

iptables -t nat -I POSTROUTING -s 10.10.10.0/16 -d 172.16.0.0/16 -o eth0 -j SNAT --to-source 2.2.2.2

Затем, когда я пинг с 10.10.10.20 до 172.16.0.20, пинг идет от 2.2.2.2. Это поведение, на которое я надеялся, однако, когда я пытаюсь выполнить ssh с 10.10.10.20 по 172.16.0.20, трафик туда не попадает. Tshark на клиентском тестовом сервере не показывает входящий ssh-трафик с 10.10.10.20 или 2.2.2.2, а tcpdump на сервере OpenSwan показывает, что трафик не получает NAT для 2.2.2.2 (он показывает пакеты только для 10.10. 10.20 -> 172.16.0.20:22).

Я пробовал много разных конфигураций (борющихся в течение нескольких дней) для установки left, leftsubnet, leftsourceip, leftnexthop, а также использования SNAT и MASQUERADE и других различных записей iptables, но мне не повезло, что трафик выглядел так, как нужно.

Что мне нужно для того, чтобы входящий трафик в сети клиентов выглядел так, как будто он исходит от внешнего IP-адреса? Любая помощь с благодарностью. Благодарю.

Если вам нужны дополнительные журналы tcpdump или tshark, я также могу предоставить их.

И FWIW, у меня действительно есть таблицы маршрутов AWS в VPC Customer Test, установленные так, что трафик 2.2.2.2 и 10.10.10.0/16 идет к шлюзу VPN, а таблицы маршрутов в Нашем VPC имеют весь трафик 172.16.0.0/16, идущий в ENI для экземпляра OpenSwan.

|источник

0