Jump to content
Le ecureuil

Все о туннелях IPIP, GRE и EoIP

580 posts in this topic

Начиная с прошивки 2.08.A.10.0-0 появилась возможность создавать туннели EoIP, GRE, IPIP как в простом виде, так и в сочетании с IPsec.

GRE и IPIP-туннели - это туннели уровня L3, на которых видны IP-адреса обоих сторон. Они представляются в системе в виде интерфейсов GreX и IPIPX, и через них можно прокидывать маршрутизацию (в том числе и default route) точно также, как и через любые другие интерфейсы. Плюс ко всему у них также есть security level. Туннели GRE совместимы со всеми Zyxel ZyWall, Mikrotik, а также Linux-роутерами. В теории должно работать вообще со всем оборудованием, которое умеет GRE, в том числе и Cisco, Juniper, etc. Компоненты называются соответственно gre и ipip.

EoIP-туннель - это туннель уровня L2, потому обмен через него идет на уровне Ethernet-кадров. При этом видны все mac-адреса, и можно объединить две локальные сети на уровне L2 через Интернет при помощи этого типа туннеля. На нем кроме IP можно гонять любой трафик, в том числе и ARP, DHCP, PPPoE, IPv6, etc. По умолчанию в туннеле при смене security level на private/protected будет работать сканирование подсети посредством ARP. Туннели EoIP разработаны Mikrotik, потому присутствует совместимость с ними, а также с Linux-роутерами, которые умеют EoIP. Компонент называется eoip.

Важно понимать, что сами по себе EoIP, GRE и IPIP-туннели являются connectionless, то есть невозможно понять находится ли в работоспособном состоянии туннель или нет. Мы можем только настроить обе стороны и после этого проверить передачу.

Плюс ко всему эти туннели в чистом виде никак не проходят через NAT, поэтому сеть между конечными точками для этих туннелей должна обеспечивать прямую связность без трансляции адресов.

GRE, IPIP и EoIP-туннели работают непосредственно поверх IPv4-протокола, EoIP и GRE используют номер IP-протокола 47, IPIP использует номер IP-протокола 4.

Настройка GRE/IPIP туннеля очень проста:

(config)> interface IPIP0
(config-if)> tunnel destination router1.example.com
(config-if)> ip address 192.168.100.1 255.255.255.0
(config-if)> security-level private
(config-if)> up

На другом конце туннеля задаются "зеркальные" настройки:

(config)> interface IPIP0
(config-if)> tunnel destination 8.6.5.4
(config-if)> ip address 192.168.100.2 255.255.255.0
(config-if)> security-level private
(config-if)> up

После этого можно попробовать пропинговать с любой из сторон адрес удаленной стороны в туннеле (это будет подсеть 192.168.100.0/24) для проверки работоспособности туннеля.

Стоит обратить внимание, что в качестве destination можно указать как доменное имя (через Cloud-режим в KeenDNS работать _НЕ_ будет), так и IP-адрес удаленной стороны (WAN-интерфейса устройства).

Для GRE имя интерфейса будет Gre0.

В случае с EoIP настройки абсолютно те же, кроме двух моментов:

 - можно задать mac-адрес интерфейса.

 - необходимо задать EoIP tunnel ID, идентификатор туннеля (число в диапазоне от 1 до 65535), причем на обоих концах он должен совпадать. Команды будут выглядеть так:

(config)> interface EoIP0
(config-if)> tunnel destination router1.example.com
(config-if)> tunnel eoip id 1500
(config-if)> ip address 192.168.100.1 255.255.255.0
(config-if)> security-level private
(config-if)> up

Другой конец туннеля:

(config)> interface EoIP0
(config-if)> tunnel destination 8.6.5.4
(config-if)> tunnel eoip id 1500
(config-if)> ip address 192.168.100.2 255.255.255.0
(config-if)> security-level private
(config-if)> up

После этого все должно работать.

