Перейти к содержанию

Рекомендуемые сообщения

Опубликовано

Здравствуйте!

Помогите пожалуйста с настройками клиентов на linux для начинающих. Хотя бы просто примеры ipsec.conf.

Для следующей конфигурации:

На Giga II поднял IPSec VPN c такими настройками:

h_1482834301_5455319_4151cb0431.png

Giga II  на внешнем интерфейсе имеет адрес 48.210.2.2, шлюз 48.210.2.1, внутренняя сеть 192.168.0.0/24 сидит за NAT, шлюз 192.168.0.1

Клиент находится за натом 192.168.2.2/32, шлюз 192.168.2.1, iptables пустой, без правил, Внешний адрес у клиента 212.20.13.66, шлюз 213.228.116.18

Третий день не могу понять, что и как надо настроить. Во первых сбивает с толку разница в терминологии, там left и right, здесь local и remote (локальная и удалённая сеть). У кинетика это left или right сторона?

Ну и всё в таком духе, в общем первый опыт и пока во всём разберёшся... не работает пока. Прошу помощи.

Опубликовано
1 час назад, pdn_mail сказал:

Здравствуйте!

Помогите пожалуйста с настройками клиентов на linux для начинающих. Хотя бы просто примеры ipsec.conf.

Для следующей конфигурации:

На Giga II поднял IPSec VPN c такими настройками:

h_1482834301_5455319_4151cb0431.png

Giga II  на внешнем интерфейсе имеет адрес 48.210.2.2, шлюз 48.210.2.1, внутренняя сеть 192.168.0.0/24 сидит за NAT, шлюз 192.168.0.1

Клиент находится за натом 192.168.2.2/32, шлюз 192.168.2.1, iptables пустой, без правил, Внешний адрес у клиента 212.20.13.66, шлюз 213.228.116.18

Третий день не могу понять, что и как надо настроить. Во первых сбивает с толку разница в терминологии, там left и right, здесь local и remote (локальная и удалённая сеть). У кинетика это left или right сторона?

Ну и всё в таком духе, в общем первый опыт и пока во всём разберёшся... не работает пока. Прошу помощи.

Вообще, любые знания - это в первую очередь соглашения между людьми.

Если бы вы реально хорошо разбирались в настройке *swan, то хорошо бы знали, что left принято считать локальной стороной, а right - удаленной.

Теперь по картинке:

 - идентификатором лучше сделать какой-нибудь FQDN или e-mail, использование IP-адресов для этого - прошлый век и в первую очередь вопрос совместимости со всяким старьем.

 - DH-группу для IKE ставьте не ниже 2 (modp1024), и то этого уже мало.

 - SHA256 для IPsec SA плохо совместима с аппаратным ускорением, используйте SHA1.

 - Почему не задаете DH для IPsec SA? Не нужна Perfect Forward Secrecy?

 - В качестве удаленной подсети назначьте 192.168.2.0/255.255.255.0

 

Конфиг клиента попробуйте набросать сами, если не сможете - завтра помогу.

Опубликовано (изменено)

Добрый день!

Спасибо за советы! Настройки делал аналогично этой статье, кроме параметров шифрования - https://zyxel.ru/kb/4881/  но на linux shrew-client-vpn почему-то не взлетел, пакеты не ходили между клиентом и сетью, да и проект не развивается уже 4 года, так что я его тут даже не упоминаю.

По вашим замечаниям есть замечание :) это по поводу "- идентификатором лучше сделать какой-нибудь FQDN или e-mail, использование IP-адресов для этого - прошлый век и в первую очередь вопрос совместимости со всяким старьем." Вчера наткнулся на статью в журнале "Системный администратор" №1-2 2016г. по настройке strongswan, так там так и говорится - "leftid=212.20.5.1 – а это ключевое слово описывает идентификатор. Пусть вас не смущает то, что оно имеет то же значение, что и left, – смысл у него совершенно другой. Это аналог ключевого слова my_identifier в ipsec-tools. Для PSK он должен быть задан равным IP-адресу, иначе соединение не будет установлено." Проверю потом, когда получу рабочий конфиг. Кстати отличная статья впервые за три дня которая растолковывает что к чему на начальном уровне.

 

