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

r13 · September 5, 2017

4 минуты назад, utya сказал:

@r13может вы подскажите, eoip настроен пинги между хостами ходят. Но на внутренний сервер зайти не могу. Там и там no isolate-private, ipsec нет.

Что есть внутренний сервер? Есть ли у этого сервера свой firewall?

Расписывайте подробнее что где и как...

Edited September 5, 2017 by r13

utya · September 5, 2017

4 минуты назад, r13 сказал:

Что есть внутренний? сервер? Есть ли у этого сервера свой firewall?

Расписывайте подробнее что где и как...

Вот селф тест если чё.

К роутеру DSL пригнал сеть giga. Кругом единая сеть и все хосты пингуются. Есть openhab c адресом 192.168.234.136, из сети giga зайти на на него могу, а с "сети" dsl только пинги долетают.

self-test_giga3.txt

self-test_DSL (2).txt

Edited September 5, 2017 by utya

r13 · 09/05/2017 01:35 PM

@utya Если сервер "пингуется" из сети dsl то смотрите настройки самого сервера. почему он на пинги отвечает, а по другим протоколам нет.

Sergey Guydya · 09/05/2017 01:36 PM

от блин , понятия не имею откуда появилась эта глупая зеркальность, я честно честно очищал интерфейс перед тем как поменять местами клиент и сервер. Спасибо вам огромное, удалил лишнее, все взлетело на ура, добавил маршрут, все работае. Еще раз спасибо

utya · 09/05/2017 01:42 PM

@r13 ок буду разбираться с сервером, поскольку и по ssh могу на него зайти. Чёто косяк с http, все сервера не открываются. Ещё вопрос по gre, чтобы мультикат ходил, никаких настроек в acl не надо, кроме no isolate-private и security-level private?

r13 · September 5, 2017

15 минут назад, utya сказал:

@r13 ок буду разбираться с сервером, поскольку и по ssh могу на него зайти. Чёто косяк с http, все сервера не открываются. Ещё вопрос по gre, чтобы мультикат ходил, никаких настроек в acl не надо, кроме no isolate-private и security-level private?

куда уж больше acl и так уже все разрешено (no isolate-private, security-level private)

Edited September 5, 2017 by r13

utya · 09/05/2017 02:00 PM

2 минуты назад, r13 сказал:

куда уж больше acl и так уже все разрешено (no isolate-private, security-level private)

вот и я голову ломаю, не могу понять чё не ходит мультикаст.

Le ecureuil · 09/06/2017 09:24 AM

Мультикаст через GRE никогда не планировался и скорее всего работать не будет.

utya · 09/06/2017 10:08 AM

24 минуты назад, Le ecureuil сказал:

Мультикаст через GRE никогда не планировался и скорее всего работать не будет.

Понял, тоесть если мультиаст то только EoIP. А можете подсказать почему внутренние сервисы не работают, я уже думал может какие-то iptbles правила у меня на сервер настроены, но нет. доступ открыт всем, сервре пингуется, по ssh через раз могу зайти, но web не открывается. Селф тест выкладывал выше. Такая ситуация наблюдается что в eoip, что в Gre.

dexter · 09/06/2017 10:16 AM

Смотрите в сторону MTU c обоих концов туннеля и уменьшайте значение. Я с этим боролся когда EoIP туннель в IPIP засовывал.

utya · 09/06/2017 10:22 AM

3 минуты назад, dexter сказал:

Смотрите в сторону MTU c обоих концов туннеля и уменьшайте значение. Я с этим боролся когда EoIP туннель в IPIP засовывал.

я понимаю что дело в mtu. Я прочёл все сообщения в ветке косательно mtu, что тока не пробовал, и фрагментацию включал, и выставлял одинаковые значения на обоих концах, и выставлял автомато, и ставил 1280. Единственно я не знаю, ка кпроверить поддеживает ли провайдер прохождение фрагментируемых "пакетов" Но хочется как-то научно подойти, может есть какае-то "методики", как это граматно настроить

