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

L2TP + IPsec на CentOS 6

 , ,


0

3

Доброго времени суток.

Не получается запустить работу l2tp + ipsec на centos 6 В итоге воспользовался скриптом с https://github.com/hwdsl2/setup-ipsec-vpn Как итог на данный момент: - Если настраивать клиента (android 6) на подключение L2TP/IPsec PSK то соединение не устанавливается - Если настраивать клиента на подключение L2TP, то соединение устанавливается, но ни чего не маршрутизируется. IP получает, но пингануть может только сам себя. - Если настраивать клиента на подключение IPsec PSK, то тоже устанавливается соединение, получаю IP и так же не могу пинговать ничего, кроме самого себя. IPsec настраивался на openswen (Libreswan 3.18)

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



Последнее исправление: Lavrentiy (всего исправлений: 1)
← ipsec cisco + strongswan
Посоветуйте умный роутер →
Ответ на: комментарий от gserg 
iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  0.0.0.0/0            xxx.xxx.xxx.xxx       multiport dports 25,465,587 to:10.77.17.6
DNAT       tcp  --  0.0.0.0/0            xxx.xxx.xxx.xxx       multiport dports 80,443 to:10.77.17.31
DNAT       tcp  --  0.0.0.0/0            xxx.xxx.xxx.xxx       multiport dports 1723,47 to:10.77.17.1

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
SNAT       all  --  10.77.17.0/24        0.0.0.0/0           to:xxx.xxx.xxx.xxx
SNAT       all  --  10.77.18.0/24        0.0.0.0/0           policy match dir out pol none to:xxx.xxx.xxx.xxx
SNAT       tcp  --  0.0.0.0/0            10.77.17.1          multiport dports 1723,47 to:xxx.xxx.xxx.xxx
SNAT       all  --  10.77.16.0/22        0.0.0.0/0           policy match dir out pol none to:xxx.xxx.xxx.xxx
MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0

Где: xxx.xxx.xxx.xxx IP внешнего интерфейса eth1
10.77.17.0/24 - Локальная сеть к которой подключаются пользователи
10.77.18.0/24 - Сеть в которую попадают при подключении по L2TP/IPsec PSK
ipsec.conf 

version 2.0

config setup
  nat_traversal=yes
  virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.77.17.0/24,%v4:!10.77.17.0/24,v4:!10.77.18.0/24
  protostack=netkey
  nhelpers=0
  interfaces=%defaultroute
  uniqueids=no
  klipsdebug=all
  plutodebug=all
conn shared
  left=xxx.xxx.xxx.xxx
  #leftid=xxx.xxx.xxx.xxx
  right=%any
  forceencaps=yes
  authby=secret
  pfs=no
  rekey=no
  keyingtries=5
  dpddelay=30
  dpdtimeout=120
  dpdaction=clear
  ike=3des-sha1,aes-sha1,aes256-sha2_512,aes256-sha2_256
  phase2alg=3des-sha1,aes-sha1,aes256-sha2_512,aes256-sha2_256

conn l2tp-psk
  auto=add
  leftsubnet=xxx.xxx.xxx.xxx/32
  leftnexthop=%defaultroute
  leftprotoport=17/%any
  rightprotoport=17/%any
  type=transport
  auth=esp
  also=shared

conn xauth-psk
  auto=add
  leftsubnet=0.0.0.0/0
  rightaddresspool=10.77.18.220-10.77.18.250
  modecfgdns1=10.77.17.30
  modecfgdns2=10.77.17.31
  leftxauthserver=yes
  rightxauthclient=yes
  leftmodecfgserver=yes
  rightmodecfgclient=yes
  modecfgpull=yes
  xauthby=file
  ike-frag=yes
  ikev2=never
  cisco-unity=yes
  #also=shared
xl2tpd.conf 
[global]
port = 1701

debug avp = yes
debug network = yes
debug packet = yes
debug state = yes
debug tunnel = yes

[lns default]
ip range = 10.77.18.220-10.77.18.250
local ip = 10.77.18.1
require chap = yes
refuse pap = yes
require authentication = yes
name = l2tpd
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
options.xl2tpd 
ipcp-accept-local
ipcp-accept-remote
ms-dns 10.77.17.30
ms-dns 10.77.17.31
noccp
auth
crtscts
mtu 1280
mru 1280
lock
proxyarp
lcp-echo-failure 4
lcp-echo-interval 30
connect-delay 5000

Lavrentiy
() автор топика
Ответ на: комментарий от pyata4ka