Для туннелей MTU интерфейса автоматически вычисляется на основе интерфейса, через который будет проходить трафик, но также его можно и задать руками через команду interface ip mtu.

Более того, L2-интерфейс EoIP можно засунуть в Bridge для объединения локальных сетей. Для этого на обоих сторонах нужно настроить EoIP-интерфейс без IP-адреса, и затем включить в Bridge Home:

(config)> interface Home
(config-if)> include EoIP0

после этого можно пытаться связаться с хостом из одной домашней сети с хостом из другой домашней сети.

 

 

В случае установки компонента ipsec появляется возможность защищать эти туннели при помощи IPsec, причем как в автоматическом, так и в полностью ручном режиме. Ручной режим здесь описан не будет, поскольку продвинутые юзеры сами всегда могут сперва настроить IPsec с правильным режимом, а затем поверх IPsec поднять туннель. В случае автоматической настройки решается сразу несколько проблем ручного режима:

 - правильно выставляется MTU

 - соединение становится connection-oriented, и нужно выбирать, кто из концов туннеля становится клиентом, а кто сервером

 - автоматически решается проблема с проходом через NAT, поскольку используется IPsec NAT Traversal, при котором весь туннельный трафик превращается в поток UDP на порт 500/4500

 - шифрование и проверка целостности данных

Компонент IPsec добавляет следующие настройки к туннелям:

interface ipsec preshared-key <key> - PSK для шифрования

interface ipsec encryption-level <level> - уровень шифрования, по умолчанию задан таким, чтобы охватывал максимально большое число устройств и ускорялся аппаратно. Можно не менять.

Поскольку IPsec разграничивает клиента и сервер, то теперь для настройки клиента (инициатора, той стороны, которая будет пытаться установить соединение) необходимо использовать команду interface tunnel destination, а для включения режима сервера (той стороны, которая будет отвечать на попытки установления соединения) необходимо использовать команду interface tunnel source.

Пример настройки EoIP туннеля с IPsec, где сторона с WAN-адресом 8.6.5.4 является сервером:

Сервер:

(config)> interface EoIP0
(config-if)> tunnel source ISP
(config-if)> tunnel eoip id 1500
(config-if)> ipsec preshared-key mytestingkey
(config-if)> ip address 192.168.100.1 255.255.255.0
(config-if)> security-level private
(config-if)> up

Клиент:

(config)> interface EoIP0
(config-if)> tunnel destination 8.6.5.4
(config-if)> tunnel eoip id 1500
(config-if)> ipsec preshared-key mytestingkey
(config-if)> ip address 192.168.100.2 255.255.255.0
(config-if)> security-level private
(config-if)> up

Во всех случаях важно, чтобы IPsec PSK совпадал на обоих концах соединения.

При этом в команде interface tunnel source можно указать как интерфейс-источник, так и IP-адрес, на котором будет "висеть" сервер. Однако предпочтение отдается интерфейсу, поскольку в данном случае вся перенастройка при смене адреса и прочих событиях будет происходить автоматически.

Также можно указать interface tunnel source auto, для автоматического переключения сервера при смене WAN-интерфейса.

 

 

Известные ограничения:

- туннели на базе EoIP/IPsec и GRE/IPsec принципиально несовместимы с PPTP-подключениями из-за использования одного и того же протокола GRE. В этом случае остается использовать всего лишь один доступный вариант: IPIP/IPsec.

Важно:

- не забывайте про isolate-private: 

 

 

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

 

  • Thanks 11

Share this post


Link to post
Share on other sites
2 часа назад, Le ecureuil сказал:

Поскольку IPsec разграничивает клиента и сервер, то теперь для настройки клиента (инициатора, той стороны, которая будет пытаться установить соединение) необходимо использовать команду interface tunnel destination

 

2 часа назад, Le ecureuil сказал:

Клиент:


(config)> interface EoIP0
(config-if)> tunnel source ISP

м.б., путаю, но в примере, возможно, перепутаны клиент и сервер

  • Thanks 1

Share this post