dexter · 09/06/2017 10:27 AM

Еще сильнее уменьшите mtu пока пакеты не начнут ходить. А потом потихоньку увиливайте значение. Фрагментацию включите.

utya · 09/06/2017 10:38 AM

5 минут назад, dexter сказал:

Еще сильнее уменьшите mtu пока пакеты не начнут ходить. А потом потихоньку увиливайте значение. Фрагментацию включите.

ок, включаю фрагментацию, ставлю самое маленько значение mtu для eoip на обоих концах (начну с него) и повышаю пока не перестанет ходить

system set net.core.eoip_allow_fragment 1
interface EoIP ip mtu 1200

такая команда нужна?: ip tcp adjust-mss pmtu

dexter · 09/06/2017 10:42 AM

interface EoIP0
    mac address 0e:5b:ac:fd:d2:4b
    security-level private
    ip dhcp client dns-routes
    ip dhcp client name-servers
    ip tcp adjust-mss 1300
    tunnel destination 192.168.254.253
    tunnel eoip id 1500
    up
!
interface Bridge2
    rename L2-Vlan253
    inherit GigabitEthernet0/Vlan253
    include EoIP0
    security-level private
    ip address 192.168.253.254 255.255.255.0
    ip dhcp client dns-routes
    ip dhcp client name-servers
    ip tcp adjust-mss 1300
    up

Вот кусочек конфига. Возможно нужно ещё меньше mtu.

utya · 09/06/2017 10:45 AM

2 минуты назад, dexter сказал:


interface EoIP0
    mac address 0e:5b:ac:fd:d2:4b
    security-level private
    ip dhcp client dns-routes
    ip dhcp client name-servers
    ip tcp adjust-mss 1300
    tunnel destination 192.168.254.253
    tunnel eoip id 1500
    up
!
interface Bridge2
    rename L2-Vlan253
    inherit GigabitEthernet0/Vlan253
    include EoIP0
    security-level private
    ip address 192.168.253.254 255.255.255.0
    ip dhcp client dns-routes
    ip dhcp client name-servers
    ip tcp adjust-mss 1300
    up

Вот кусочек конфига. Возможно нужно ещё меньше mtu.

спасибо, сейчас попробую

utya · 09/06/2017 10:59 AM

@dexter
так можно или ip mtu удалить?

interface EoIP0
    mac address 9a:19:f0:cb:d1:44
    security-level private
    ip dhcp client dns-routes
    ip dhcp client name-servers
    ip mtu 1100
    ip tcp adjust-mss 1100
    tunnel destination xx.xxx.ru
    tunnel eoip id 1500
    up

arbayten · 09/06/2017 01:18 PM

45 минут назад, dexter сказал:

Смотрите в сторону MTU c обоих концов туннеля и уменьшайте значение

имхо, все же сюда могут зайти в т.ч. адекватные новички (если все это скоро не накроется), которым бы:

1) ip tcp adjust-mss 1300 .. +20 +20 -> 1340 -> т.е. для tcp only будет формироваться ip пакет макс.размером 1340 в отношении которого уже может применяться ip mtu;
2) этот пакет, видимо, завернется в eoip получив еще немного жира: т.к. бридж прозрачен, то без .1q -> добавляем 14 от 802.3 (т.к. eoip знает L2 на другой стороне), 8 от gre и еще 20 от ip (чтобы дойти до другого конца туннеля) .. т.е. набрали вес до 1340+14+8+20 = 1382;
3) и вот новый ip пакет в чистом виде eoip макс.размером 1382 путешествует по сетям и если по пути придется пройти интерфейс с mtu меньше чем 1382, то ... имеет смысл дополнительно обернуть в то, что может решать подобные проблемы;
4) предположим, пакет дошел до нужного конца, дальше по принципу луковицы: сняли верх (20 от ip), на проходной отдали 8 от gre, на L2 отдали 14, все, доехали и тут тоже может быть косяк с mtu на интерфейсе хоста (а дальше снова отдавать 20 и 20 и данные сегмента раскрылись).

если это не объяснять, то все бесполезно.

п.1 не учитывает пакеты вне tcp.

system set net.core.eoip_allow_fragment 1 - видимо фрагментирует и собирает ip пакеты на основе размера mtu интерфейса через который он (eoip) эти пакеты пропинывает.

utya · 09/06/2017 02:12 PM

51 минуту назад, arbayten сказал:

имхо, все же сюда могут зайти в т.ч. адекватные новички (если все это скоро не накроется), которым бы:

1) ip tcp adjust-mss 1300 .. +20 +20 -> 1340 -> т.е. для tcp only будет формироваться ip пакет макс.размером 1340 в отношении которого уже может применяться ip mtu;
2) этот пакет, видимо, завернется в eoip получив еще немного жира: т.к. бридж прозрачен, то без .1q -> добавляем 14 от 802.3 (т.к. eoip знает L2 на другой стороне), 8 от gre и еще 20 от ip (чтобы дойти до другого конца туннеля) .. т.е. набрали вес до 1340+14+8+20 = 1382;
3) и вот новый ip пакет в чистом виде eoip макс.размером 1382 путешествует по сетям и если по пути придется пройти интерфейс с mtu меньше чем 1382, то ... имеет смысл дополнительно обернуть в то, что может решать подобные проблемы;
4) предположим, пакет дошел до нужного конца, дальше по принципу луковицы: сняли верх (20 от ip), на проходной отдали 8 от gre, на L2 отдали 14, все, доехали и тут тоже может быть косяк с mtu на интерфейсе хоста (а дальше снова отдавать 20 и 20 и данные сегмента раскрылись).

если это не объяснять, то все бесполезно.

п.1 не учитывает пакеты вне tcp.

system set net.core.eoip_allow_fragment 1 - видимо фрагментирует и собирает ip пакеты на основе размера mtu интерфейса через который он (eoip) эти пакеты пропинывает.

ну я модель Osi немного знаю, но понятное дело что этого мало чтобы понимать всю глубину и правильность выставки mtu. Спасибо за пост, буду почитать матчасть. Ну а пока свернул все каналы, а то ничего не работает, невозможно работать.

Le ecureuil · 09/07/2017 03:08 PM

В 9/6/2017 в 16:18, arbayten сказал:

имхо, все же сюда могут зайти в т.ч. адекватные новички (если все это скоро не накроется), которым бы:

1) ip tcp adjust-mss 1300 .. +20 +20 -> 1340 -> т.е. для tcp only будет формироваться ip пакет макс.размером 1340 в отношении которого уже может применяться ip mtu;
2) этот пакет, видимо, завернется в eoip получив еще немного жира: т.к. бридж прозрачен, то без .1q -> добавляем 14 от 802.3 (т.к. eoip знает L2 на другой стороне), 8 от gre и еще 20 от ip (чтобы дойти до другого конца туннеля) .. т.е. набрали вес до 1340+14+8+20 = 1382;
3) и вот новый ip пакет в чистом виде eoip макс.размером 1382 путешествует по сетям и если по пути придется пройти интерфейс с mtu меньше чем 1382, то ... имеет смысл дополнительно обернуть в то, что может решать подобные проблемы;
4) предположим, пакет дошел до нужного конца, дальше по принципу луковицы: сняли верх (20 от ip), на проходной отдали 8 от gre, на L2 отдали 14, все, доехали и тут тоже может быть косяк с mtu на интерфейсе хоста (а дальше снова отдавать 20 и 20 и данные сегмента раскрылись).

если это не объяснять, то все бесполезно.

п.1 не учитывает пакеты вне tcp.

system set net.core.eoip_allow_fragment 1 - видимо фрагментирует и собирает ip пакеты на основе размера mtu интерфейса через который он (eoip) эти пакеты пропинывает.

allow fragment разрежет L2-фреймы, заходящие в EoIP-интерфейс (хоть пусть и 1500 байт будут) на подходящие, если path MTU ниже чем размер пакета + заголовки, а потом на приемнике их прозрачно соберет.

arbayten · 09/07/2017 05:10 PM

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

allow fragment разрежет L2-фреймы, заходящие в EoIP-интерфейс (хоть пусть и 1500 байт будут) на подходящие, если path MTU ниже чем размер пакета + заголовки, а потом на приемнике их прозрачно соберет.

т.е. все как обычно: например, клиент арпит ip получателя броадкастом, броадкаст проходит в т.ч. через туннель, получатель отвечает арпом в юникасте, арп-кэши обоих хостов подсети пополнились соответствующими записями, для них все едино; при стандартном mtu бриджа в 1500 на eoip заходит ethernet-кадр от клиента макс. размером в 1514, при allow fragment он бьется с учетом +8 +20 и pmtud ... на базе icmp с df (?) до другого конца туннеля и потенциальный затык если по пути black hole на блоке icmp ... как-то так? если на базе icmp с df ... то какое время действия pmtu через которое будет повторный icmp? если нет ответа на icmp, то идет дискард или все равно отправляем? если часть пакета потеряли, то дискардим весь пакет оставляя решение за протоколами более высокого уровня?

детали важны, чтобы люди понимали, где может быть проблема.

arbayten · 09/08/2017 08:55 AM

и еще немного: раз pmtud, видимо, включен по-умолчанию (а выключить чем-нибудь можно?) для tcp и udp ... скажем, на первом пристрелочном tcp-хэндшейке можно выяснить mtu хоста из mss и взять минимальный с обоих поинтов, но не pmtu - это пока рогом не упремся ... но чтобы мысль не потерять -> т.е. с платформы ip пакеты выходят с df ... м.б. добавить что-нибудь вроде interface ip clear-df <acl> и ставить set ip df 0, чтобы проблему с меньшим mtu на пути попробовали решать другие железки? (м.б. даже добавлять это в конфиг по-умолчанию при поднятии подобных туннелей "пользователем").

KorDen · September 11, 2017

Заметил такое на 2.11.A.1.0-1 при тестовой перезагрузке по питанию, не знаю, критично ли это, но кажется что system failed тут быть не должно.

вначале после установки времени peer didn't accept DH group MODP_1536, it requested MODP_2048 и remote peer of crypto map "IPIP0" returned invalid DH group for IPsec phase 2, дальше

[I] Sep 11 23:34:15 ndm: Network::Interface::SecureIPTunnel: "IPIP0": IPsec client layer is up, do start tunnel layer.
[C] Sep 11 23:34:15 ndm: Network::Interface::SecureIPTunnel: "IPIP0": system failed [0xcffd02be], unable to change tunnel: file exists.
[C] Sep 11 23:34:15 ndm: Network::Interface::SecureIPTunnel: "IPIP0": system failed [0xcffd00b1].
[I] Sep 11 23:34:15 ndm: Network::Interface::SecureIPTunnel: "IPIP0": secured tunnel is ready.

С той стороны strongSwan U5.3.5/K4.4.0-83-generic, если что... Self-test ниже

Edited September 11, 2017 by KorDen

utya · September 21, 2017

Я снова решил поднять eoip.
для mtu дописал

ip tcp adjust-mss 1300

и включил фрагментацию. Локальные сервера как не работали так и не работают, но если подключиться по vpn к однуму из роутеров которые соединены по eoip между собой то всё работает и хорошо открывается.

