Jump to content
Le ecureuil

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

Recommended Posts

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

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

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

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

Edited by r13

Share this post


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

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

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

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

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

self-test_giga3.txt

self-test_DSL (2).txt

 

Edited by utya

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


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

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

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

Edited by r13

Share this post


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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


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

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

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


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

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

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

Share this post


Link to post
Share on other sites

@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

 

Share this post


Link to post
Share on other sites
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) эти пакеты пропинывает.

  • Upvote 1

Share this post


Link to post
Share on other sites
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. Спасибо за пост, буду почитать матчасть. Ну а пока свернул все каналы, а то ничего не работает, невозможно работать.

Share this post


Link to post
Share on other sites
В 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 ниже чем размер пакета + заголовки, а потом на приемнике их прозрачно соберет.

Share this post


Link to post
Share on other sites
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, то идет дискард или все равно отправляем? если часть пакета потеряли, то дискардим весь пакет оставляя решение за протоколами более высокого уровня?

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Заметил такое на 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 by KorDen
  • Thanks 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
В 22.09.2017 в 11:31, Le ecureuil сказал:

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

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

UPD.

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

Edited by utya

Share this post


Link to post
Share on other sites

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

Share this post


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

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

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

 

Edited by r13
  • Thanks 1

Share this post


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

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

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

  • Thanks 1

Share this post


Link to post
Share on other sites

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