Все советуют OpenVPN, но у большинства кто занимается не им стоит задача, установка VPN связи стандартными средствами без установки доп.приложений. Так что ждём лучших времён, когда крупные игроки рынка встроят поддержку OpenVPN в свои OS.

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

Читать логи.

Я читаю логи из /var/log/messages и /var/log/secure , но получаю от туда минимум информации и гуглёжка меня не спасает из-за низкой грамотности в этом русле
Вот примеры логов после попытки подключиться:
/var/log/messages 

Nov 30 12:38:17 iskra rsyslogd-2177: imuxsock begins to drop messages from pid 23267 due to rate-limiting
Nov 30 12:38:24 iskra rsyslogd-2177: imuxsock lost 602 messages from pid 23267 due to rate-limiting
Nov 30 12:38:24 iskra rsyslogd-2177: imuxsock begins to drop messages from pid 23267 due to rate-limiting
Nov 30 12:38:30 iskra rsyslogd-2177: imuxsock lost 1003 messages from pid 23267 due to rate-limiting
Nov 30 12:38:33 iskra rsyslogd-2177: imuxsock begins to drop messages from pid 23267 due to rate-limiting
Nov 30 12:38:36 iskra rsyslogd-2177: imuxsock lost 206 messages from pid 23267 due to rate-limiting
Nov 30 12:38:36 iskra rsyslogd-2177: imuxsock begins to drop messages from pid 23267 due to rate-limiting
Nov 30 12:38:42 iskra rsyslogd-2177: imuxsock lost 602 messages from pid 23267 due to rate-limiting
Nov 30 12:38:42 iskra rsyslogd-2177: imuxsock begins to drop messages from pid 23267 due to rate-limiting
Nov 30 12:38:50 iskra rsyslogd-2177: imuxsock lost 607 messages from pid 23267 due to rate-limiting
Nov 30 12:38:53 iskra xl2tpd[19579]: Maximum retries exceeded for tunnel 20174.  Closing.
Nov 30 12:38:53 iskra xl2tpd[19579]: Connection 1901 closed to 10.77.17.101, port 57823 (Timeout)
/var/log/secure 
Nov 30 12:38:17 iskra pluto[23267]: | *received 580 bytes from 10.77.17.101:500 on eth1 (port=500)
Nov 30 12:38:17 iskra pluto[23267]: |   5c 05 91 3f  f7 5d de a3  00 00 00 00  00 00 00 00
(подобные строчки как выше)
Nov 30 12:38:17 iskra pluto[23267]: |   77 57 01 00
Nov 30 12:38:17 iskra pluto[23267]: | **parse ISAKMP Message:
Nov 30 12:38:17 iskra pluto[23267]: |    initiator cookie:
Nov 30 12:38:17 iskra pluto[23267]: |   5c 05 91 3f  f7 5d de a3
Nov 30 12:38:17 iskra pluto[23267]: |    responder cookie:
Nov 30 12:38:17 iskra pluto[23267]: |   00 00 00 00  00 00 00 00
Nov 30 12:38:17 iskra pluto[23267]: |    next payload type: ISAKMP_NEXT_SA (0x1)
Nov 30 12:38:17 iskra pluto[23267]: |    ISAKMP version: ISAKMP Version 1.0 (rfc2407) (0x10)
Nov 30 12:38:17 iskra pluto[23267]: |    exchange type: ISAKMP_XCHG_IDPROT (0x2)
Nov 30 12:38:17 iskra pluto[23267]: |    flags: none (0x0)
Nov 30 12:38:17 iskra pluto[23267]: |    message ID:  00 00 00 00
Nov 30 12:38:17 iskra pluto[23267]: |    length: 580 (0x244)
Nov 30 12:38:17 iskra pluto[23267]: |  processing version=1.0 packet with exchange type=ISAKMP_XCHG_IDPROT (2)
Nov 30 12:38:17 iskra pluto[23267]: | got payload 0x2  (ISAKMP_NEXT_SA) needed: 0x2opt: 0x2080
Nov 30 12:38:17 iskra pluto[23267]: | ***parse ISAKMP Security Association Payload:
Nov 30 12:38:17 iskra pluto[23267]: |    next payload type: ISAKMP_NEXT_VID (0xd)
Nov 30 12:38:17 iskra pluto[23267]: |    length: 428 (0x1ac)
Nov 30 12:38:17 iskra pluto[23267]: |    DOI: ISAKMP_DOI_IPSEC (0x1)

