Добрый вечер, коллеги!
Немного запутался с роутингом между двумя сетями с ipsec-туннелем между их шлюзами.
Имеется: centos6 x86, Openswan U2.6.32/K2.6.32-279.2.1.el6.i686gate1:
eth0: A.A.A.A (ext ip), 172.17.1.0/22
eth1: B.B.B.B (ext ip), 172.17.4.0/22# cat /etc/ipsec.conf:
config setup
protostack=netkey
oe=offconn net-to-net
type=tunnel
left=A.A.A.A
leftsubnet=172.17.1.0/22
leftsourceip=172.17.1.101
leftrsasigkey=0sAQ...
right=B.B.B.B
rightsubnet=172.17.4.0/22
rightsourceip=172.17.4.101
rightrsasigkey=0sAQ...
auto=start# netstat -rn
Destination Gateway Genmask Flags MSS Window irtt Iface
172.17.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
172.17.4.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
A.A.248.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0
0.0.0.0 A.A.A.GW 0.0.0.0 UG 0 0 0 eth0iptables с политиками ACCEPT;
конфигурация gate2 зеркальна gate1
при указанной конфигурации после того, как туннель поднимается, "видимость" хостов получается такой, что участники сети gate1 - 172.17.1.0/22 могут ходить на 172.17.4.101, но не дальше. при этом, gate1 также не видит по внутренним адресам никого, кроме gate2;
попробовал задействовать NETMAP:
iptables --table nat -A POSTROUTING -s 172.17.4.0/22 -j NETMAP --to 172.17.1.0/22
и на gate2 соответственно
iptables --table nat -A POSTROUTING -s 172.17.1.0/22 -j NETMAP --to 172.17.4.0/22
после чего, шлюзы смогли ходить в противоположные локалки, но при этом, с остальных хостов доступа в удаленную сеть нет, также как и в начале - могут ходить по внутреннему адресу только на противоположный шлюз.
смотрел схемы iproute2+iptables... не совсем понял, каким образом можно в данной ситуации реализовать связку сетей без NAT'а и подмены адресов, т. е. так, чтобы хосты сетей видели реальные адреса при общении друг с другом через туннель.
> gate1:
> eth0: A.A.A.A (ext ip), 172.17.1.0/22
> eth1: B.B.B.B (ext ip), 172.17.4.0/22Тут опечатка?
> # cat /etc/ipsec.conf:
> conn net-to-net
> type=tunnel
> left=A.A.A.A...
> right=B.B.B.B...
Или всё же нет? Судя по этому Вы что то напутали.
>[оверквотинг удален]
>> eth1: B.B.B.B (ext ip), 172.17.4.0/22
> Тут опечатка?
>> # cat /etc/ipsec.conf:
>> conn net-to-net
>> type=tunnel
>> left=A.A.A.A
> ...
>> right=B.B.B.B
> ...
> Или всё же нет? Судя по этому Вы что то напутали.В качестве left и right я прописал внешние статические адреса обоих шлюзов. Не исключаю, что напутал. Делал в соответствии со схемой, описанной в adv-config из openswan-doc:
-------------------------------------------------------------------------------------
Consider a pair of subnets, each with a security gateway, connected via the Internet:192.168.100.0/24 left subnet
|
192.168.100.1
North Gateway
101.101.101.101 left
|
101.101.101.1 left next hop
[Internet]
202.202.202.1 right next hop
|
202.202.202.202 right
South gateway
192.168.200.1
|
192.168.200.0/24 right subnetA tunnel specification such as:
conn northnet-southnet
left=101.101.101.101
leftnexthop=101.101.101.1
leftsubnet=192.168.100.0/24
leftfirewall=yes
right=202.202.202.202
rightnexthop=202.202.202.1
rightsubnet=192.168.200.0/24
rightfirewall=yes
-------------------------------------------------------------------------------------
1. # /etc/sysct.conf
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.icmp_ignore_bogus_error_responses = 12. ipsec verify
3. cat /proc/sys/net/ipv4/ip_forward
> 1. # /etc/sysct.conf
> net.ipv4.ip_forward = 1
> net.ipv4.conf.default.rp_filter = 0
> net.ipv4.conf.default.accept_source_route = 0
> net.ipv4.conf.all.send_redirects = 0
> net.ipv4.conf.default.send_redirects = 0
> net.ipv4.icmp_ignore_bogus_error_responses = 1
> 2. ipsec verify
> 3. cat /proc/sys/net/ipv4/ip_forwardвсе перечисленные флаги в sysctl.conf есть.
# 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-279.2.1.el6.i686 (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]
Testing against enforced SElinux mode [OK]
Checking that pluto is running [OK]
Pluto listening for IKE on udp 500 [OK]
Pluto listening for NAT-T on udp 4500 [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking NAT and MASQUERADEing [OK]
Checking for 'ip' command [OK]
Checking /bin/sh is not /bin/dash [OK]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]
Значит смотрите в сторону фаерволов iptables на серверах.
Используйте tcpdump.
> Значит смотрите в сторону фаерволов iptables на серверах.
> Используйте tcpdump.Спасибо. iptables полностью открыты. nat'а нет. tcpdump на "пингуемом" шлюзе показывает icmp трафик на обоих интерфейсах (eth0 и eth1), что мне кажется немного странным.
Может ли источником проблемы являться то, что оба шлюза живут в виртуальных машинах kvm/libvirt, и их интерфейсы настроены через бриджи к внешнему и внутреннему интерфейсам хостовых машин? Поискал на эту тему информацию, но никаких ограничений ipsec/openswan в таких схемах не заметил...
Допустим:
eth0 - 202.202.202.202
eth1 - 192.168.200.1Если запустить "tcpdump -nni eth1" присутствуют ли в выводе пакеты с интерфейса eth0 (с публичной - адресованы 202.202.202.202 или адресатом есть 202.202.202.202)?
> Допустим:
> eth0 - 202.202.202.202
> eth1 - 192.168.200.1
> Если запустить "tcpdump -nni eth1" присутствуют ли в выводе пакеты с интерфейса
> eth0 (с публичной - адресованы 202.202.202.202 или адресатом есть 202.202.202.202)?нет. на внутреннем интерфейсе пингуемого гейтвея, при пингах внутрь сети через туннель с другого гейтвея (на любой хост), ничего нет.
но tcpdump интерфейса eth0 показывает следующее:
14:14:30.011704 IP A.A.A.A > B.B.B.B: ESP(spi=0xdeaa29e6,seq=0x38), length 132
14:14:30.011725 IP A.A.A.A > 172.17.4.10: ICMP echo request, id 59142, seq 15, length 64
14:14:30.011738 IP B.B.B.B > A.A.A.A: ICMP host 172.17.4.10 unreachable - admin prohibited, length 92фаерволы везде пустые, с политиками ACCEPT.
Если интересно - резюме следующее - туннель исправно функционирует на "железе". Сети перестают видеть друг друга только в случае наличия/использования мостов (brX);>[оверквотинг удален]
>> eth0 (с публичной - адресованы 202.202.202.202 или адресатом есть 202.202.202.202)?
> нет. на внутреннем интерфейсе пингуемого гейтвея, при пингах внутрь сети через туннель
> с другого гейтвея (на любой хост), ничего нет.
> но tcpdump интерфейса eth0 показывает следующее:
> 14:14:30.011704 IP A.A.A.A > B.B.B.B: ESP(spi=0xdeaa29e6,seq=0x38), length 132
> 14:14:30.011725 IP A.A.A.A > 172.17.4.10: ICMP echo request, id 59142, seq 15,
> length 64
> 14:14:30.011738 IP B.B.B.B > A.A.A.A: ICMP host 172.17.4.10 unreachable - admin prohibited,
> length 92
> фаерволы везде пустые, с политиками ACCEPT.
А так пробовали на хост-машине:
# cat >> /etc/sysctl.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
EOF
# sysctl -p /etc/sysctl.conf