LINUX.ORG.RU
решено ФорумAdmin

не удается настроить IPSec на Debian/OpenSWAN


0

1

С администрированием linux-систем сталкивался мало, поэтому разбираюсь со скрипом. Google спрашивал, но ответа не добился. К сути. Схема подключения на клиенте следующая: HomePC<-->Router(NAT)<-->Inet<-->VPN_Server

Хочу настроить на Debian l2tp OpenSWAN ipsec. Действовал так:

0)

root@dtcoalex:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:50:56:81:45:c5
          inet addr:91.245.35.34  Bcast:91.245.35.63  Mask:255.255.255.224
          inet6 addr: fe80::250:56ff:fe81:45c5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8235 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7659 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:745378 (727.9 KiB)  TX bytes:2222999 (2.1 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

1) apt-get install openswan xl2tpd

2)

 root@dtcoalex:~# nano /etc/ipsec.conf

version    2.0    # conforms to second version of ipsec.conf specification
config setup
    protostack=netkey
    nat_traversal=yes  virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!10.0.7.0/26
    interfaces=%defaultroute
#    plutodebug="all"
    plutostderrlog=/var/log/pluto.log
    oe=off
conn L2TP-PSK-NAT
    authby=secret
    type=transport
    pfs=no
    rekey=no
    keyingtries=3
    left=%defaultroute
    leftprotoport=17/1701
    right=%any
    rightsubnet=vhost:%no,%priv
    rightprotoport=17/%any
    auto=add
3)
 nano /etc/ipsec.secrets
91.245.35.34 %any: PSK "mysecret" #external IP
4)
 nano  /etc/xl2tpd/xl2tpd.conf

ipsec saref = yes
debug tunnel = yes
debug avp = yes
debug network = yes
debug packet = yes
debug state = yes
;force userspace =yes

[lns default]
ip range = 10.0.7.40-10.0.7.50
local ip = 10.0.7.2
assign ip = yes
require chap = yes
refuse pap = yes
require authentication = yes
name = l2tpVPN
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
5) nano etc/xl2tpd/l2tp-secrets
*       *       *   # let all , because we use auth with ppp

6)

 nano /etc/ppp/options.xl2tpd 
ipcp-accept-local
ipcp-accept-remote
require-mschap-v2
auth
noccp
idle 1800
mtu 1200
mru 1200
nodefaultroute
debug
lock
proxyarp
connect-delay 5000
logfile /var/log/xl2tpd.log
7)
nano  /etc/ppp/chap-secrets
user   l2tpd   pass    *
8) /etc/init.d/ipsec restart && /etc/init.d/xl2tpd restart