Link to post
Share on other sites

- можно разъяснить подробнее weak/normal/strong, какие это proposals?

- насколько я понимаю, чтобы ходить через другой роутер, надо на "сервере" прописать, условно "ip nat IPIP0", а на другом просто маршруты, либо задать ip global, и будет работать в том числе с логикой резервирования?

 

- через EoIP DHCP-трафик ходит, или фильтруется? Можно ли это поведение настроить? Пример желаемой реализации я уже описывал - внутренние IP у роутеров 192.168.0.1/24 (DHCP на свои порты 2-100, def .1) и 192.168.0.101/24 (DHCP на свои порты 102-200, def .101), каждый сегмент в интернет ходит через свой роутер (с возможностью ходить по маршрутам через другой), но есть прозрачная сеть.

Share this post


Link to post
Share on other sites
1 час назад, IgaX сказал:

 

м.б., путаю, но в примере, возможно, перепутаны клиент и сервер

Ога, поправил.

  • Thanks 1

Share this post


Link to post
Share on other sites
1 час назад, KorDen сказал:

- можно разъяснить подробнее weak/normal/strong, какие это proposals?

Насчет proposals примерно вот так:

IPSECURE_IKE_MEDIUM_(
    "aes256-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536,"
    "aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024");
IPSECURE_SA_MEDIUM_(
    "aes128-sha1,aes256-sha1,3des-sha1,"
    "aes256-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536,"
    "aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024");
IPSECURE_SA_MEDIUM_3DES_(
    "3des-sha1,aes256-sha1,aes128-sha1,"
    "aes256-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536,"
    "aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024");
IPSECURE_SA_MEDIUM_PFS_(
    "aes128-sha1-modp1024,aes128-sha1,aes256-sha1,3des-sha1,"
    "aes256-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536,"
    "aes256-sha1-modp1024,3des-sha1-modp1024");
IPSECURE_SA_MEDIUM_3DES_PFS_(
    "3des-sha1-modp1024,3des-sha1,aes256-sha1,aes128-sha1,"
    "aes256-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536,"
    "aes256-sha1-modp1024,aes128-sha1-modp1024");

IPSECURE_IKE_LOW_(
    "aes128-sha1-modp1024,3des-sha1-modp1024,des-sha1-modp1024,"
    "aes128-sha1-modp768,3des-sha1-modp768,des-sha1-modp768,"
    "aes128-md5-modp1024,3des-md5-modp1024,des-md5-modp1024,"
    "aes128-md5-modp768,3des-md5-modp768,des-md5-modp768");
IPSECURE_SA_LOW_(
    "des-md5,aes128-sha1,3des-sha1,des-sha1,aes128-md5,3des-md5,"
    "aes128-sha1-modp1024,3des-sha1-modp1024,des-sha1-modp1024,"
    "aes128-sha1-modp768,3des-sha1-modp768,des-sha1-modp768,"
    "aes128-md5-modp1024,3des-md5-modp1024,des-md5-modp1024,"
    "aes128-md5-modp768,3des-md5-modp768,des-md5-modp768");
IPSECURE_SA_LOW_PFS_(
    "des-md5-modp1024,aes128-sha1,3des-sha1,des-sha1,aes128-md5,3des-md5,"
    "aes128-sha1-modp1024,3des-sha1-modp1024,des-sha1-modp1024,"
    "aes128-sha1-modp768,3des-sha1-modp768,des-sha1-modp768,"
    "aes128-md5-modp1024,3des-md5-modp1024,"
    "aes128-md5-modp768,3des-md5-modp768,des-md5-modp768");

IPSECURE_IKE_STRONG_(
    "aes256-sha1-modp2048,aes128-sha1-modp2048,"
    "aes256-sha1-modp1536,aes128-sha1-modp1536");
IPSECURE_SA_STRONG_(
    "aes256-sha1-modp1536,"
    "aes256-sha1-modp2048,aes128-sha1-modp2048,"
    "aes128-sha1-modp1536");