Nov 30 12:38:17 iskra pluto[23267]: | got payload 0x2000  (ISAKMP_NEXT_VID) needed: 0x0opt: 0x2080
Nov 30 12:38:17 iskra pluto[23267]: | ***parse ISAKMP Vendor ID Payload:
Nov 30 12:38:17 iskra pluto[23267]: |    next payload type: ISAKMP_NEXT_VID (0xd)
Nov 30 12:38:17 iskra pluto[23267]: |    length: 20 (0x14)
(подобных 4 строки повторяется несколько раз)

Nov 30 12:38:17 iskra pluto[23267]: |  quirks.qnat_traversal_vid set to=89
Nov 30 12:38:17 iskra pluto[23267]: | received Vendor ID payload [RFC 3947]
Nov 30 12:38:17 iskra pluto[23267]: | Ignoring older NAT-T Vendor ID paylad [draft-ietf-ipsec-nat-t-ike-02]
Nov 30 12:38:17 iskra pluto[23267]: | ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
Nov 30 12:38:17 iskra pluto[23267]: | Ignoring older NAT-T Vendor ID paylad [draft-ietf-ipsec-nat-t-ike-02_n]
Nov 30 12:38:17 iskra pluto[23267]: | ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Nov 30 12:38:17 iskra pluto[23267]: | ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Nov 30 12:38:17 iskra pluto[23267]: | received Vendor ID payload [FRAGMENTATION 80000000]
Nov 30 12:38:17 iskra pluto[23267]: | received Vendor ID payload [Dead Peer Detection]
Nov 30 12:38:17 iskra pluto[23267]: | find_host_connection me=xxx.xxx.xxx.xxx:500 him=10.77.17.101:500 policy=IKEV1_ALLOW
Nov 30 12:38:17 iskra pluto[23267]: | find_host_pair_conn: xxx.xxx.xxx.xxx:500 10.77.17.101:500 -> hp:none
Nov 30 12:38:17 iskra pluto[23267]: | find_next_host_connection policy=IKEV1_ALLOW
Nov 30 12:38:17 iskra pluto[23267]: | find_next_host_connection returns empty
Nov 30 12:38:17 iskra pluto[23267]: | ****parse IPsec DOI SIT:
Nov 30 12:38:17 iskra pluto[23267]: |    IPsec DOI SIT: SIT_IDENTITY_ONLY (0x1)
Nov 30 12:38:17 iskra pluto[23267]: | ****parse ISAKMP Proposal Payload:
Nov 30 12:38:17 iskra pluto[23267]: |    next payload type: ISAKMP_NEXT_NONE (0x0)
Nov 30 12:38:17 iskra pluto[23267]: |    length: 416 (0x1a0)
Nov 30 12:38:17 iskra pluto[23267]: |    proposal number: 1 (0x1)
Nov 30 12:38:17 iskra pluto[23267]: |    protocol ID: PROTO_ISAKMP (0x1)
Nov 30 12:38:17 iskra pluto[23267]: |    SPI size: 0 (0x0)
Nov 30 12:38:17 iskra pluto[23267]: |    number of transforms: 12 (0xc)
Nov 30 12:38:17 iskra pluto[23267]: | *****parse ISAKMP Transform Payload (ISAKMP):
Nov 30 12:38:17 iskra pluto[23267]: |    next payload type: ISAKMP_NEXT_T (0x3)
Nov 30 12:38:17 iskra pluto[23267]: |    length: 36 (0x24)
Nov 30 12:38:17 iskra pluto[23267]: |    ISAKMP transform number: 1 (0x1)
Nov 30 12:38:17 iskra pluto[23267]: |    ISAKMP transform ID: KEY_IKE (0x1)
Nov 30 12:38:17 iskra pluto[23267]: | ******parse ISAKMP Oakley attribute:
Nov 30 12:38:17 iskra pluto[23267]: |    af+type: OAKLEY_LIFE_TYPE (0x800b)
Nov 30 12:38:17 iskra pluto[23267]: |    length/value: 1 (0x1)
Nov 30 12:38:17 iskra pluto[23267]: | ******parse ISAKMP Oakley attribute:
Nov 30 12:38:17 iskra pluto[23267]: |    af+type: OAKLEY_LIFE_DURATION (0x800c)
Nov 30 12:38:17 iskra pluto[23267]: |    length/value: 28800 (0x7080)
Nov 30 12:38:17 iskra pluto[23267]: | ******parse ISAKMP Oakley attribute:
Nov 30 12:38:17 iskra pluto[23267]: |    af+type: OAKLEY_ENCRYPTION_ALGORITHM (0x8001)
Nov 30 12:38:17 iskra pluto[23267]: |    length/value: 7 (0x7)
Nov 30 12:38:17 iskra pluto[23267]: | ******parse ISAKMP Oakley attribute:
Nov 30 12:38:17 iskra pluto[23267]: |    af+type: OAKLEY_KEY_LENGTH (0x800e)
Nov 30 12:38:17 iskra pluto[23267]: |    length/value: 256 (0x100)
Nov 30 12:38:17 iskra pluto[23267]: | ******parse ISAKMP Oakley attribute:
Nov 30 12:38:17 iskra pluto[23267]: |    af+type: OAKLEY_AUTHENTICATION_METHOD (0x8003)
и т.д. до прерывания попыток соединения
Это повторяется несколько раз, по количеству отправленных запросов на подключение.

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

Смотрю в логи вижу фигу

В этих логах не могу понять и нагуглить следующее:

Nov 30 12:38:17 iskra pluto[23267]: |    responder cookie:
Nov 30 12:38:17 iskra pluto[23267]: |   00 00 00 00  00 00 00 00
Тут смущают нули, но откуда они тут и почему и что должно быть... 
Nov 30 12:38:17 iskra pluto[23267]: |    flags: none (0x0)
Nov 30 12:38:17 iskra pluto[23267]: |    message ID:  00 00 00 00
Тоже самое, но мне кажется, что оэто следствие полученых ранее нулей... 
ov 30 12:38:17 iskra pluto[23267]: | find_host_pair_conn: xxx.xxx.xxx.xxx:500 10.77.17.101:500 -> hp:none
Почему none, откуда, что за это отвечает и как исправить? Или это всё также виноваты те самые нули? 
Nov 30 12:38:17 iskra pluto[23267]: | find_next_host_connection returns empty
Соответственно мне не нравится empty

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

Надо придушить логирование, оно сейчас слишком подробное. Поищи по манам как задать параметр plutodebug. По идее, его можно менять на ходу командой ipsec whack, но без курения манов не подскажу.
Либо пролистывай мусор и ищи в конце лога сообщение о конкретной ошибке.
Либо выкинь либру, поставь strongswan. Всегда так делаю.

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

ipsec.conf
в разделе:
config setup
заменил строки на: 

klipsdebug=none
plutodebug=control
так же там написано что они указывают: interfaces="ipsec0=eth1 ipsec1=ppp0"
Логи же стали лаконичней. 
Nov 30 15:22:47 iskra pluto[24804]: | *received 580 bytes from 10.77.17.101:500 on eth1 (port=500)
Nov 30 15:22:47 iskra pluto[24804]: |  processing version=1.0 packet with exchange type=ISAKMP_XCHG_IDPROT (2)
Nov 30 15:22:47 iskra pluto[24804]: | received Vendor ID payload [RFC 3947]
Nov 30 15:22:47 iskra pluto[24804]: | ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
Nov 30 15:22:47 iskra pluto[24804]: | ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Nov 30 15:22:47 iskra pluto[24804]: | ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Nov 30 15:22:47 iskra pluto[24804]: | received Vendor ID payload [FRAGMENTATION 80000000]
Nov 30 15:22:47 iskra pluto[24804]: | received Vendor ID payload [Dead Peer Detection]
Nov 30 15:22:47 iskra pluto[24804]: packet from 10.77.17.101:500: initial Main Mode message received on xxx.xxx.xxx.xxx:500 but no connection has been authorized with policy PSK+IKEV1_ALLOW
Nov 30 15:22:47 iskra pluto[24804]: | complete v1 state transition with STF_IGNORE

Nov 30 15:22:14 iskra kernel: padlock: VIA PadLock not detected.
Nov 30 15:22:14 iskra kernel: padlock: VIA PadLock Hash Engine not detected.
Nov 30 15:22:14 iskra kernel: Intel AES-NI instructions are not detected.
Nov 30 15:22:15 iskra kernel: Intel AES-NI instructions are not detected.
Nov 30 15:22:15 iskra kernel: padlock: VIA PadLock not detected.
Nov 30 15:22:15 iskra kernel: Intel AES-NI instructions are not detected.
Nov 30 15:22:15 iskra kernel: Intel PCLMULQDQ-NI instructions are not detected.
Nov 30 15:22:58 iskra xl2tpd[19579]: Maximum retries exceeded for tunnel 19008.  Closing.
Nov 30 15:22:58 iskra xl2tpd[19579]: Connection 14487 closed to 10.77.17.101, port 54574 (Timeout)
С новыми результатами погружаюсь в гугление

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