Дальше погуглил матчасть, где то вычитал что если бриджевать с локалкой то нужно mtu увеличить, но в нашем случае mtu для eoip выставляется автоматом по исходящему инету, поэтому этот вариант не работает. В итоге выставил ip mtu 1200 ну уж точно должно пролезть, но не работает ничего. (Пингуется но локальные ресурсы не работают) Ну куда ещё копать? Mtu 1000 не помогает, его же бесконечно меньше нельзя делать. я уже обновил прошивку, снёс всё к заводским настройкам.

interface EoIP0
    mac address de:bf:c3:2b:d5:5e
    security-level private
    ip dhcp client dns-routes
    ip dhcp client name-servers
    ip mtu 1200
    ip tcp adjust-mss pmtu
    tunnel destination xx.yyy.ru
    tunnel eoip id 1500
    up
!
interface Bridge0
    rename Home
    description "Home network"
    inherit GigabitEthernet0/Vlan1
    include AccessPoint
    include AccessPoint_5G
    include EoIP0
    security-level private
    ip address 192.168.234.1 255.255.255.0
    ip dhcp client dns-routes
    ip dhcp client name-servers
    igmp downstream
    up
!

Edited September 21, 2017 by utya

Le ecureuil · 09/21/2017 08:05 PM

@utya почему не хотите попробовать оставить mtu в покое (1500) и включить eoip_allow_fragment?

utya · 09/22/2017 06:39 AM

@Le ecureuilуже давно включал фрагментацию не помогало. Сейчас Удалил всё тунели, накатил новый драфт 2.11. Mtu не трогал он сам настроился. Включил фрагментацию. Понимаю что где-то какая-то вшифвая галочка стоит или ещё какая-то "хрень" которая не даёт нормально работать, но глаз уже замылен окончательно. Селф-тест приложил ниже.

Le ecureuil · 09/22/2017 08:31 AM

Вроде все верно. Попробуйте уменьшить MTU у WAN-интерфейсов до 1400 на обоих концах туннеля, сохранить настройки и перезагрузить роутеры. Возможно это поможет.

utya · September 24, 2017

В 22.09.2017 в 11:31, Le ecureuil сказал:

Вроде все верно. Попробуйте уменьшить MTU у WAN-интерфейсов до 1400 на обоих концах туннеля, сохранить настройки и перезагрузить роутеры. Возможно это поможет.

у меня на dsl приходит оптика, там стоит устройство в бридже, может это как то влияет?
1400 на WAN не помогает, есть смысл снижать?

UPD.

а после махинацией с mtu на роутере, нужно менять mtu на клиентах?
А то я смотрю если клиенты подключены на прямую через провод забриджовый с eoip то всё работает, а когда через vpn то меняется mtu и всё работает.

Edited September 24, 2017 by utya

KorDen · 10/01/2017 06:28 PM

Сейчас на 2.11.A.4.0-0 обнаружил крайне неприятное поведение автотуннелей - при падении одного (и попытках переподключиться) как я понимаю рестартуются все остальные на этом роутере, а за ним по цепочке начинают рестартоваться и на остальных роутерах - в итоге все туннели дохнут капитально, если хоть один глючит. Можно ли этого избежать?

r13 · October 1, 2017

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

Сейчас на 2.11.A.4.0-0 обнаружил крайне неприятное поведение автотуннелей - при падении одного (и попытках переподключиться) как я понимаю рестартуются все остальные на этом роутере, а за ним по цепочке начинают рестартоваться и на остальных роутерах - в итоге все туннели дохнут капитально, если хоть один глючит. Можно ли этого избежать?

Я уже об этом заводил тему, воспроизводится не всегда, зависимости не выявил. А так да частенько случается такая бяка. @Le ecureuil воспроизвести пока не смог.

Edited October 1, 2017 by r13

KorDen · 10/01/2017 07:18 PM

9 минут назад, r13 сказал:

Я уже об этом заводил тему

А, вот она! Я помнил, что у вас было что-то похожее, но сходу не нашел, где вы отписывались.. Отпишусь там тогда пожалуй

Sign In

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

Recommended Posts

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post