Изменено пользователем pdn_mail
Опубликовано

Переделал настройки пока так:

h_1482910463_3925725_f7122040c5.png

в качестве удалённой сети выступает конкретный клиент (сервер 192.168.2.2), так задумано, чтобы вся удалённая сетка не шарилась по локальной, только один сервер.

установил strongswan.

как описано в статье всё, что связано с openssl, я не правил, у меня запуск swanctl не показал ошибку.

поправил только конфигурацию логирования (логи великое дело, по логам нашёл три ошибки в настройках конфигурации)

в итоге рабочая конфига:

ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
        # strictcrlpolicy=yes
        # uniqueids = no
# Add connections here.
# Sample VPN connections
conn IPSect
      ikelifetime=3h
      lifetime=3h
      ike=aes128-sha1-modp1024!
      esp=aes128-sha1-modp1024!
      left=192.168.2.2
      leftid=beta@tester.ru     # любой подоёдёт т.к. со стороны модема стоит "any"
      leftauth=psk
      leftsubnet=192.168.2.2/32
      right=48.210.2.2
      rightid=alpha@tester.ru       # для работы PSK не обязательно чтобы адрес был (может в openswan актуально?)
      rightsubnet=192.168.0.0/24
      rightauth=psk
      keyexchange=ikev1
      auto=start

ipsec.secrets
# ipsec.secrets - strongSwan IPsec secrets file
192.168.2.2 48.210.2.2 : PSK "12345678"

делаем ipsec restart и всё работает :)

Всякие данные по шлюзам и другим IP адресам со стороны клиента и шлюза провайдера оказались не нужны. (212.20.13.66 и 213.228.116.18, 48.210.2.1)

Опубликовано

только теперь вопрос, компьютер подключенный к GIGA не доступен из интернет over IPSec. Правило NAT на КЦ прописал для 192.168.2.2 на порт 80, но telnet не хочет цепляться по прокинутому порту.

Эм... это возможно?

Опубликовано
10 минут назад, pdn_mail сказал:

только теперь вопрос, компьютер подключенный к GIGA не доступен из интернет over IPSec. Правило NAT на КЦ прописал для 192.168.2.2 на порт 80, но telnet не хочет цепляться по прокинутому порту.

Эм... это возможно?

Нет, через IPsec невозможно пробрасывать default route.

Опубликовано

Каким образом можно подключить web-сервер удалённого офиса к Zyxel Giga II чтобы можно было к нему из интернет обращаться? Провайдер удалёного офиса не может дать белый IP, надо как-то зацепиться сервером к центральному офису с белым IP и при этом иметь доступ из интернет к этому удалённому web-серверу. Есть способы?

Опубликовано
35 минут назад, pdn_mail сказал:

Каким образом можно подключить web-сервер удалённого офиса к Zyxel Giga II чтобы можно было к нему из интернет обращаться? Провайдер удалёного офиса не может дать белый IP, надо как-то зацепиться сервером к центральному офису с белым IP и при этом иметь доступ из интернет к этому удалённому web-серверу. Есть способы?

А чем вам PPTP VPN с пробросом порта не угодил?

Опубликовано (изменено)

Могу предположить ещё один фантастический вариант. Поднять какой-нибудь прозрачный прокси на модеме и завернуть пакеты через него. Есть же там возможность установки свободных пакетов.

Но это именно, что из области фантастики. Даже не знаю есть ли такой пакет в готовом виде.

А что, на 2.09 сразу всё заработает или там какие-то дополнительные настройки сделать придётся? Глупость конечно спросил, пойду читать.

Изменено пользователем pdn_mail
  • 1 год спустя...
Опубликовано

Подскажите пожалуйста, что может быть не так.

Происходит хендшейк, но стопорится посередине. Причем видимо на стороне Кинетика.