Либо пролистывай мусор и ищи в конце лога сообщение о конкретной ошибке.

Поиском в cat /var/log/secure | grep "error" и cat /var/log/messages | grep "error" за сегодня ни чего не выдаёт.

Либо выкинь либру, поставь strongswan. Всегда так делаю.

Пробовал и StrongSWAN - результат тот же.

Lavrentiy
() автор топика

Поясните

Так же у меня сомнения, правильно ли я понимаю строку конфигурации в ipsec.conf
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.77.17.0/24,%v4:!10.77.17.0/24,v4:!10.77.18.0/24
Что всё что без "!", то якобы как за NAT-ом, а то что с "!", то без NAT-а?
Т.е. я подключаюсь к сети 10.77.17.0/24 и мне нужно указывать её через "!", верно?
Остальные сети нужно указывать и зачем?

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

Не grep error, а конкретно лог pluto. Тем более, pluto можно запускать в foreground'е и смотреть.

Пробовал и StrongSWAN - результат тот же.

Потому что логов не вкуривал. У strongswan'а они более читаемые.

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

Не grep error, а конкретно лог pluto. Тем более, pluto можно запускать в foreground'е и смотреть

А можно поподробней? Уж очень большое желание победить эту беду :(

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

Чтобы читать логи pluto, надо грепать pluto, либо запускать pluto в foreground'е, либо конфигурить для pluto отдельный файл.
Строка с причиной отказа не обязательно содержит слово error (и непонятно, с чего ты вообще взял, что содержит).
Вот, например, strongswan'овское сообщение из лога:

Nov 30 14:59:30 myhostname strongswan: 05[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSEN

У pluto будет что-то свое, но выглядеть оно будет вполне миролюбиво, без всяких воплей ОШИБКА ОШИБКА ЮЗЕР ЛОХ.
Но.
Если у тебя при попытке подключить клиента по ipsec+l2tp начинает гавкать в лог еще и xl2tpd, то скорее всего с swan'ом уже все хорошо, надо смотреть уже на логи xl2tpd.

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

1. Просто соединение по L2TP происходит. Всё хорошо. Получаю IP во внутренней сети, выхожу через внутреннюю сеть в интернет, вижу локальные сервисы и т.д.
2. Пробую подключить чистый IPsec PSK, он перестал коннектиться. Хотя когда коннектился, толку от этого было ноль
3. Соответственно и по L2TP+IPsec_PSK он тоже не коннектится.
Выше задавал вопрос про конфигурацию ipsec.conf. Что именно значит virtual_private и какие сети нужно включать и какие нет?
При связки L2TP+IPsec в начале устанавливается L2TP или IPsec, судя по логам и мануалам, то в начале идёт IPsec соединение по UDP 500 порту. А вот дальше тишина и не понятная для меня действительность. И в логах про xl2tpd 

Dec  1 13:52:42 iskra xl2tpd[19579]: Maximum retries exceeded for tunnel 41384.  Closing.
Dec  1 13:52:42 iskra xl2tpd[19579]: Connection 60395 closed to 10.77.17.101, port 49396 (Timeout)
Курю мануалы...

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

Что именно значит virtual_private

Это те сети, в которые ты не хочешь ходить по туннелю, потому что они находятся «по эту сторону».

Maximum retries exceeded for tunnel 41384. Closing.

Это не самая информативная часть.
Выкинь из конфигов все секции conn, кроме одной, где будут только хосты и authby/auto/опционально_keyexchange, т.е. минимум. Добейся коннекта и только потом наращивай конфиг.
И я серьезно, если не можешь назвать причину юзать libreswan - ставь strongswan.

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

thesis - спасибо. Действительно, работать с strongswan оказалось проще. Настроил его без L2TP.
Есть только два момента, которые не знаю как решить красиво
1. Настройка VPN на android без приложения, а исключительно штатными средствами.
2. Автоматически генерировать ключи для пользователей которые находятся в группе VPN в AD. И закрывать доступ тем, кого удалили из этой группы.

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

1) В AD предпочтительна аутентификация по паролям без гемора с клиентскими сертификатами и без убожества PSK. Поэтому можно пользоваться IKEv2 с EAP-MSCHAPv2 для вендов и IPSec Hybrid для андроидов. Для легаси можно настроить IKEv1+L2TP.
Вся эта ерунда подразумевает наличие радиуса (вендовый NPS), см. плагин стронгсвана eap-radius.
2) Нафиг ключи, см. п. 1.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 2)
23 марта 2018 г.
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← ipsec cisco + strongswan
Admin
Посоветуйте умный роутер →