Поскольку используется IKEv1, то клиент отсылает только первый proposal из списка, а сервер сравнивает proposal из запроса со списоком и принимает любой подходящий.

Цитата

- насколько я понимаю, чтобы ходить через другой роутер, надо на "сервере" прописать, условно "ip nat IPIP0", а на другом просто маршруты, либо задать ip global, и будет работать в том числе с логикой резервирования?

Примерно так, только учтите, что туннель всегда будет в состоянии up, если он не работает поверх IPsec, и потому резервирование с ним будет работать странно, хотя зависит от числа в ip global.

Цитата

- через EoIP DHCP-трафик ходит, или фильтруется? Можно ли это поведение настроить? Пример желаемой реализации я уже описывал - внутренние IP у роутеров 192.168.0.1/24 (DHCP на свои порты 2-100, def .1) и 192.168.0.101/24 (DHCP на свои порты 102-200, def .101), каждый сегмент в интернет ходит через свой роутер (с возможностью ходить по маршрутам через другой), но есть прозрачная сеть.

DHCP проходит насквозь через EoIP, как и любой другой трафик L2. Для фильтрования используйте ebtables из entware или что-то в этом духе, модули ядра все присутствуют в компонентах.

  • Thanks 1

Share this post


Link to post
Share on other sites

@Le ecureuil, а будет манул на счет маршрутов, помните вы писали к моему посту?

 

Share this post


Link to post
Share on other sites
18 минут назад, enpa сказал:

@Le ecureuil, а будет манул на счет маршрутов, помните вы писали к моему посту?

 

Насчет маршрутов придумывайте сами или подсматривайте примеры в БЗ для PPTP и адаптируйте. Все механизмы теперь для этого есть. Я все же не технический писатель, и не техподдержка.

  • Thanks 1

Share this post


Link to post
Share on other sites

@Le ecureuil

Попытался поднять IPIP over IPSec между 1й и 2й ультрами

Лог с ошибкой:

Nov 08 22:30:12ndm
IpSec::Configurator: reconnecting crypto map "IPIP0".
Nov 08 22:30:14ndm
IpSec::Configurator: start shutting down crypto map "IPIP0" task.
Nov 08 22:30:14ipsec
12[CFG] received stroke: unroute 'IPIP0' 
Nov 08 22:30:14ipsec
05[CFG] received stroke: terminate 'IPIP0{*}' 
Nov 08 22:30:14ipsec
05[CFG] no CHILD_SA named 'IPIP0' found 
Nov 08 22:30:14ipsec
14[CFG] received stroke: terminate 'IPIP0[*]' 
Nov 08 22:30:14ipsec
14[CFG] no IKE_SA named 'IPIP0' found 
Nov 08 22:30:14ndm
IpSec::Configurator: shutting down crypto map "IPIP0" task done.
Nov 08 22:30:15ndm
IpSec::Configurator: start initiating crypto map "IPIP0" task.
Nov 08 22:30:15ipsec
15[CFG] received stroke: initiate 'IPIP0' 
Nov 08 22:30:15ndm
IpSec::Configurator: initiating crypto map "IPIP0" task done.
Nov 08 22:30:15ipsec
09[IKE] sending XAuth vendor ID 
Nov 08 22:30:15ipsec
09[IKE] sending DPD vendor ID 
Nov 08 22:30:15ipsec
09[IKE] sending Cisco Unity vendor ID 
Nov 08 22:30:15ipsec
09[IKE] sending NAT-T (RFC 3947) vendor ID 
Nov 08 22:30:15ipsec
09[IKE] sending draft-ietf-ipsec-nat-t-ike-02\n vendor ID 
Nov 08 22:30:15ipsec
09[IKE] initiating Main Mode IKE_SA IPIP0[63] to 176.14.124.109 
Nov 08 22:30:15ipsec
11[IKE] received DPD vendor ID 
Nov 08 22:30:15ipsec
11[IKE] received NAT-T (RFC 3947) vendor ID 
Nov 08 22:30:15ipsec
11[CFG] received proposals: IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/# 
Nov 08 22:30:15ipsec
11[CFG] configured proposals: IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/# 
Nov 08 22:30:15ipsec
11[CFG] selected proposal: IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/# 
Nov 08 22:30:16upnp
sendto(udp_notify=7, 192.168.1.1): No such device
Nov 08 22:30:16upnp
Core::Syslog: last message repeated 10 times.
Nov 08 22:30:17ipsec
06[IKE] received INVALID_KE_PAYLOAD error notify 
Nov 08 22:30:17ndm
IpSec::Configurator: remote peer of crypto map "IPIP0" returned invalid key notification.
Nov 08 22:30:17ndm
IpSec::Configurator: fallback peer is not defined for crypto map "IPIP0", retry.
Nov 08 22:30:17ndm
IpSec::Configurator: schedule reconnect for crypto map "IPIP0".
Nov 08 22:30:17ndm
Network::Interface::SecureIPTunnel: "IPIP0": IPsec layer is down, shutdown tunnel layer.
Nov 08 22:30:17ndm
Network::Interface::SecureIPTunnel: "IPIP0": secured tunnel is down.

 

Share this post


Link to post
Share on other sites

@Le ecureuil И вдогонку, если остановить этот интерфейс, (сделать Interface IPIP0 down) то связанный с ним IPSec продолжает попытки подключиться.

UPD Я так понимаю нужно сделать Interface IPIP0 no connect чтоб перестало коннектиться?

Edited by r13
  • Thanks 1

Share this post


Link to post
Share on other sites
14 часа назад, r13 сказал:

@Le ecureuil

Попытался поднять IPIP over IPSec между 1й и 2й ультрами

Лог с ошибкой:


Nov 08 22:30:12ndm
IpSec::Configurator: reconnecting crypto map "IPIP0".
Nov 08 22:30:14ndm
IpSec::Configurator: start shutting down crypto map "IPIP0" task.
Nov 08 22:30:14ipsec
12[CFG] received stroke: unroute 'IPIP0' 
Nov 08 22:30:14ipsec
05[CFG] received stroke: terminate 'IPIP0{*}' 
Nov 08 22:30:14ipsec
05[CFG] no CHILD_SA named 'IPIP0' found 
Nov 08 22:30:14ipsec
14[CFG] received stroke: terminate 'IPIP0[*]' 
Nov 08 22:30:14ipsec
14[CFG] no IKE_SA named 'IPIP0' found 
Nov 08 22:30:14ndm
IpSec::Configurator: shutting down crypto map "IPIP0" task done.
Nov 08 22:30:15ndm
IpSec::Configurator: start initiating crypto map "IPIP0" task.
Nov 08 22:30:15ipsec
15[CFG] received stroke: initiate 'IPIP0' 
Nov 08 22:30:15ndm
IpSec::Configurator: initiating crypto map "IPIP0" task done.
Nov 08 22:30:15ipsec
09[IKE] sending XAuth vendor ID 
Nov 08 22:30:15ipsec
09[IKE] sending DPD vendor ID 
Nov 08 22:30:15ipsec
09[IKE] sending Cisco Unity vendor ID 
Nov 08 22:30:15ipsec
09[IKE] sending NAT-T (RFC 3947) vendor ID 
Nov 08 22:30:15ipsec
09[IKE] sending draft-ietf-ipsec-nat-t-ike-02\n vendor ID 
Nov 08 22:30:15ipsec
09[IKE] initiating Main Mode IKE_SA IPIP0[63] to 176.14.124.109 
Nov 08 22:30:15ipsec
11[IKE] received DPD vendor ID 
Nov 08 22:30:15ipsec
11[IKE] received NAT-T (RFC 3947) vendor ID 
Nov 08 22:30:15ipsec
11[CFG] received proposals: IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/# 
Nov 08 22:30:15ipsec
11[CFG] configured proposals: IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/# 
Nov 08 22:30:15ipsec
11[CFG] selected proposal: IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/# 
Nov 08 22:30:16upnp
sendto(udp_notify=7, 192.168.1.1): No such device
Nov 08 22:30:16upnp
Core::Syslog: last message repeated 10 times.
Nov 08 22:30:17ipsec
06[IKE] received INVALID_KE_PAYLOAD error notify 
Nov 08 22:30:17ndm
IpSec::Configurator: remote peer of crypto map "IPIP0" returned invalid key notification.
Nov 08 22:30:17ndm
IpSec::Configurator: fallback peer is not defined for crypto map "IPIP0", retry.
Nov 08 22:30:17ndm
IpSec::Configurator: schedule reconnect for crypto map "IPIP0".
Nov 08 22:30:17ndm
Network::Interface::SecureIPTunnel: "IPIP0": IPsec layer is down, shutdown tunnel layer.
Nov 08 22:30:17ndm
Network::Interface::SecureIPTunnel: "IPIP0": secured tunnel is down.

 

Судя по логу у вас на разных концах задан разный PSK, проверьте внимательно (а лучше вбейте заново).

Share this post


Link to post
Share on other sites
13 часа назад, r13 сказал:

@Le ecureuil И вдогонку, если остановить этот интерфейс, (сделать Interface IPIP0 down) то связанный с ним IPSec продолжает попытки подключиться.

Ок, принято в работу.

Share this post


Link to post
Share on other sites

@Le ecureuilПодскажите пожалуйста, в логах постоянно лезет:

 

Nov 09 18:43:07ndm

Network::Interface::EoIP: "EoIP0": tunnel is down: retry to resolve remote endpoint.

Nov 09 18:43:07ndm

Network::Interface::Tunnel: "EoIP0": resolved destination 31.41.245.221.

Nov 09 18:43:07ndm

Network::Interface::Tunnel: "EoIP0": resolved source 10.77.140.133.

 

что-то не правильно прописал? IPsec включен и коннект есть, с IPsec клиента на IPsec сервер.

 

Edited by enpa

Share this post


Link to post
Share on other sites
33 минуты назад, enpa сказал:

@Le ecureuilПодскажите пожалуйста, в логах постоянно лезет:

 

Nov 09 18:43:07ndm

Network::Interface::EoIP: "EoIP0": tunnel is down: retry to resolve remote endpoint.

Nov 09 18:43:07ndm

Network::Interface::Tunnel: "EoIP0": resolved destination 31.41.245.221.

Nov 09 18:43:07ndm

Network::Interface::Tunnel: "EoIP0": resolved source 10.77.140.133.

 

что-то не правильно прописал? IPsec включен и коннект есть, с IPsec клиента на IPsec сервер.

 

self-test с обоих сторон где?

Share this post


Link to post
Share on other sites

@Le ecureuil

Пока удалось поднять GRE over IPsec и IPIP over IPsec но чисто номинально, по логам все ок поднялось, но трафик не ходит.

Попутно вылезла несовместимость GRE туннеля и штатного PPTP клиента:

создал туннель, клиент отвалился и покругу пытается безуспешно подключиться. Грохнул туннель и клиент сразу же подключился.

селф тест в следующем посте.

 

UPD пинги из под ентвари до  удаленного роутера работают, а пинги с компьютера не идут, не понятно....

Edited by r13

Share this post


Link to post
Share on other sites

@Le ecureuil не успел вчера скинуть. Заметил, что после того, как прописываю:

Сервер:

interface EoIP0
tunnel source ISP
tunnel eoip id 1500
ipsec preshared-key mytestingkey
ip address 192.168.100.1 255.255.255.0
security-level private
up

Со стороны клиента прописываю:

interface EoIP0
tunnel destination 31.41.245.221 - ip сервера
tunnel eoip id 1500
ipsec preshared-key mytestingkey
ip address 192.168.100.2 255.255.255.0
security-level private
up

 