9)

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.37/K3.2.0-4-686-pae (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing XFRM related proc values                      [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/send_redirects
  or NETKEY will cause the sending of bogus ICMP redirects!

        [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
  or NETKEY will accept bogus ICMP 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                               [WARNING]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

Однако получаю ошибку при попытке соединиться с клиента на Windows 7. В логе /var/log/pluto.log

packet from 87.117.185.107:641: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
packet from 87.117.185.107:641: received Vendor ID payload [RFC 3947] method set to=109
packet from 87.117.185.107:641: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109
packet from 87.117.185.107:641: ignoring Vendor ID payload [FRAGMENTATION]
packet from 87.117.185.107:641: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
packet from 87.117.185.107:641: ignoring Vendor ID payload [Vid-Initial-Contact]
packet from 87.117.185.107:641: ignoring Vendor ID payload [IKE CGA version 1]
"L2TP-PSK-NAT"[2] 87.117.185.107 #9: responding to Main Mode from unknown peer 87.117.185.107
"L2TP-PSK-NAT"[2] 87.117.185.107 #9: OAKLEY_GROUP 20 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
"L2TP-PSK-NAT"[2] 87.117.185.107 #9: OAKLEY_GROUP 19 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
"L2TP-PSK-NAT"[2] 87.117.185.107 #9: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
"L2TP-PSK-NAT"[2] 87.117.185.107 #9: STATE_MAIN_R1: sent MR1, expecting MI2
packet from 87.117.185.107:641: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
packet from 87.117.185.107:641: received Vendor ID payload [RFC 3947] method set to=109
packet from 87.117.185.107:641: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109
packet from 87.117.185.107:641: ignoring Vendor ID payload [FRAGMENTATION]
packet from 87.117.185.107:641: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
packet from 87.117.185.107:641: ignoring Vendor ID payload [Vid-Initial-Contact]
packet from 87.117.185.107:641: ignoring Vendor ID payload [IKE CGA version 1]
"L2TP-PSK-NAT"[2] 87.117.185.107 #10: responding to Main Mode from unknown peer 87.117.185.107
"L2TP-PSK-NAT"[2] 87.117.185.107 #10: OAKLEY_GROUP 20 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
"L2TP-PSK-NAT"[2] 87.117.185.107 #10: OAKLEY_GROUP 19 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
"L2TP-PSK-NAT"[2] 87.117.185.107 #10: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
"L2TP-PSK-NAT"[2] 87.117.185.107 #10: STATE_MAIN_R1: sent MR1, expecting MI2
"L2TP-PSK-NAT"[2] 87.117.185.107 #3: max number of retransmissions (2) reached STATE_MAIN_R1
"L2TP-PSK-NAT"[2] 87.117.185.107 #4: max number of retransmissions (2) reached STATE_MAIN_R1
"L2TP-PSK-NAT"[2] 87.117.185.107 #5: max number of retransmissions (2) reached STATE_MAIN_R1
"L2TP-PSK-NAT"[2] 87.117.185.107 #6: max number of retransmissions (2) reached STATE_MAIN_R1
"L2TP-PSK-NAT"[2] 87.117.185.107 #7: max number of retransmissions (2) reached STATE_MAIN_R1
"L2TP-PSK-NAT"[2] 87.117.185.107 #8: max number of retransmissions (2) reached STATE_MAIN_R1
"L2TP-PSK-NAT"[2] 87.117.185.107 #9: max number of retransmissions (2) reached STATE_MAIN_R1
"L2TP-PSK-NAT"[2] 87.117.185.107 #10: max number of retransmissions (2) reached STATE_MAIN_R1
"L2TP-PSK-NAT"[2] 87.117.185.107: deleting connection "L2TP-PSK-NAT" instance with peer 87.117.185.107 {isakmp=#0/ipsec=#0}
Где искать решение проблемы? Я правильно понимаю, что у меня какой то Double NAT получается? Могут ли проблемы быть связаны с этим?

"L2TP-PSK-NAT"[2] 87.117.185.107 #10: STATE_MAIN_R1: sent MR1, expecting MI2[br]
"L2TP-PSK-NAT"[2] 87.117.185.107 #3: max number of retransmissions (2) reached STATE_MAIN_R1

Возможно, исходящие пакеты не доходят до клиента. Бывает, например, когда провайдер зарезал исходящий фрагментированный UDP. Смотри снифером на венде и tcpdump'ом на сервере.
Но вообще у опенсвана логи - уродство редкое, по ним никогда толком не поймешь, какого черта ему еще надо.

thesis ★★★★★ ()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от thesis

Спасибо!

Верный диагноз. На клиенте в дампе ничего то сервера не получаю. Буду пробовать получить белый IP адрес.

AlexeyMish ()
Ответ на: Спасибо! от AlexeyMish

Не факт, что поможет, даже если причина действительно в этом.
Тем более я тут подумал - обычно причина фрагментации UDP это размер сертификатов, а у тебя PSK.
Так что строка «max number of retransmissions (2) reached» может означать, что сервер даже не пытается перепослать то, чего от него просит венда. Вопрос в том, чего именно она просит, и почему.
Ненавижу логи openswan'а. Не-на-ви-жу.

Если есть возможность, воткни strongswan, лучше пятый. Его выхлоп хоть читать можно, да и конфигурировать методом копипасты проще.

thesis ★★★★★ ()
Последнее исправление: thesis (всего исправлений: 2)
Ответ на: комментарий от thesis

Может быть посоветуешь чего? Хочется сервер поставить, чтоб можно было без дополнительных танцев подключиться Iphone, Android, Windows. В смысле без сторонних приблуд, все из коробки. Тут вроде как должно было взлететь, судя по http://habrahabr.ru/company/FastVPS/blog/205162/.

AlexeyMish ()
Ответ на: комментарий от AlexeyMish

Посоветовал уже - strongswan. У него вменяемая вика и вменяемые логи. Еще советую держать одновременно IPSec+L2TP и IKEv2, потому что на IPSec+L2TP и protostack=netkey не получится держать нескольких клиентов за общим NAT'ом, а klips, с которым это получалось, вроде как отовсюду повыкидывали (хотя про дебиян не знаю).

И еще всякие хабры советую курить в последнюю очередь, а начинать с типовых конфигов, которые есть в документации к *swan'ам. В /usr/share/doc/ загляни, может и openswan победишь. В случае с PSK там чуть ли не пять строк минимального конфига всего, всё просто.

thesis ★★★★★ ()
Ответ на: комментарий от thesis

Перед тем, как разбираться с strongswan хочу убедиться, что yt смог победить openswan. Подключил дома комп напрямую, мимо роутера. Логи сильно изменились. теперь при подключении: http://pastebin.com/KtNLxHUn Я правильно понимаю, что соединение поднимается, но по какой то причине сразу после поднятия рвется?

ЗЫ в /usr/share/doc/ ничего интересного не нашел.

ls /usr/share/doc/openswan/
changelog.Debian.gz  changelog.gz  copyright  CREDITS  NEWS.Debian.gz  README.Debian.gz

AlexeyMish ()
Ответ на: комментарий от AlexeyMish

Да, здесь вроде бы все хорошо. Теперь, похоже, пришло время смотреть в логи xl2tpd. Если там пусто - в iptables.

ls /usr/share/doc/openswan/

Ну лезь в гугль тогда, или на гитхаб. Где-то у них точно валялась пачка минимальных конфигов для тестирования разных схем. В редхатах, емнип, документация была вынесена в отдельный пакет, в дебиане не знаю.

Впрочем, теперь это уже не так важно - этот уровень более-менее работает.

Ну и в роутер загляни. Есть ли там что-нибудь насчет ipsec passthrough.

thesis ★★★★★ ()
Ответ на: комментарий от thesis

Тяжело мне дается настройка. В логах xl2tpd пусто. Смотрею tcpdump.

root@dtcoalex:~# tcpdump -i eth0 -n -nn -ttt host 87.117.185.107 and port not 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:00:00.000000 IP 87.117.185.107.641 > 91.245.35.34.500: isakmp: phase 1 I ident
00:00:00.000517 IP 91.245.35.34.500 > 87.117.185.107.641: isakmp: phase 1 R ident
00:00:00.090974 IP 87.117.185.107.641 > 91.245.35.34.500: isakmp: phase 1 I ident
00:00:00.007878 IP 91.245.35.34.500 > 87.117.185.107.641: isakmp: phase 1 R ident
00:00:00.057674 IP 87.117.185.107.62368 > 91.245.35.34.4500: NONESP-encap: isakmp: phase 1 I ident[E]
00:00:00.000240 IP 91.245.35.34.4500 > 87.117.185.107.62368: NONESP-encap: isakmp: phase 1 R ident[E]
00:00:00.039128 IP 87.117.185.107.62368 > 91.245.35.34.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
00:00:00.010005 IP 91.245.35.34.4500 > 87.117.185.107.62368: NONESP-encap: isakmp: phase 2/others R oakley-quick[E]
00:00:00.039682 IP 87.117.185.107.62368 > 91.245.35.34.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
00:00:00.002843 IP 87.117.185.107.62368 > 91.245.35.34.4500: UDP-encap: ESP(spi=0x0a535b55,seq=0x1), length 148
00:00:00.000045 IP 91.245.35.34 > 87.117.185.107: ICMP 91.245.35.34 udp port 1701 unreachable, length 135
00:00:00.999668 IP 87.117.185.107.62368 > 91.245.35.34.4500: UDP-encap: ESP(spi=0x0a535b55,seq=0x2), length 148
00:00:00.000070 IP 91.245.35.34 > 87.117.185.107: ICMP 91.245.35.34 udp port 1701 unreachable, length 135
00:00:01.999909 IP 87.117.185.107.62368 > 91.245.35.34.4500: UDP-encap: ESP(spi=0x0a535b55,seq=0x3), length 148
00:00:00.000056 IP 91.245.35.34 > 87.117.185.107: ICMP 91.245.35.34 udp port 1701 unreachable, length 135
00:00:03.999960 IP 87.117.185.107.62368 > 91.245.35.34.4500: UDP-encap: ESP(spi=0x0a535b55,seq=0x4), length 148
00:00:00.000053 IP 91.245.35.34 > 87.117.185.107: ICMP 91.245.35.34 udp port 1701 unreachable, length 135
00:00:08.000264 IP 87.117.185.107.62368 > 91.245.35.34.4500: UDP-encap: ESP(spi=0x0a535b55,seq=0x5), length 148
00:00:00.000057 IP 91.245.35.34 > 87.117.185.107: ICMP 91.245.35.34 udp port 1701 unreachable, length 135
00:00:04.962958 IP 87.117.185.107.62368 > 91.245.35.34.4500: isakmp-nat-keep-alive
00:00:05.036976 IP 87.117.185.107.62368 > 91.245.35.34.4500: UDP-encap: ESP(spi=0x0a535b55,seq=0x6), length 148
00:00:00.000056 IP 91.245.35.34 > 87.117.185.107: ICMP 91.245.35.34 udp port 1701 unreachable, length 135
00:00:10.014275 IP 87.117.185.107.62368 > 91.245.35.34.4500: NONESP-encap: isakmp: phase 2/others I inf[E]
00:00:00.000216 IP 91.245.35.34.4500 > 87.117.185.107.62368: NONESP-encap: isakmp: phase 2/others R inf[E]
00:00:00.001324 IP 87.117.185.107.62368 > 91.245.35.34.4500: NONESP-encap: isakmp: phase 2/others I inf[E]
00:00:00.004789 IP 91.245.35.34.4500 > 87.117.185.107.62368: NONESP-encap: isakmp: phase 2/others R inf[E]

Но у меня в iptables везде Policy Accept.

root@dtcoalex:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain fail2ban-ssh (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

Насколько понимаю, это либо нет слушателя на порту 1701 либо пакеты дропаются на файерволе. Проверяю, вижу, что нет слушателя на 1701.
root@dtcoalex:~# netstat -an | grep 1701
root@dtcoalex:~#

Смотрю запущен ли xl2tpd

 ps aux | grep xl2tpd
root      3094  0.0  0.3   3552   792 pts/0    S+   05:27   0:00 grep xl2tpd

проверяю на всякий случай конфиг, вроде бы все правильно

cat /etc/xl2tpd/xl2tpd.conf
[global]
port = 1701
auth file = /etc/xl2tpd/l2tp-secrets        # auth file with pars login/password for l2tp auth
[lns default]
ip range = 10.0.0.2-10.0.0.200              # range of IP's , that give to clients when auth is good
local ip = 10.0.0.1
refuse chap = yes
refuse pap = yes
require authentication = yes
ppp debug = yes                                        # debug mode
pppoptfile = /etc/ppp/options.xl2tpd        #  this is ppp options config file
length bit = yes
exclusive = no
assign ip = yes
name = VPN-Server
debug
logfile /var/log/xl2tpd.log
Не могу понять, куда смотреть дальше.

AlexeyMish ()
Ответ на: комментарий от AlexeyMish

Не могу понять, куда смотреть дальше.
logfile /var/log/xl2tpd.log

:)
Кстати, у xl2tpd есть ключи для дебажного запуска в консоли.
Что-то типа xl2tpd -c /etc/xl2tpd.conf -D, не помню точно.
На время отладки службу можно тормознуть и запускать его вот таким вот образом.

thesis ★★★★★ ()
Ответ на: комментарий от thesis

Заборол! ошибка в конфиге xl2tpd.conf оказывается ";" не считается знаком комментария. =) осталось забороть маршрутизацию, но это будет в следующем посте.

AlexeyMish ()
Ответ на: комментарий от thesis

Смежный вопрос по маршрутизации. Не знаю в какую сторону гуглить. Смотри, в openvpn есть возможность при подключении раздавать маршруты. В случае с openswan можно, что-то похожее замутить? т.е. чтобы на клиенте, шлюз по умолчанию не менялся, просто прописывались нужные мне маршруты.

AlexeyMish ()
Ответ на: комментарий от AlexeyMish

Раздавать информацию о сети предназначен DHCP.
В частности, безклассовые маршруты - это опция 249 (для вендов) и 121 (для остальных).
То есть, теперь твоя задача состоит в том, чтобы поднять сервер дхцп, который будет отвечать на бродкасты впн-клиентам, но не мешать остальной сети.

thesis ★★★★★ ()
Ответ на: комментарий от thesis

Хмм.. интересная задача. Начал изучать вопрос, сразу возникли непонятки.

Насколько я понимаю, дхцп должно вещать в интерфейс, который работает с впн клиентами. Для того, чтобы указать в какой интерфейс должен работать dhcp сервер нужно в строке INTERFACES указывать сетевой интерфейс, который смотрит в сторону впн клиентов.

nano /etc/default/dhcp3-server
INTERFACES="pppx"
Но т.к. интерфейс поднимается, только после подключения впн клиентов, dhcp должен начинать работать в момент поднятия интерфейса ppp0,ppp1.... pppx. Тут у меня начинается каша в голове. Будет ли dhcp раздавать адреса из единого пула в различные интерфейсы? Как для разных интерфейсов прописывать свои шлюзы? Ведь для ppp0 в качестве gateway должно быть 10.0.0.1, для ppp1 - 10.0.0.3.

Или мне не нужно прописывать в какой интерфейс будет работать dhcp сервер, а нужно в iptables зарубить бродкасты от всех, кроме впн клиентов?

AlexeyMish ()
Ответ на: комментарий от AlexeyMish

Будет ли dhcp раздавать адреса из единого пула в различные интерфейсы?

По идее, он не должен раздавать адреса из диапазонов, в которых сам не живет. По крайней мере, так сделано в dnsmasq, про isc dhcpd не скажу.
И вообще, не пофиг ли тебе адреса, тебе ж надо маршруты раздать, а адреса он может вообще не раздавать, пусть это делает ppp, например.

а нужно в iptables зарубить бродкасты от всех, кроме впн клиентов?

Вполне вариант.

Как для разных интерфейсов прописывать свои шлюзы?

Во-первых, не знаю, это уже RTFM.
Во-вторых, у тебя в xl2tpd.conf указано «local ip = 10.0.0.1». Это и есть твой «впн-шлюз» для всех клиентов.

Ты пробуй, пробуй. Тебе осталось-то всего лишь с дхцп разобраться. Куришь лог запросов-ответов, постепенно приходит понимание.

thesis ★★★★★ ()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от thesis

Это сладкое чувство победы. :)

Маршруты получил. На винде, все как надо заработало.

Теперь у меня есть нормально настроенный туннель, для прослушивания радио пандоры откуда угодно.

cat /etc/dnsmasq.conf

domain-needed

# Change this line if you want dns to get its upstream servers from
# somewhere other that /etc/resolv.conf
resolv-file=/etc/resolv.conf

# By  default,  dnsmasq  will  send queries to any of the upstream
# servers it knows about and tries to favour servers to are  known
# to  be  up.  Uncommenting this forces dnsmasq to try each query
# with  each  server  strictly  in  the  order  they   appear   in
# /etc/resolv.conf
strict-order

server=8.8.8.8

interface= lo

except-interface=eth0
no-dhcp-interface=eth0

except-interface=tun0
no-dhcp-interface=tun0

listen-address=10.0.0.1

#bind-interfaces

domain= local

dhcp-option=vendor:MSFT,2,1i

dhcp-range=10.0.0.2,10.0.0.200,255.255.0.0,12h
dhcp-option=option:domain-search,local
dhcp-option=1,255.255.255.0


dhcp-option=6, 4.4.4.4, 8.8.8.8
dhcp-option=121, 10.0.0.0/24,  10.8.0.10/24, 17.149.36.0/24, 17.154.66.0/24, 208.85.40.0/24, 213.180.204.3, 10.0.0.1
dhcp-option=249, 10.0.0.0/24,  10.8.0.10/24, 17.149.36.0/24, 17.154.66.0/24, 208.85.40.0/24, 213.180.204.3, 10.0.0.1
log-dhcp
AlexeyMish ()
Ответ на: комментарий от AlexeyMish

Мои поздравления.
Отметь тему, как решенную.

thesis ★★★★★ ()
Ответ на: комментарий от AlexeyMish

а как вы добились работы dnsmasq совместно с «dhcp сервером» встроенным в xl2tpd? у меня или туннель не поднимается, или клиент получает маршруты и днс от xl2tpd только.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.