forum.opennet.ru - "CSR1000v за линуксовым натом

форумы

правила/FAQ

поиск

регистрация

вход/выход

слежка

"CSR1000v за линуксовым натом - получение public ip"

Форум Маршрутизаторы CISCO и др. оборудование. (VPN, VLAN, туннель)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"CSR1000v за линуксовым натом - получение public ip"	+/–
Сообщение от lightspeed (??) on 08-Сен-17, 15:47
Коллеги, Есть гипервизор, на нем висит csr1000v на внутренних ip адресах. У нее есть шлюз - внешний линуксовый роутер (локальный шлюз). Который натит все что приходит из гипервизора (в том числе и циску). Есть удаленный линукс бокс, на нем есть несколько внешних паблик ip адресов. Задача - пробросить один-два паблика на csr1000v. Для тестов, сделал ipsec/gre туннель между двумя линусами - и пробросил внутри паблик с удаленного на локальный шлюз. Все работает. Не могу понять как прокинуть паблик за нат локального шлюза через гипервизор на циску. Если что-то не понятно, пишите. Спасибо!
Ответить \| Правка \| Cообщить модератору

Оглавление

CSR1000v за линуксовым натом - получение public ip, zanswer CCNA RS and S, 08:25 , 09-Сен-17, (1)

CSR1000v за линуксовым натом - получение public ip, lightspeed, 10:49 , 09-Сен-17, (2)

CSR1000v за линуксовым натом - получение public ip, zanswer CCNA RS and S, 14:13 , 09-Сен-17, (3)

CSR1000v за линуксовым натом - получение public ip, lightspeed, 21:52 , 09-Сен-17, (4)

CSR1000v за линуксовым натом - получение public ip, zanswer CCNA RS and S, 09:38 , 10-Сен-17, (5)

CSR1000v за линуксовым натом - получение public ip, lightspeed, 22:56 , 10-Сен-17, (6)

CSR1000v за линуксовым натом - получение public ip, zanswer CCNA RS and S, 07:48 , 11-Сен-17, (7)

Сообщения по теме [Сортировка по ответам | RSS]

1. "CSR1000v за линуксовым натом - получение public ip" +/–

Сообщение от zanswer CCNA RS and S on 09-Сен-17, 08:25

>[оверквотинг удален]
> Есть гипервизор, на нем висит csr1000v на внутренних ip адресах.
> У нее есть шлюз - внешний линуксовый роутер (локальный шлюз). Который натит
> все что приходит из гипервизора (в том числе и циску).
> Есть удаленный линукс бокс, на нем есть несколько внешних паблик ip адресов.
> Задача - пробросить один-два паблика на csr1000v.
> Для тестов, сделал ipsec/gre туннель между двумя линусами - и пробросил внутри
> паблик с удаленного на локальный шлюз. Все работает. Не могу понять
> как прокинуть паблик за нат локального шлюза через гипервизор на циску.
> Если что-то не понятно, пишите.
> Спасибо!
Можете сделать ровно так же, с помощью GRE over IPSec или можете посмотреть в сторону Proxy ARP на вашем NAT маршрутизаторе.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "CSR1000v за линуксовым натом - получение public ip" +/–

Сообщение от lightspeed (??) on 09-Сен-17, 10:49

> Можете сделать ровно так же, с помощью GRE over IPSec или можете
> посмотреть в сторону Proxy ARP на вашем NAT маршрутизаторе.
Эм. Можете показать кусок конфига циски? Что там прописывать в tunnel source в этом случае, в tun интерфейсе? Я пока сделал просто gre:
interface Tunnel1
ip address 10.118.0.1 255.255.255.252
ip mtu 1436
tunnel source GigabitEthernet4
tunnel destination 139.59.xx.xxx
!
gi4 - это egress в сторону шлюза.
Соответственно, на стороне ремоте линукс-бокса 10.118.0.2/30 в туннеле.
И за ним уже маршрутизирую сетку.
Но с циски даже .2 не пингуется через tun1.
NAT и исключения конечно прописаны с обеих сторон.
P.S. ARP proxy. Идея. Подумаю. Если есть рабочий конфиг, буду рад если сможете показать.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "CSR1000v за линуксовым натом - получение public ip" +/–

