The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"linux ipsec lan to lan routing"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Маршрутизация, NAT / Linux)
Изначальное сообщение [ Отслеживать ]

"linux ipsec lan to lan routing"  +/
Сообщение от n0x (ok) on 01-Авг-12, 19:14 
Добрый вечер, коллеги!
Немного запутался с роутингом между двумя сетями с ipsec-туннелем между их шлюзами.
Имеется: centos6 x86, Openswan U2.6.32/K2.6.32-279.2.1.el6.i686

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:

config setup
        protostack=netkey
        oe=off

conn 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 eth0

iptables с политиками 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'а и подмены адресов, т. е. так, чтобы хосты сетей видели реальные адреса при общении друг с другом через туннель.

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "linux ipsec lan to lan routing"  +/
Сообщение от Loly on 02-Авг-12, 10:49 
> 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

...

Или всё же нет? Судя по этому Вы что то напутали.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "linux ipsec lan to lan routing"  +/
Сообщение от n0x (ok) on 02-Авг-12, 12:08 
>[оверквотинг удален]
>>   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 subnet

A 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 | Наверх | Cообщить модератору

3. "linux ipsec lan to lan routing"  +/
Сообщение от Loly on 02-Авг-12, 13:21 
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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "linux ipsec lan to lan routing"  +/
Сообщение от n0x (ok) on 02-Авг-12, 15:29 
> 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]

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "linux ipsec lan to lan routing"  +/
Сообщение от Loly on 02-Авг-12, 16:44 
Значит смотрите в сторону фаерволов iptables на серверах.
Используйте tcpdump.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "linux ipsec lan to lan routing"  +/
Сообщение от n0x (ok) on 02-Авг-12, 16:58 
> Значит смотрите в сторону фаерволов iptables на серверах.
> Используйте tcpdump.

Спасибо. iptables полностью открыты. nat'а нет. tcpdump на "пингуемом" шлюзе показывает icmp трафик на обоих интерфейсах (eth0 и eth1), что мне кажется немного странным.

Может ли источником проблемы являться то, что оба шлюза живут в виртуальных машинах kvm/libvirt, и их интерфейсы настроены через бриджи к внешнему и внутреннему интерфейсам хостовых машин? Поискал на эту тему информацию, но никаких ограничений ipsec/openswan в таких схемах не заметил...

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "linux ipsec lan to lan routing"  +/
Сообщение от Loly on 02-Авг-12, 23:09 
Допустим:
eth0 - 202.202.202.202
eth1 - 192.168.200.1

Если запустить "tcpdump -nni eth1" присутствуют ли в выводе пакеты с интерфейса eth0 (с публичной - адресованы 202.202.202.202 или адресатом есть 202.202.202.202)?

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "linux ipsec lan to lan routing"  +/
Сообщение от n0x (ok) on 03-Авг-12, 14:20 
> Допустим:
> 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.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "linux ipsec lan to lan routing"  +/
Сообщение от n0x (ok) on 06-Авг-12, 11:07 
Если интересно - резюме следующее - туннель исправно функционирует на "железе". Сети перестают видеть друг друга только в случае наличия/использования мостов (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.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "linux ipsec lan to lan routing"  +/
Сообщение от Loly on 06-Авг-12, 22:09 
А так пробовали на хост-машине:
# 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
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру