Я успешно установил соединение IPsec, но оно работает только частично. Одна сторона не отправляет пакеты через туннель. Кажется, что топология сети здесь непонятна.
Любая помощь высоко ценится! Спасибо!!
Это схема сети:
"office"(192.168.73.0/24) == "vpn"(192.168.73.1) == "router"(6.6.6.6) <====> "server"(7.7.7.7) == "VM_LAN"(192.168.133.0/24)
6.6.6.6 и 7.7.7.7 являются символическими общедоступными IP-адресами, т.е. «маршрутизатор» и «сервер» напрямую подключены к Интернету.
«vpn» и «server» работают под управлением CentOS 6. «router» - это кабельный модем, выполняющий NAT и переадресацию портов.
Соединение установлено.
На "vpn" я могу пинговать внутренний IP "сервера":
[root@vpn]# ping 192.168.133.1
PING 192.168.133.1 (192.168.133.1) 56(84) bytes of data.
64 bytes from 192.168.133.1: icmp_seq=1 ttl=64 time=74.8 ms
На "сервере" я не могу пинговать "vpn", нет даже пакета, отправленного.
Ниже приведен дамп с «сервера», показывающий входящий пакет ping. Я использую ту же команду, чтобы проверить, отправляются ли пакеты с «сервера» на «vpn», при отправке ping от «server», но пакеты не появляются.
[root@server]# tcpdump port 500 or port 4500
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:40:21.793577 IP 6.6.6.6.ipsec-nat-t > 7.7.7.7.ipsec-nat-t: UDP-encap: ESP(spi=0x712a1d37,seq=0x2), length 132
14:40:21.793650 IP 7.7.7.7.ipsec-nat-t > 6.6.6.6.ipsec-nat-t: UDP-encap: ESP(spi=0x840e6b76,seq=0x2), length 132
проверка ipsec выглядит нормально:
[root@server]# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path [OK]
Linux Openswan U2.6.32/K2.6.32-358.2.1.el6.x86_64 (netkey)
Checking for IPsec support in kernel [OK]
SAref kernel support [N/A]
NETKEY: Testing for disabled ICMP send_redirects [OK]
NETKEY detected, testing for disabled ICMP accept_redirects [OK]
Checking that pluto is running [OK]
Pluto listening for IKE on udp 500 [OK]
Pluto listening for NAT-T on udp 4500 [OK]
Checking for 'ip' command [OK]
Checking /bin/sh is not /bin/dash [OK]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]
iptables отключен:
[root@server]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@server]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
7.7.7.7 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
0.0.0.0 7.7.7.1 0.0.0.0 UG 0 0 0 eth0
Мой ipsec.conf:
config setup
# Debug-logging controls: "none" for (almost) none, "all" for lots.
# klipsdebug=none
# plutodebug="control parsing"
plutodebug="all"
# For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
protostack=netkey
nat_traversal=yes
virtual_private="%v4:192.168.73.0/24"
oe=off
# Enable this if you see "failed to find any available worker"
# nhelpers=0
conn aaa-office
authby=secret
left=7.7.7.7
leftsubnet=192.168.133.0/24
right=6.6.6.6
rightsubnet=192.168.73.0/24
rightid=192.168.73.8
auto=add
Я отвечу сам и надеюсь, что эту информацию можно будет использовать для других с той же проблемой.
Основная причина заключалась в том, что пакеты с «сервера» не проходили через туннель. С помощью ip xfrm policy
Я мог видеть, что политика маршрутизации через туннель такова, что пакеты должны исходить из 192.168.133.0/24.
Пинг от "server" к "vpn" привел к этим пакетам:
17:29:16.549349 IP 7.7.7.7 > 192.168.73.8: ICMP echo request, id 43864, seq 1, length 64
Таким образом, при проверке связи исходный IP-адрес, естественно, был публичным IP-адресом сервера. Это не относилось к машине «vpn», поскольку эта машина уже находилась в подсети. Проблема решена, когда я добавил в конфигурационный файл «server» следующую инструкцию:
leftsourceip=192.168.133.1
Теперь все работает, как ожидалось, и я могу подключиться к подсети за «vpn» с «сервера».
Я не знаю openswan, но: в туннеле VPN убедитесь, что у вас есть VPN на основе маршрута или на основе политики. т.е. если он основан на маршруте, должен быть маршрут, который говорит: «берет этот туннельный интерфейс, чтобы добраться до сети 192.168.73.1». Если это основано на политике, то должна быть политика, которая гласит: «исходный трафик из x отправляется в пункт назначения y = туннель через VPN-туннель».
Извините ... удалено много ... плохое понимание чтения ... Я вижу информацию о LAN-интерфейсе / IP-адресе вашего сервера и понимаю, что вы пытаетесь выполнить эхо-запрос с исходного IP-адреса 192.168.133.1.
Я бы все равно проверил, что политика или маршрут в openswan настроен на стороне сервера для источника трафика 192.168.133.0/24, предназначенного для 192.168.73.0/24, и убедитесь, что он использует туннель. Похоже, этот трафик не использует туннель, а вместо этого выполняет что-то вроде:
192.168.133.1 - - попытка пинговать 192.168.73.1 (что не удалось)