Сообщение от zanswer CCNA RS and S on 09-Сен-17, 14:13

>[оверквотинг удален]
>  tunnel source GigabitEthernet4
>  tunnel destination 139.59.xx.xxx
> !
> gi4 - это egress в сторону шлюза.
> Соответственно, на стороне ремоте линукс-бокса 10.118.0.2/30 в туннеле.
> И за ним уже маршрутизирую сетку.
> Но с циски даже .2 не пингуется через tun1.
> NAT и исключения конечно прописаны с обеих сторон.
> P.S. ARP proxy. Идея. Подумаю. Если есть рабочий конфиг, буду рад если
> сможете показать.
Давайте начнём с вашего GRE туннеля. Вы сейчас строите напрямую между удалённым маршрутизатором и вашим виртуальным CSR1000V, через NAT маршрутизатор?
И так, ваш CSR1000V может выполнить пинг до tunnel destiantion? ICMP уходя и возвращаются? Если так, значит мы можем предположить, что tunnel source интерфейс содержит правильные настройки, а таблица маршрутизации содержит маршрут до адреса назначения.
В таком случае переходим непосредственно к GRE туннелю, вы сказали, что не можете выполнить пинг адреса назначения туннеля, иными словами 10.118.0.2. Это означает, что туннель не поднялся, покажите вывод команд:
show ip int br или show interfaces tunnel 1 | include protocol
Если по каким-то причинам это не возможно, то укажите, в каком состоянии находится туннель? Он поднялся у вас? Если нет, значит мы можем говорить о том, что ваш NAT маршрутизатор не выполняет трансляцию GRE пакетов.
Проверьте любым доступным вам способом, видите ли вы на NAT маршрутизаторе на интерфейсе смежном с вашим Gi4 GRE пакеты от вашего CSR1000V. Далее проверьте выполняет ли он их трансляцию или нет (как известно трансляция GRE протокола затруднена, ввиду отсутствия у протокола полей уникально идентифицирующих пакет). В случае, если между удалённым маршрутизатором и NAT маршрутизатором есть промежуточные устройства, то проверьте видите ли вы на удалённом маршрутизаторе на интерфейсе которому назначен 139.59.xx.xxx, GRE пакеты от вашего CSR1000V.
Что касается Proxy ARP, у меня нет готового конфига для Linux, есть для Mikrotik, для CSR1000V не каких дополнительных настроек не нужно, кроме стандартных настроек интерфейса.
На Mikrotik это реализовано следующим образом, - возможно данный концепцию можно перенести и на обычный Linux дистрибутив, вы назначаете на loopback или иным удобным способом ваши глобально маршрутизируемые адреса, активируете Proxy ARP для интерфейсов которые будут участвовать в процессе обмена трафиком. После чего создаёте стандартный статический маршрут, указывающий, что требуемый глобально маршрутизируемый адрес находится за интерфейсом смежным с вашим CSR1000V.
Но я бы всё таки смотрел лучше в сторону туннеля, нежели Proxy ARP, в прочем, если с туннелем нечего не получится совсем, то можно будет и Proxy ARP попробовать реализовать.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "CSR1000v за линуксовым натом - получение public ip" +/–

Сообщение от lightspeed (??) on 09-Сен-17, 21:52

Приветствую Zanwer,
Спасибо, за ваш ответ! И так, по-порядку:
> Давайте начнём с вашего GRE туннеля. Вы сейчас строите напрямую между удалённым
> маршрутизатором и вашим виртуальным CSR1000V, через NAT маршрутизатор?
Совершенно верно.
> И так, ваш CSR1000V может выполнить пинг до tunnel destiantion? ICMP уходя
> и возвращаются? Если так, значит мы можем предположить, что tunnel source
> интерфейс содержит правильные настройки, а таблица маршрутизации содержит маршрут до адреса
> назначения.
Все правильно. Все пингуется:
vgw#ping 139.59.142.112
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 139.59.142.112, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/41/43 ms
> В таком случае переходим непосредственно к GRE туннелю, вы сказали, что не
> можете выполнить пинг адреса назначения туннеля, иными словами 10.118.0.2. Это означает,
> что туннель не поднялся, покажите вывод команд:
> show ip int br или show interfaces tunnel 1 | include protocol
Вывод:
vgw#show interfaces tunnel 1 | include protocol
Tunnel1 is up, line protocol is up
  Tunnel protocol/transport GRE/IP
     0 unknown protocol drops
Т.о., видно что протокол в апе, и туннель должен строиться..(
В тоже время, tcpdump -i eth0 proto gre
на удаленном линукс-боксе показывает пустоту..
соответственно tcpdump -i tun1 - тоже.
включил дебаг gre и icmp на циске - ничего.
Что вызывает подозрение, откровенно говоря.
Причем, icmp пакеты на циске вижу, если пингую что-то за пределами туннеля.

vgw#ping 10.118.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.118.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
vgw#
Sep  9 18:51:01.410: ICMP: echo reply sent, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0
Sep  9 18:51:01.411: ICMP: echo reply rcvd, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0
Sep  9 18:51:01.411: ICMP: echo reply sent, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0
Sep  9 18:51:01.412: ICMP: echo reply rcvd, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0
Sep  9 18:51:01.412: ICMP: echo reply sent, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0
Sep  9 18:51:01.413: ICMP: echo reply rcvd, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0
vgw#
vgw#
Sep  9 18:51:01.413: ICMP: echo reply sent, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0
Sep  9 18:51:01.414: ICMP: echo reply rcvd, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0
Sep  9 18:51:01.414: ICMP: echo reply sent, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0
Sep  9 18:51:01.415: ICMP: echo reply rcvd, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0
Sep  9 18:51:01.424: Tunnel1: Maximum interface MTU over-ridden to 10132
vgw#ping 10.118.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.118.0.2, timeout is 2 seconds:
...
Sep  9 18:51:11.424: Tunnel1: Maximum interface MTU over-ridden to 10132..
Success rate is 0 percent (0/5)
vgw#sh deb
IOSXE Conditional Debug Configs:
Conditional Debug Global State: Stop

IOSXE Packet Tracing Configs:

Generic IP:
  ICMP packet debugging is on
General-purpose tunnel:
  Tunnel Interface Event debugging is on

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "CSR1000v за линуксовым натом - получение public ip" +/–

Сообщение от zanswer CCNA RS and S on 10-Сен-17, 09:38

>[оверквотинг удален]
> Sep  9 18:51:11.424: Tunnel1: Maximum interface MTU over-ridden to 10132..
> Success rate is 0 percent (0/5)
> vgw#sh deb
> IOSXE Conditional Debug Configs:
> Conditional Debug Global State: Stop
> IOSXE Packet Tracing Configs:
> Generic IP:
>   ICMP packet debugging is on
> General-purpose tunnel:
>   Tunnel Interface Event debugging is on
Хорошо, раз туннель поднялся, значит мы можем говорить о том, что три ниже следующих условия соблюдены:
"There is no route, which includes the default route, to the tunnel destination address.
The interface that anchors the tunnel source is down.
The route to the tunnel destination address is through the tunnel itself, which results in recursion."
Поскольку по умолчанию point-to-point GRE туннель не выполняет отправку GRE Keepalives, то определить, что сервер назначения не получает GRE пакеты, не возможно, ввиду отсутствия механизма подтверждения доставки в GRE протоколе.
Из выше представленной вами информации, мы можем сделать вывод, что имеем проблему на NAT маршрутизаторе, который не выполняет функции трансляции для GRE протокола или они выполняются не верно.
Поэтому теперь наша цель ваш NAT маршрутизатор, мы должны определить причину, которая ведёт к следствию, нарушению функции NAT трансляций для GRE пакетов. Поскольку вы используете Linux, то мы можем предположить, что не был активирован ALG для GRE, поскольку трансляция GRE пакетов без помощи дополнительных помощников не возможна.
Я не смог сходу найти документацию по GRE ALG, по крайней мере в объёме позволившем бы мне предложить правила для NAT. Но, вот, что удалось найти, это модули требуемые для отслеживания и трансляции GRE протокола:
nf_conntrack_proto_gre
nf_nat_proto_gre
Поскольку у GRE нет в заголовке таких полей, как SRC/DST порт, то в связи с этим, PAT трансляция затруднена. Судя по исходным кодам модулей, они используют не обязательное поле GRE Key для определения, какому потоку принадлежит полученный GRE пакет или CallID в случае PPTP GRE.
Собственно говоря, осталось только написать требуемые правила для трансляции GRE пакетов, на CSR1000V и удалённом маршрутизаторе дополнительно необходимо добавить команды для установления GRE Key в заголовки пакетов:
conf t
int tun 0
tunnel key 1
end
wr

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "CSR1000v за линуксовым натом - получение public ip" +/–

Сообщение от lightspeed (??) on 10-Сен-17, 22:56

> Собственно говоря, осталось только написать требуемые правила для трансляции GRE пакетов,
> на CSR1000V и удалённом маршрутизаторе дополнительно необходимо добавить команды для установления
> GRE Key в заголовки пакетов:
> conf t
> int tun 0
> tunnel key 1
> end
> wr
Т.о., можно отметить:
1. ipsec/gre туннель на линукс-боксе работает.
2. gre tunnel на csr поднимается, но не работает.
Исходя из этого, возможно проблема на линукс-боксе именно с форвардом gre.
zanswer, спасибо! Завтра попробую настроить gre форвардинг на линукс-боксе, и дам вам знать.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "CSR1000v за линуксовым натом - получение public ip" +/–

Сообщение от zanswer CCNA RS and S on 11-Сен-17, 07:48

>[оверквотинг удален]
>> int tun 0
>> tunnel key 1
>> end
>> wr
> Т.о., можно отметить:
> 1. ipsec/gre туннель на линукс-боксе работает.
> 2. gre tunnel на csr поднимается, но не работает.
> Исходя из этого, возможно проблема на линукс-боксе именно с форвардом gre.
> zanswer, спасибо! Завтра попробую настроить gre форвардинг на линукс-боксе, и дам вам
> знать.
Именно, NAT маршрутизатор не выполняет их пересылку в адрес удалённого маршрутизатора. К слову, в случае, если вы будете использовать GRE over IPSec, то фазу борьбы с GRE over NAT, можно пропустить, поскольку RFC 8086: GRE-in-UDP Encapsulation пока не актуален, а вот RFC 3948: UDP Encapsulation of IPsec ESP Packets весьма актуален и уже реализован.
Иными словами, проблем с NAT не возникнет, если инициировать соединение будет ваш CSR1000V, поскольку, как только маршрутизатор будет выявляться NAT, он будет переходить к инкапсуляции ESP пакетов в UDP. При этом GRE пакет будет находится внутри ESP, а значит NAT маршрутизатору не придётся иметь дело с плохо транслируемым через NAT GRE.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	1. "CSR1000v за линуксовым натом - получение public ip"	+/–
	Сообщение от zanswer CCNA RS and S on 09-Сен-17, 08:25
	>[оверквотинг удален] > Есть гипервизор, на нем висит csr1000v на внутренних ip адресах. > У нее есть шлюз - внешний линуксовый роутер (локальный шлюз). Который натит > все что приходит из гипервизора (в том числе и циску). > Есть удаленный линукс бокс, на нем есть несколько внешних паблик ip адресов. > Задача - пробросить один-два паблика на csr1000v. > Для тестов, сделал ipsec/gre туннель между двумя линусами - и пробросил внутри > паблик с удаленного на локальный шлюз. Все работает. Не могу понять > как прокинуть паблик за нат локального шлюза через гипервизор на циску. > Если что-то не понятно, пишите. > Спасибо! Можете сделать ровно так же, с помощью GRE over IPSec или можете посмотреть в сторону Proxy ARP на вашем NAT маршрутизаторе.
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "CSR1000v за линуксовым натом - получение public ip"	+/–
	Сообщение от lightspeed (??) on 09-Сен-17, 10:49
	> Можете сделать ровно так же, с помощью GRE over IPSec или можете > посмотреть в сторону Proxy ARP на вашем NAT маршрутизаторе. Эм. Можете показать кусок конфига циски? Что там прописывать в tunnel source в этом случае, в tun интерфейсе? Я пока сделал просто gre: interface Tunnel1 ip address 10.118.0.1 255.255.255.252 ip mtu 1436 tunnel source GigabitEthernet4 tunnel destination 139.59.xx.xxx ! gi4 - это egress в сторону шлюза. Соответственно, на стороне ремоте линукс-бокса 10.118.0.2/30 в туннеле. И за ним уже маршрутизирую сетку. Но с циски даже .2 не пингуется через tun1. NAT и исключения конечно прописаны с обеих сторон. P.S. ARP proxy. Идея. Подумаю. Если есть рабочий конфиг, буду рад если сможете показать.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "CSR1000v за линуксовым натом - получение public ip"	+/–
	Сообщение от zanswer CCNA RS and S on 09-Сен-17, 14:13
	>[оверквотинг удален] > tunnel source GigabitEthernet4 > tunnel destination 139.59.xx.xxx > ! > gi4 - это egress в сторону шлюза. > Соответственно, на стороне ремоте линукс-бокса 10.118.0.2/30 в туннеле. > И за ним уже маршрутизирую сетку. > Но с циски даже .2 не пингуется через tun1. > NAT и исключения конечно прописаны с обеих сторон. > P.S. ARP proxy. Идея. Подумаю. Если есть рабочий конфиг, буду рад если > сможете показать. Давайте начнём с вашего GRE туннеля. Вы сейчас строите напрямую между удалённым маршрутизатором и вашим виртуальным CSR1000V, через NAT маршрутизатор? И так, ваш CSR1000V может выполнить пинг до tunnel destiantion? ICMP уходя и возвращаются? Если так, значит мы можем предположить, что tunnel source интерфейс содержит правильные настройки, а таблица маршрутизации содержит маршрут до адреса назначения. В таком случае переходим непосредственно к GRE туннелю, вы сказали, что не можете выполнить пинг адреса назначения туннеля, иными словами 10.118.0.2. Это означает, что туннель не поднялся, покажите вывод команд: show ip int br или show interfaces tunnel 1 \| include protocol Если по каким-то причинам это не возможно, то укажите, в каком состоянии находится туннель? Он поднялся у вас? Если нет, значит мы можем говорить о том, что ваш NAT маршрутизатор не выполняет трансляцию GRE пакетов. Проверьте любым доступным вам способом, видите ли вы на NAT маршрутизаторе на интерфейсе смежном с вашим Gi4 GRE пакеты от вашего CSR1000V. Далее проверьте выполняет ли он их трансляцию или нет (как известно трансляция GRE протокола затруднена, ввиду отсутствия у протокола полей уникально идентифицирующих пакет). В случае, если между удалённым маршрутизатором и NAT маршрутизатором есть промежуточные устройства, то проверьте видите ли вы на удалённом маршрутизаторе на интерфейсе которому назначен 139.59.xx.xxx, GRE пакеты от вашего CSR1000V. Что касается Proxy ARP, у меня нет готового конфига для Linux, есть для Mikrotik, для CSR1000V не каких дополнительных настроек не нужно, кроме стандартных настроек интерфейса. На Mikrotik это реализовано следующим образом, - возможно данный концепцию можно перенести и на обычный Linux дистрибутив, вы назначаете на loopback или иным удобным способом ваши глобально маршрутизируемые адреса, активируете Proxy ARP для интерфейсов которые будут участвовать в процессе обмена трафиком. После чего создаёте стандартный статический маршрут, указывающий, что требуемый глобально маршрутизируемый адрес находится за интерфейсом смежным с вашим CSR1000V. Но я бы всё таки смотрел лучше в сторону туннеля, нежели Proxy ARP, в прочем, если с туннелем нечего не получится совсем, то можно будет и Proxy ARP попробовать реализовать.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "CSR1000v за линуксовым натом - получение public ip"	+/–
	Сообщение от lightspeed (??) on 09-Сен-17, 21:52
	Приветствую Zanwer, Спасибо, за ваш ответ! И так, по-порядку: > Давайте начнём с вашего GRE туннеля. Вы сейчас строите напрямую между удалённым > маршрутизатором и вашим виртуальным CSR1000V, через NAT маршрутизатор? Совершенно верно. > И так, ваш CSR1000V может выполнить пинг до tunnel destiantion? ICMP уходя > и возвращаются? Если так, значит мы можем предположить, что tunnel source > интерфейс содержит правильные настройки, а таблица маршрутизации содержит маршрут до адреса > назначения. Все правильно. Все пингуется: vgw#ping 139.59.142.112 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 139.59.142.112, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/41/43 ms > В таком случае переходим непосредственно к GRE туннелю, вы сказали, что не > можете выполнить пинг адреса назначения туннеля, иными словами 10.118.0.2. Это означает, > что туннель не поднялся, покажите вывод команд: > show ip int br или show interfaces tunnel 1 \| include protocol Вывод: vgw#show interfaces tunnel 1 \| include protocol Tunnel1 is up, line protocol is up Tunnel protocol/transport GRE/IP 0 unknown protocol drops Т.о., видно что протокол в апе, и туннель должен строиться..( В тоже время, tcpdump -i eth0 proto gre на удаленном линукс-боксе показывает пустоту.. соответственно tcpdump -i tun1 - тоже. включил дебаг gre и icmp на циске - ничего. Что вызывает подозрение, откровенно говоря. Причем, icmp пакеты на циске вижу, если пингую что-то за пределами туннеля. vgw#ping 10.118.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.118.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms vgw# Sep 9 18:51:01.410: ICMP: echo reply sent, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0 Sep 9 18:51:01.411: ICMP: echo reply rcvd, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0 Sep 9 18:51:01.411: ICMP: echo reply sent, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0 Sep 9 18:51:01.412: ICMP: echo reply rcvd, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0 Sep 9 18:51:01.412: ICMP: echo reply sent, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0 Sep 9 18:51:01.413: ICMP: echo reply rcvd, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0 vgw# vgw# Sep 9 18:51:01.413: ICMP: echo reply sent, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0 Sep 9 18:51:01.414: ICMP: echo reply rcvd, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0 Sep 9 18:51:01.414: ICMP: echo reply sent, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0 Sep 9 18:51:01.415: ICMP: echo reply rcvd, src 10.118.0.1, dst 10.118.0.1, topology BASE, dscp 0 topoid 0 Sep 9 18:51:01.424: Tunnel1: Maximum interface MTU over-ridden to 10132 vgw#ping 10.118.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.118.0.2, timeout is 2 seconds: ... Sep 9 18:51:11.424: Tunnel1: Maximum interface MTU over-ridden to 10132.. Success rate is 0 percent (0/5) vgw#sh deb IOSXE Conditional Debug Configs: Conditional Debug Global State: Stop IOSXE Packet Tracing Configs: Generic IP: ICMP packet debugging is on General-purpose tunnel: Tunnel Interface Event debugging is on
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "CSR1000v за линуксовым натом - получение public ip"	+/–
	Сообщение от zanswer CCNA RS and S on 10-Сен-17, 09:38
	>[оверквотинг удален] > Sep 9 18:51:11.424: Tunnel1: Maximum interface MTU over-ridden to 10132.. > Success rate is 0 percent (0/5) > vgw#sh deb > IOSXE Conditional Debug Configs: > Conditional Debug Global State: Stop > IOSXE Packet Tracing Configs: > Generic IP: > ICMP packet debugging is on > General-purpose tunnel: > Tunnel Interface Event debugging is on Хорошо, раз туннель поднялся, значит мы можем говорить о том, что три ниже следующих условия соблюдены: "There is no route, which includes the default route, to the tunnel destination address. The interface that anchors the tunnel source is down. The route to the tunnel destination address is through the tunnel itself, which results in recursion." Поскольку по умолчанию point-to-point GRE туннель не выполняет отправку GRE Keepalives, то определить, что сервер назначения не получает GRE пакеты, не возможно, ввиду отсутствия механизма подтверждения доставки в GRE протоколе. Из выше представленной вами информации, мы можем сделать вывод, что имеем проблему на NAT маршрутизаторе, который не выполняет функции трансляции для GRE протокола или они выполняются не верно. Поэтому теперь наша цель ваш NAT маршрутизатор, мы должны определить причину, которая ведёт к следствию, нарушению функции NAT трансляций для GRE пакетов. Поскольку вы используете Linux, то мы можем предположить, что не был активирован ALG для GRE, поскольку трансляция GRE пакетов без помощи дополнительных помощников не возможна. Я не смог сходу найти документацию по GRE ALG, по крайней мере в объёме позволившем бы мне предложить правила для NAT. Но, вот, что удалось найти, это модули требуемые для отслеживания и трансляции GRE протокола: nf_conntrack_proto_gre nf_nat_proto_gre Поскольку у GRE нет в заголовке таких полей, как SRC/DST порт, то в связи с этим, PAT трансляция затруднена. Судя по исходным кодам модулей, они используют не обязательное поле GRE Key для определения, какому потоку принадлежит полученный GRE пакет или CallID в случае PPTP GRE. Собственно говоря, осталось только написать требуемые правила для трансляции GRE пакетов, на CSR1000V и удалённом маршрутизаторе дополнительно необходимо добавить команды для установления GRE Key в заголовки пакетов: conf t int tun 0 tunnel key 1 end wr
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "CSR1000v за линуксовым натом - получение public ip"	+/–
	Сообщение от lightspeed (??) on 10-Сен-17, 22:56
	> Собственно говоря, осталось только написать требуемые правила для трансляции GRE пакетов, > на CSR1000V и удалённом маршрутизаторе дополнительно необходимо добавить команды для установления > GRE Key в заголовки пакетов: > conf t > int tun 0 > tunnel key 1 > end > wr Т.о., можно отметить: 1. ipsec/gre туннель на линукс-боксе работает. 2. gre tunnel на csr поднимается, но не работает. Исходя из этого, возможно проблема на линукс-боксе именно с форвардом gre. zanswer, спасибо! Завтра попробую настроить gre форвардинг на линукс-боксе, и дам вам знать.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	7. "CSR1000v за линуксовым натом - получение public ip"	+/–
	Сообщение от zanswer CCNA RS and S on 11-Сен-17, 07:48
	>[оверквотинг удален] >> int tun 0 >> tunnel key 1 >> end >> wr > Т.о., можно отметить: > 1. ipsec/gre туннель на линукс-боксе работает. > 2. gre tunnel на csr поднимается, но не работает. > Исходя из этого, возможно проблема на линукс-боксе именно с форвардом gre. > zanswer, спасибо! Завтра попробую настроить gre форвардинг на линукс-боксе, и дам вам > знать. Именно, NAT маршрутизатор не выполняет их пересылку в адрес удалённого маршрутизатора. К слову, в случае, если вы будете использовать GRE over IPSec, то фазу борьбы с GRE over NAT, можно пропустить, поскольку RFC 8086: GRE-in-UDP Encapsulation пока не актуален, а вот RFC 3948: UDP Encapsulation of IPsec ESP Packets весьма актуален и уже реализован. Иными словами, проблем с NAT не возникнет, если инициировать соединение будет ваш CSR1000V, поскольку, как только маршрутизатор будет выявляться NAT, он будет переходить к инкапсуляции ESP пакетов в UDP. При этом GRE пакет будет находится внутри ESP, а значит NAT маршрутизатору не придётся иметь дело с плохо транслируемым через NAT GRE.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору