https://opennet.me/openforum/vsluhforumID6/2203.html Коллеги,<br><br>Есть гипервизор, на нем висит csr1000v на внутренних ip адресах.<br>У нее есть шлюз - внешний линуксовый роутер (локальный шлюз). Который натит все что приходит из гипервизора (в том числе и циску).<br>Есть удаленный линукс бокс, на нем есть несколько внешних паблик ip адресов.<br>Задача - пробросить один-два паблика на csr1000v.<br>Для тестов, сделал ipsec/gre туннель между двумя линусами - и пробросил внутри паблик с удаленного на локальный шлюз. Все работает. Не могу понять как прокинуть паблик за нат локального шлюза через гипервизор на циску.<br><br>Если что-то не понятно, пишите.<br>Спасибо!<br> https://opennet.me/openforum/vsluhforumID6/2203.html#7 Mon, 11 Sep 2017 04:48:40 GMT &gt;[оверквотинг удален]<br>&gt;&gt; int tun 0 <br>&gt;&gt; tunnel key 1 <br>&gt;&gt; end <br>&gt;&gt; wr <br>&gt; Т.о., можно отметить: <br>&gt; 1. ipsec/gre туннель на линукс-боксе работает.<br>&gt; 2. gre tunnel на csr поднимается, но не работает.<br>&gt; Исходя из этого, возможно проблема на линукс-боксе именно с форвардом gre.<br>&gt; zanswer, спасибо! Завтра попробую настроить gre форвардинг на линукс-боксе, и дам вам <br>&gt; знать.<br><br>Именно, NAT маршрутизатор не выполняет их пересылку в адрес удалённого маршрутизатора. К слову, в случае, если вы будете использовать GRE over IPSec, то фазу борьбы с GRE over NAT, можно пропустить, поскольку RFC 8086: GRE-in-UDP Encapsulation пока не актуален, а вот RFC 3948: UDP Encapsulation of IPsec ESP Packets весьма актуален и уже реализован.<br><br>Иными словами, проблем с NAT не возникнет, если инициировать соединение будет ваш CSR1000V, поскольку, как только маршрутизатор будет выявляться NAT, он будет переходить к инкапсуляции ESP пакетов в UDP. При этом GRE пакет будет находится внутри ESP, а значит NAT маршрутизатору не придё https://opennet.me/openforum/vsluhforumID6/2203.html#6 Sun, 10 Sep 2017 19:56:26 GMT &gt; Собственно говоря, осталось только написать требуемые правила для трансляции GRE пакетов, <br>&gt; на CSR1000V и удалённом маршрутизаторе дополнительно необходимо добавить команды для установления <br>&gt; GRE Key в заголовки пакетов: <br>&gt; conf t <br>&gt; int tun 0 <br>&gt; tunnel key 1 <br>&gt; end <br>&gt; wr <br><br>Т.о., можно отметить:<br>1. ipsec/gre туннель на линукс-боксе работает.<br>2. gre tunnel на csr поднимается, но не работает.<br><br>Исходя из этого, возможно проблема на линукс-боксе именно с форвардом gre.<br><br>zanswer, спасибо! Завтра попробую настроить gre форвардинг на линукс-боксе, и дам вам знать.<br><br> https://opennet.me/openforum/vsluhforumID6/2203.html#5 Sun, 10 Sep 2017 06:38:02 GMT &gt;[оверквотинг удален]<br>&gt; Sep 9 18:51:11.424: Tunnel1: Maximum interface MTU over-ridden to 10132..<br>&gt; Success rate is 0 percent (0/5) <br>&gt; vgw#sh deb <br>&gt; IOSXE Conditional Debug Configs: <br>&gt; Conditional Debug Global State: Stop <br>&gt; IOSXE Packet Tracing Configs: <br>&gt; Generic IP: <br>&gt; ICMP packet debugging is on <br>&gt; General-purpose tunnel: <br>&gt; Tunnel Interface Event debugging is on <br><br>Хорошо, раз туннель поднялся, значит мы можем говорить о том, что три ниже следующих условия соблюдены:<br><br>"There is no route, which includes the default route, to the tunnel destination address.<br>The interface that anchors the tunnel source is down.<br>The route to the tunnel destination address is through the tunnel itself, which results in recursion." <br><br>Поскольку по умолчанию point-to-point GRE туннель не выполняет отправку GRE Keepalives, то определить, что сервер назначения не получает GRE пакеты, не возможно, ввиду отсутствия механизма подтверждения доставки в GRE протоколе.<br><br>Из выше представленной вами информации, мы https://opennet.me/openforum/vsluhforumID6/2203.html#4 Sat, 09 Sep 2017 18:52:27 GMT Приветствую Zanwer,<br><br>Спасибо, за ваш ответ! И так, по-порядку:<br><br>&gt; Давайте начнём с вашего GRE туннеля. Вы сейчас строите напрямую между удалённым <br>&gt; маршрутизатором и вашим виртуальным CSR1000V, через NAT маршрутизатор?<br><br>Совершенно верно.<br><br>&gt; И так, ваш CSR1000V может выполнить пинг до tunnel destiantion? ICMP уходя <br>&gt; и возвращаются? Если так, значит мы можем предположить, что tunnel source <br>&gt; интерфейс содержит правильные настройки, а таблица маршрутизации содержит маршрут до адреса <br>&gt; назначения.<br><br>Все правильно. Все пингуется:<br><br>vgw#ping 139.59.142.112<br>Type escape sequence to abort.<br>Sending 5, 100-byte ICMP Echos to 139.59.142.112, timeout is 2 seconds:<br>!!!!!<br>Success rate is 100 percent (5/5), round-trip min/avg/max = 40/41/43 ms<br><br>&gt; В таком случае переходим непосредственно к GRE туннелю, вы сказали, что не <br>&gt; можете выполнить пинг адреса назначения туннеля, иными словами 10.118.0.2. Это означает, <br>&gt; что туннель не поднялся, покажите вывод команд: <br>&gt; show ip int br или show interfaces t https://opennet.me/openforum/vsluhforumID6/2203.html#3 Sat, 09 Sep 2017 11:13:55 GMT &gt;[оверквотинг удален]<br>&gt; tunnel source GigabitEthernet4 <br>&gt; tunnel destination 139.59.xx.xxx <br>&gt; !<br>&gt; gi4 - это egress в сторону шлюза.<br>&gt; Соответственно, на стороне ремоте линукс-бокса 10.118.0.2/30 в туннеле.<br>&gt; И за ним уже маршрутизирую сетку.<br>&gt; Но с циски даже .2 не пингуется через tun1.<br>&gt; NAT и исключения конечно прописаны с обеих сторон.<br>&gt; P.S. ARP proxy. Идея. Подумаю. Если есть рабочий конфиг, буду рад если <br>&gt; сможете показать.<br><br>Давайте начнём с вашего GRE туннеля. Вы сейчас строите напрямую между удалённым маршрутизатором и вашим виртуальным CSR1000V, через NAT маршрутизатор?<br><br>И так, ваш CSR1000V может выполнить пинг до tunnel destiantion? ICMP уходя и возвращаются? Если так, значит мы можем предположить, что tunnel source интерфейс содержит правильные настройки, а таблица маршрутизации содержит маршрут до адреса назначения.<br><br>В таком случае переходим непосредственно к GRE туннелю, вы сказали, что не можете выполнить пинг адреса назначения туннеля, иными словами 10.118.0.2. Это означает, https://opennet.me/openforum/vsluhforumID6/2203.html#2 Sat, 09 Sep 2017 07:49:55 GMT &gt; Можете сделать ровно так же, с помощью GRE over IPSec или можете <br>&gt; посмотреть в сторону Proxy ARP на вашем NAT маршрутизаторе.<br><br>Эм. Можете показать кусок конфига циски? Что там прописывать в tunnel source в этом случае, в tun интерфейсе? Я пока сделал просто gre:<br><br>interface Tunnel1<br> ip address 10.118.0.1 255.255.255.252<br> ip mtu 1436<br> tunnel source GigabitEthernet4<br> tunnel destination 139.59.xx.xxx<br>!<br><br>gi4 - это egress в сторону шлюза.<br>Соответственно, на стороне ремоте линукс-бокса 10.118.0.2/30 в туннеле. <br>И за ним уже маршрутизирую сетку.<br>Но с циски даже .2 не пингуется через tun1.<br><br>NAT и исключения конечно прописаны с обеих сторон.<br><br>P.S. ARP proxy. Идея. Подумаю. Если есть рабочий конфиг, буду рад если сможете показать.<br><br><br><br><br> https://opennet.me/openforum/vsluhforumID6/2203.html#1 Sat, 09 Sep 2017 05:25:33 GMT &gt;[оверквотинг удален]<br>&gt; Есть гипервизор, на нем висит csr1000v на внутренних ip адресах.<br>&gt; У нее есть шлюз - внешний линуксовый роутер (локальный шлюз). Который натит <br>&gt; все что приходит из гипервизора (в том числе и циску).<br>&gt; Есть удаленный линукс бокс, на нем есть несколько внешних паблик ip адресов. <br>&gt; Задача - пробросить один-два паблика на csr1000v.<br>&gt; Для тестов, сделал ipsec/gre туннель между двумя линусами - и пробросил внутри <br>&gt; паблик с удаленного на локальный шлюз. Все работает. Не могу понять <br>&gt; как прокинуть паблик за нат локального шлюза через гипервизор на циску. <br>&gt; Если что-то не понятно, пишите.<br>&gt; Спасибо!<br><br>Можете сделать ровно так же, с помощью GRE over IPSec или можете посмотреть в сторону Proxy ARP на вашем NAT маршрутизаторе.<br>