[I] Apr 18 22:55:08 ipsec: Starting strongSwan 5.5.0 IPsec [starter]... 
[I] Apr 18 22:55:08 ipsec: 00[DMN] Starting IKE charon daemon (strongSwan 5.5.0, Linux 2.6.22.15, mips) 
[I] Apr 18 22:55:08 ipsec: 00[CFG] loading secrets 
[I] Apr 18 22:55:08 ipsec: 00[CFG]   loaded IKE secret for xxxxxx@gmail.com  
[I] Apr 18 22:55:08 ipsec: 00[CFG]   loaded EAP secret for vpnuser 
[I] Apr 18 22:55:08 ipsec: 00[CFG] starting systime check, interval: 10s 
[I] Apr 18 22:55:08 ipsec: 00[LIB] loaded plugins: charon aes des sha2 sha1 md5 random nonce openssl xcbc cmac hmac attr kernel-netlink socket-default stroke updown eap-mschapv2 eap-dynamic xauth-generic xauth-eap error-notify systime-fix 
[I] Apr 18 22:55:08 ipsec: 06[CFG] received stroke: add connection 'Hyperexpert' 
[I] Apr 18 22:55:08 ipsec: 06[CFG] added configuration 'Hyperexpert' 
[I] Apr 18 22:55:08 ipsec: 08[CFG] received stroke: initiate 'Hyperexpert' 
[I] Apr 18 22:55:08 ipsec: 08[IKE] sending XAuth vendor ID 
[I] Apr 18 22:55:08 ipsec: 08[IKE] sending DPD vendor ID 
[I] Apr 18 22:55:08 ipsec: 08[IKE] sending NAT-T (RFC 3947) vendor ID 
[I] Apr 18 22:55:08 ipsec: 08[IKE] sending draft-ietf-ipsec-nat-t-ike-02\n vendor ID 
[I] Apr 18 22:55:08 ipsec: 08[IKE] initiating Main Mode IKE_SA Hyperexpert[1] to 208.115.99.179 
[I] Apr 18 22:55:08 ipsec: 10[IKE] received DPD vendor ID 
[I] Apr 18 22:55:08 ipsec: 10[IKE] received FRAGMENTATION vendor ID 
[I] Apr 18 22:55:08 ipsec: 10[IKE] received XAuth vendor ID 
[I] Apr 18 22:55:08 ipsec: 10[IKE] received NAT-T (RFC 3947) vendor ID 
[I] Apr 18 22:55:08 ipsec: 10[CFG] received proposals: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/# 
[I] Apr 18 22:55:08 ipsec: 10[CFG] configured proposals: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_8192/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_6144/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_4096/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_3072/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/# 
[I] Apr 18 22:55:08 ipsec: 10[CFG] selected proposal: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/# 
[I] Apr 18 22:55:09 ipsec: 11[IKE] linked key for crypto map 'Hyperexpert' is not found, still searching 

и на этом still searching уходит в себя.

На стороне сервера:

Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: responding to Main Mode from unknown peer 93.xx.xx.xx on port 128
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP8192] refused
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP6144] refused
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP4096] refused
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP3072] refused
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: STATE_MAIN_R1: sent MR1, expecting MI2
Apr 18 15:43:22 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: STATE_MAIN_R2: sent MR2, expecting MI3
Apr 18 15:43:22 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: STATE_MAIN_R2: retransmission; will wait 0.5 seconds for response
Apr 18 15:43:23 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: ignoring informational payload INVALID_KEY_INFORMATION, msgid=00000000, length=28
Apr 18 15:43:23 mine pluto[19954]: | ISAKMP Notification Payload
Apr 18 15:43:23 mine pluto[19954]: |   00 00 00 1c  00 00 00 01  01 10 00 11
Apr 18 15:43:23 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: received and ignored informational message
Apr 18 15:43:23 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: STATE_MAIN_R2: retransmission; will wait 1 seconds for response

Ну и далше онее убивает 

 STATE_MAIN_R2: 60 second timeout exceeded after 7 retransmits.  No response (or no acceptable response) to our IKEv1 message

Опубликовано
В 4/18/2018 в 23:08, Oleg Andrianov сказал:

Подскажите пожалуйста, что может быть не так.

Происходит хендшейк, но стопорится посередине. Причем видимо на стороне Кинетика.


[I] Apr 18 22:55:08 ipsec: Starting strongSwan 5.5.0 IPsec [starter]... 
[I] Apr 18 22:55:08 ipsec: 00[DMN] Starting IKE charon daemon (strongSwan 5.5.0, Linux 2.6.22.15, mips) 
[I] Apr 18 22:55:08 ipsec: 00[CFG] loading secrets 
[I] Apr 18 22:55:08 ipsec: 00[CFG]   loaded IKE secret for xxxxxx@gmail.com  
[I] Apr 18 22:55:08 ipsec: 00[CFG]   loaded EAP secret for vpnuser 
[I] Apr 18 22:55:08 ipsec: 00[CFG] starting systime check, interval: 10s 
[I] Apr 18 22:55:08 ipsec: 00[LIB] loaded plugins: charon aes des sha2 sha1 md5 random nonce openssl xcbc cmac hmac attr kernel-netlink socket-default stroke updown eap-mschapv2 eap-dynamic xauth-generic xauth-eap error-notify systime-fix 
[I] Apr 18 22:55:08 ipsec: 06[CFG] received stroke: add connection 'Hyperexpert' 
[I] Apr 18 22:55:08 ipsec: 06[CFG] added configuration 'Hyperexpert' 
[I] Apr 18 22:55:08 ipsec: 08[CFG] received stroke: initiate 'Hyperexpert' 
[I] Apr 18 22:55:08 ipsec: 08[IKE] sending XAuth vendor ID 
[I] Apr 18 22:55:08 ipsec: 08[IKE] sending DPD vendor ID 
[I] Apr 18 22:55:08 ipsec: 08[IKE] sending NAT-T (RFC 3947) vendor ID 
[I] Apr 18 22:55:08 ipsec: 08[IKE] sending draft-ietf-ipsec-nat-t-ike-02\n vendor ID 
[I] Apr 18 22:55:08 ipsec: 08[IKE] initiating Main Mode IKE_SA Hyperexpert[1] to 208.115.99.179 
[I] Apr 18 22:55:08 ipsec: 10[IKE] received DPD vendor ID 
[I] Apr 18 22:55:08 ipsec: 10[IKE] received FRAGMENTATION vendor ID 
[I] Apr 18 22:55:08 ipsec: 10[IKE] received XAuth vendor ID 
[I] Apr 18 22:55:08 ipsec: 10[IKE] received NAT-T (RFC 3947) vendor ID 
[I] Apr 18 22:55:08 ipsec: 10[CFG] received proposals: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/# 
[I] Apr 18 22:55:08 ipsec: 10[CFG] configured proposals: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_8192/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_6144/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_4096/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_3072/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/# 
[I] Apr 18 22:55:08 ipsec: 10[CFG] selected proposal: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/# 
[I] Apr 18 22:55:09 ipsec: 11[IKE] linked key for crypto map 'Hyperexpert' is not found, still searching 

и на этом still searching уходит в себя.

На стороне сервера:


Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: responding to Main Mode from unknown peer 93.xx.xx.xx on port 128
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP8192] refused
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP6144] refused
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP4096] refused
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP3072] refused
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: STATE_MAIN_R1: sent MR1, expecting MI2
Apr 18 15:43:22 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: STATE_MAIN_R2: sent MR2, expecting MI3
Apr 18 15:43:22 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: STATE_MAIN_R2: retransmission; will wait 0.5 seconds for response
Apr 18 15:43:23 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: ignoring informational payload INVALID_KEY_INFORMATION, msgid=00000000, length=28
Apr 18 15:43:23 mine pluto[19954]: | ISAKMP Notification Payload
Apr 18 15:43:23 mine pluto[19954]: |   00 00 00 1c  00 00 00 01  01 10 00 11
Apr 18 15:43:23 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: received and ignored informational message
Apr 18 15:43:23 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: STATE_MAIN_R2: retransmission; will wait 1 seconds for response

Ну и далше онее убивает 

 STATE_MAIN_R2: 60 second timeout exceeded after 7 retransmits.  No response (or no acceptable response) to our IKEv1 message

Если вам реально нужен IPsec, то переходите на последний delta / draft, и используйте IKEv2. В 2.06 IPsec хоть и присутствует, но содержит много недоработок.

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.