Jump to content

Recommended Posts

Posted

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

Помогите пожалуйста с настройками клиентов на 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 сторона?

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

Posted
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

 

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

Posted (edited)

Добрый день!

Спасибо за советы! Настройки делал аналогично этой статье, кроме параметров шифрования - 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-адресу, иначе соединение не будет установлено." Проверю потом, когда получу рабочий конфиг. Кстати отличная статья впервые за три дня которая растолковывает что к чему на начальном уровне.

 

Edited by pdn_mail
Posted

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

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)

Posted

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

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

Posted
10 минут назад, pdn_mail сказал:

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

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

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

Posted

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

Posted
35 минут назад, pdn_mail сказал:

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

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

Posted

PPTP  признаётся менее надёжным, вот и полез в IPSec. Надо теперь как-то подумать о надёжности.

Posted

Тогда если вы готовы поставить 2.09 на Giga II, то добро пожаловать сюда:

Из вариантов на 2.06 у вас только PPTP.

Posted (edited)

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

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

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

Edited by pdn_mail
  • 1 year later...
Posted

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

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

[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

Posted
В 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 хоть и присутствует, но содержит много недоработок.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

This site uses cookies. By clicking "I accept" or continuing to browse the site, you authorize their use in accordance with the Privacy Policy.