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

[Le ecureuil]

Начиная с прошивки 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: 

 

Для тех, кто будет включать EoIP в Bridge:

Правильно делать в таком порядке - выставить вручную MTU 1500 на EoIP, и забриджевать его. Тогда все будет работать нормально, в том числе и фрагментация. Иначе на EoIP выставится MTU < 1500 и будут проблемы.

 

Команды eoip_allow_fragment на версиях 3.x нет, она устарела. Фрагментация включается автоматически.

 

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

 

[IgaX]

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

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

 

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

Клиент:

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

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

[KorDen]

- можно разъяснить подробнее 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), каждый сегмент в интернет ходит через свой роутер (с возможностью ходить по маршрутам через другой), но есть прозрачная сеть.

[Le ecureuil]

1 час назад, IgaX сказал:

 

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

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

[Le ecureuil]

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 или что-то в этом духе, модули ядра все присутствуют в компонентах.

[hellonow]

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

 

[Le ecureuil]

18 минут назад, enpa сказал:

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

 

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

[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.

 

[r13]

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

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

Edited November 9, 2016 by r13

[Le ecureuil]

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, проверьте внимательно (а лучше вбейте заново).

[Le ecureuil]

13 часа назад, r13 сказал:

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

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

[hellonow]

@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 November 9, 2016 by enpa

[Le ecureuil]

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 с обоих сторон где?

[r13]

@Le ecureuil

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

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

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

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

 

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

Edited November 9, 2016 by r13

[hellonow]

@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 November 10, 2016 by enpa

[Le ecureuil]

В 11/8/2016 в 23:52, r13 сказал:

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

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

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

[r13]

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

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

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

[Le ecureuil]

5 часов назад, r13 сказал:

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

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

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

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

[r13]

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

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

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

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

[Le ecureuil]

В 11/8/2016 в 23:52, r13 сказал:

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

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

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

[hellonow]

@Le ecureuil а по моему посту есть какая инфа? 

[Le ecureuil]

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

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

 

[hellonow]

@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 November 11, 2016 by enpa

[Le ecureuil]

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 до реального адреса сервера, ему не нужно в этом помогать.

[Le ecureuil]

13 часа назад, r13 сказал:

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

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

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

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

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

[hellonow]

@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 November 11, 2016 by enpa

[Le ecureuil]

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 и более не подключается. 

селф в облаке

 

 

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

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

[Le ecureuil]

В 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.

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

[KorDen]

Поднял 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 November 12, 2016 by KorDen

[Le ecureuil]

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

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

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

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

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

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