PPTP VPN , как основное подключение провайдера, перестает коннектиться. Скидываю селф ниже.

Edited by enpa

Share this post


Link to post
Share on other sites
В 11/8/2016 в 23:52, r13 сказал:

UPD Я так понимаю нужно сделать Interface IPIP0 no connect чтоб перестало коннектиться?

Нет, должно работать с просто "down". Команда "connect" есть только у интерфейсов на базе PPP.

Это баг, будем чинить.

  • Thanks 1

Share this post


Link to post
Share on other sites

@Le ecureuil В дальнейшем планируете реализовать для клиент серверного режима указывать не конкретный интерфейс а использовать интерфейс текущего подключения к Интернет?

что-то вроде tunnel source default 

что бы работало в том числе в схеме с резервированием интернета

  • Thanks 1

Share this post


Link to post
Share on other sites
5 часов назад, r13 сказал:

@Le ecureuil В дальнейшем планируете реализовать для клиент серверного режима указывать не конкретный интерфейс а использовать интерфейс текущего подключения к Интернет?

что-то вроде tunnel source default 

что бы работало в том числе в схеме с резервированием интернета

Да, когда все более крупные проблемы будут решены - возможно так и сделаем.

  • Thanks 1

Share this post


Link to post
Share on other sites

@Le ecureuil Если на момент запуска не возможно отресолвить dns имя endpoint туннеля (доступ в интернет еще не поднялся после перезагрузки) то туннель IPSec больше не поднимается.

down/ up на интерфейсе не помогает,

помогает пересоздание endpoint адреса

селфтест ниже.

Share this post


Link to post
Share on other sites
В 11/8/2016 в 23:52, r13 сказал:

@Le ecureuil И вдогонку, если остановить этот интерфейс, (сделать Interface IPIP0 down) то связанный с ним IPSec продолжает попытки подключиться.

UPD Я так понимаю нужно сделать Interface IPIP0 no connect чтоб перестало коннектиться?

Реакция на команды interface up/down поправлена, войдет в ближайший релиз.

  • Thanks 1

Share this post


Link to post
Share on other sites

@enpa, @r13 - туннели на базе EoIP/IPsec и GRE/IPsec концептуально несовместимы с PPTP-подключениями из-за того, что PPTP тоже использует протокол GRE. У вас есть всего лишь один вариант - использовать IPIP/IPsec.

Занесу инфу в шапку.

 

  • Thanks 1

Share this post


Link to post
Share on other sites

