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

[r13]

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

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

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

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

Edited September 5, 2017 by r13

[utya]

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]

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

[Sergey Guydya]

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

[utya]

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

[r13]

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]

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

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

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

[Le ecureuil]

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

[utya]

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

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

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

[dexter]

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

[utya]

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

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

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

[dexter]

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

[utya]

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

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

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

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

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

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

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]

@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]

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]

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]

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

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]

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

[KorDen]

Заметил такое на 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]

Я снова решил поднять 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]

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

 

[utya]

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

[Le ecureuil]

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

[utya]

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

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

[r13]

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

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

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

 

Edited October 1, 2017 by r13

[KorDen]

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

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

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