До сих пор весьма распространено подключение, когда провайдер ставит свой роутер и выдает клиенту приватные адреса. Чтобы иметь возможность построить IPsec туннель через подобное подключение и был придуман NAT Traversal (NAT-T). В свое время я потратил много времени на осознание того, что нужно указывать в качестве локального и удаленного хостов на концах туннеля в OpenSWAN. Кому интересна эта тема, добро пожаловать под кат.
Все тесты я проводил на стенде, собрав вот такую конфигурацию:
В данном случае задача состоит в том, чтоб построить IPsec туннель между FW1 и FW2, при этом FW1 имеет на WAN интерфейсе приватный адрес — 172.30.0.254 и находится за роутером провайдера.
Сразу оговорюсь, что есть несколько условий для этого и все зависит от возможности настройки роутера провайдера:
Вариант1:
| ACTION | SOURCE | DESTINATION | PROTOCOL | PORT | FORWARD |
|---|---|---|---|---|---|
| DNAT | 2.2.2.2 | 5.5.5.5 | 50 | 172.30.0.254 | |
| DNAT | 2.2.2.2 | 5.5.5.5 | 51 | 172.30.0.254 | |
| DNAT | 2.2.2.2 | 5.5.5.5 | udp | 500 | 172.30.0.254:500 |
То есть все пакеты с исходящим адресом 2.2.2.2 и с адресом назначения 5.5.5.5 по протоколу UDP приходящие на порт 500 перенаправлять на 172.30.0.254(это наш FW1) также на порт 500. И тоже самое делать со всеми пакетами по протоколам 50 и 51(ESP и AH соответственно).
Это не NAT-T, на самом деле так работает обычный IPsec. Проблема в том, что этот метод может «заработать», а может и «не заработать», и никто не может дать гарантий(это во многом зависит от провайдера), поэтому советуют использовать второй вариант.
Вариант2: NAT Traversal (NAT-T)
| ACTION | SOURCE | DESTINATION | PROTOCOL | PORT | FORWARD |
|---|---|---|---|---|---|
| DNAT | 2.2.2.2 | 5.5.5.5 | udp | 500 | 172.30.0.254:500 |
| DNAT | 2.2.2.2 | 5.5.5.5 | udp | 4500 | 172.30.0.254:4500 |
Как видно, тут используется только UDP протокол, который разрешен по умолчанию у большинства провайдеров.
Как устанавливать и настраивать OpenSWAN на хабре писали не раз, например вот здесь, поэтому приведу просто примеры конфигураций.
Для FW1:
/etc/ipsec.conf
nat_traversal=yes protostack=netkey conn connection_to_fw2 type=tunnel auto=start authby=secret pfs=yes ike=aes256-sha1;modp2048 phase2=esp phase2alg=aes256-sha1;modp2048 left=172.30.0.254 leftnexthop=172.30.0.1 leftsourceip=192.168.0.1 leftsubnet=192.168.0.0/24 leftid=@left right=2.2.2.1 rightsubnets=10.0.0.0/24 rightid=@right
Для FW2:
/etc/ipsec.conf
nat_traversal=yes protostack=netkey conn connection_to_fw1 type=tunnel auto=start authby=secret pfs=yes ike=aes256-sha1;modp2048 phase2=esp phase2alg=aes256-sha1;modp2048 right=2.2.2.1 rightid=@right rightsourceip=10.0.0.1 rightsubnet=10.0.0.0/24 left=5.5.5.1 leftid=@left leftsubnet=192.168.0.0/24 leftnexthop=172.30.0.1
с обоих сторон должна быть одинаковая запись ключа:
@left @right : PSK "123456789"
Ну и версия Openswan:
ipsec —version
Linux Openswan U2.6.37/K3.2.0-83-generic-pae (netkey)
перезапускаем OpenSWAN и проверяем:
/etc/init.d/ipsec restart
root@fw2:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0c:29:cd:12:76
inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
root@fw2:~# ping -I eth0 192.168.0.1
PING 192.168.0.1 (192.168.0.1) from 10.0.0.1 eth0: 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=0.577 ms
ссылка на оригинал статьи http://habrahabr.ru/post/259479/
Добавить комментарий