@Le ecureuil эх, жаль ;( тогда попробуем IPIP0.

у меня на одном роутере серый айпи, IPsec - клиент который, вопрос такой, тут указано

Настройка GRE/IPIP туннеля очень проста:

(config)> interface IPIP0

(config-if)> tunnel destination router1.example.com

(config-if)> ip address 192.168.100.1 255.255.255.0

(config-if)> security-level private (config-if)> up

(config-if)> tunnel destination router1.example.com  --- тут указываем айпи IPsec клиента? Правильно? 

 

и можно добавить к этому туннелю команду (config-if)> tunnel source ISP? чтобы сразу использовался реальный айпи ISP, очень удобно было бы.

Edited by enpa

Share this post


Link to post
Share on other sites
10 минут назад, enpa сказал:

@Le ecureuil эх, жаль ;( тогда попробуем IPIP0.

у меня на одном роутере серый айпи, IPsec - клиент который, вопрос такой, тут указано

Настройка GRE/IPIP туннеля очень проста:

(config)> interface IPIP0

(config-if)> tunnel destination router1.example.com

(config-if)> ip address 192.168.100.1 255.255.255.0

(config-if)> security-level private (config-if)> up

(config-if)> tunnel destination router1.example.com  --- тут указываем айпи IPsec клиента? Правильно? 

 

и можно добавить к этому туннелю команду (config-if)> tunnel source ISP? чтобы сразу использовался реальный айпи ISP, очень удобно было бы.

Нет, IP-адрес или FQDN сервера (он должен быть глобальным, или это должен быть проброшенные порты 500/4500 UDP на этом адресе до сервера).

Локальный адрес вычислится автоматом на основе роутинга, так что tunnel source тут лишний. Плюс IPsec сам создаст все настройки для прохода сквозь NAT до реального адреса сервера, ему не нужно в этом помогать.

  • Thanks 1

Share this post


Link to post
Share on other sites
13 часа назад, r13 сказал:

@Le ecureuil Если на момент запуска не возможно отресолвить dns имя endpoint туннеля (доступ в интернет еще не поднялся после перезагрузки) то туннель IPSec больше не поднимается.

down/ up на интерфейсе не помогает,

помогает пересоздание endpoint адреса

селфтест ниже.

Спасибо за репорт, исправлено. Войдет в ближайший релиз.

  • Thanks 1

Share this post


Link to post
Share on other sites

@Le ecureuil сейчас прописал:

 

interface IPIP0
tunnel destination 31.41.245.221
ip address 192.168.100.1 255.255.255.0
security-level private
up


interface IPIP0
tunnel destination 31.41.245.221
ip address 192.168.100.2 255.255.255.0
security-level private
up

 

как и в предыдущий раз, отвалился PPTP VPN и более не подключается. 

селф в облаке

 

 

Edited by enpa

Share this post


Link to post
Share on other sites
1 час назад, enpa сказал:

@Le ecureuil сейчас прописал:

 

interface IPIP0
tunnel destination 31.41.245.221
ip address 192.168.100.1 255.255.255.0
security-level private
up


interface IPIP0
tunnel destination 31.41.245.221
ip address 192.168.100.2 255.255.255.0
security-level private
up

 

как и в предыдущий раз, отвалился PPTP VPN и более не подключается. 

селф в облаке

 

 

Ага, затесалась еще одна мелочевка.

Поправлено, будет как обычно в сегодняшней сборке. :)

  • Thanks 1

Share this post


Link to post
Share on other sites
В 11/9/2016 в 18:44, enpa сказал:

@Le ecureuilПодскажите пожалуйста, в логах постоянно лезет:

 

Nov 09 18:43:07ndm

Network::Interface::EoIP: "EoIP0": tunnel is down: retry to resolve remote endpoint.

Nov 09 18:43:07ndm

Network::Interface::Tunnel: "EoIP0": resolved destination 31.41.245.221.

Nov 09 18:43:07ndm

Network::Interface::Tunnel: "EoIP0": resolved source 10.77.140.133.

Исправлено, будет в следующей сборке.

  • Thanks 1

Share this post


Link to post
Share on other sites

Поднял IPIPoverIPsec между Ultra 2 - Giga 2 на v2.08(AAUX.0)A11 (до этого был IPsec 2.08-2.06) с настройками из шапки..

Долго гадал, почему трафик от компов не ходит, потом, увидев что пакеты даже не уходят с home на ipip0, вспомнил про isolate-private - надо бы напомнить о нем в шапке, IMO.

Роутинг в обе стороны после ip nat ipip0 работает корректно [вроде бы]..

Теперь вопрос - как запретить трафик guest->home / guest->ipip, но разрешить home-ipip? В простом случае можно поставить security-level protected для Guest, но если надо к одному Ipip доступ дать, а к другому не давать?

 

Еще вопрос до кучи - туннели идут в лимит двух IPsec или как?

Edited by KorDen
  • Thanks 1

Share this post


Link to post
Share on other sites
34 минуты назад, KorDen сказал:

Теперь вопрос - как запретить трафик guest->home / guest->ipip, но разрешить home-ipip? В простом случае можно поставить security-level protected для Guest, но если надо к одному Ipip доступ дать, а к другому не давать?

ACL / Межсетевой экран

34 минуты назад, KorDen сказал:

Еще вопрос до кучи - туннели идут в лимит двух IPsec или как?

Для туннелей нет ограничения.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×