LINUX.ORG.RU
ФорумAdmin

GRE tunnel Debian 7.5 - Cisco

 ,


0

1

Добрый день, ситуацияю странная до абсурда. Есть две машины, на одной Debian 6.0 на другой Debian 7.5. Задача поднять GRE туннель до Cisco.

Конфигурация туннеля на Debian 6.0

auto gre1
iface gre1 inet static
address 172.18.0.54
netmask 255.255.255.252
modprobe ip_gre
up ifconfig gre1 multicast
pre-up iptunnel add gre1 mode gre local 172.18.1.49 remote 172.18.1.1 ttl 255
pointopoint 172.18.0.53
post-down iptunnel del gre1 

туннель прекрасно работает. пинги до 172.18.0.53 и трасировка прекрасно идут.

Конфигурация тунеля на Debian 7.5

auto gre1
iface gre1 inet static
address 172.18.0.50
netmask 255.255.255.252
modprobe ip_gre
up ifconfig gre1 multicast
pre-up iptunnel add gre1 mode gre local 172.18.1.48 remote 172.18.1.1 ttl 255
pointopoint 172.18.0.49
post-down iptunnel del gre1 

пинги и трасеровка не идут до 172.18.0.49. вот что показывает tcpdump

root@vs-msk00-prx05:/home/manage# tcpdump -i gre1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gre1, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:28:26.173697 IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2642, seq 1, length 64
11:28:27.174072 IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2642, seq 2, length 64
11:28:28.174054 IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2642, seq 3, length 64
11:28:29.174047 IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2642, seq 4, length 64
11:28:30.174034 IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2642, seq 5, length 64
11:28:31.174029 IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2642, seq 6, length 64
11:28:32.174020 IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2642, seq 7, length 64

Не могу понять, почему на Debian 7.5 не работает. Циску сразу отметаем так как там два тунеля на двух интерфейсах полностью индентичные, только различаются айпи, 53 и 49 соответственно. Подскажите в чем отличие построение Gre туннеля на Debian 6.0 и Debian 7.5. Iptables не правил ни на Debian 6.0, ни на Debian 7.5.



Последнее исправление: Ninjatrasher (всего исправлений: 2)

Ответ на: комментарий от victorb

iptables пусты по дефолту и там и там. думаете следует на второй машине прописать разрешния в INPUT и OUTPUT?

Ninjatrasher
() автор топика

Я бы всё-таки не отметал сразу cisco.

Надо проверить, приходят ли из туннеля на cisco пакеты. Либо в acl добавить правило с log в конце и посмотреть счётчик, либо включить debug.

Deleted
()
Ответ на: комментарий от Deleted

с циски не пигуется вторая машина, а пакеты иду, но идут в никуда. но так же на циске пингуется первая машина и пакеты идут. так что тут явно затык не в циске.

Ninjatrasher
() автор топика
Ответ на: комментарий от Ninjatrasher

Для меня всё равно неявно.

Доверяй, но проверяй.

Без конфига cisco не вижу смысла тыкать в один дебиан пальцем.

Deleted
()
Ответ на: комментарий от Deleted
 interface Tunnel2
description **** GRE to Squid server for WCCP ****
ip address 172.18.0.49 255.255.255.252
ip mtu 1276
tunnel source 172.18.1.1
tunnel destination 172.18.1.48 

точно такой же конфиг, но с другими ip, работает для первой машины

Ninjatrasher
() автор топика

Заметил так же интересную вещь на второй машине.

При выводе команды ifconfig -a, вижу следующие:

gre1      Link encap:UNSPEC  HWaddr AC-12-01-30-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:172.18.0.50  P-t-P:172.18.0.49  Mask:255.255.255.255
          inet6 addr: fe80::5efe:ac12:130/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1476  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:488 (488.0 B)
Маска все равно 255, хотя в interfaces ставил 252. может быть в этом затык?

Ninjatrasher
() автор топика
Ответ на: комментарий от victorb

прописал в iptables следующие

root@vs-msk00-prx05:/home/manage# iptables -I INPUT -p gre -s 172.18.1.1 -j ACCEPT
root@vs-msk00-prx05:/home/manage# iptables -I OUTPUT -p gre -s 172.18.1.1 -j ACCEPT
root@vs-msk00-prx05:/home/manage# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     gre  --  172.18.1.1           anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     gre  --  172.18.1.1           anywhere
не помогло.

Ninjatrasher
() автор топика
Ответ на: комментарий от Ninjatrasher

Если у тебя ничего не было прописано в iptables, а по умолчанию там ACCEPT, то это и не поможет.

Deleted
()
Ответ на: комментарий от Deleted

вот конфиг рабочего туннеля, котороый используется первой машиной на дебинае

interface Tunnel1
description **** GRE to Squid server for WCCP ****
ip address 172.18.0.53 255.255.255.252
ip mtu 1276
tunnel source 172.18.1.1
tunnel destination 172.18.1.47

Ninjatrasher
() автор топика
Ответ на: комментарий от Ninjatrasher

Я конечно с GRE не очень. Но мне непонятно, почему IP и подсети не совпадают.

$ ipcalc 172.18.0.53 255.255.255.252
Address:   172.18.0.53          10101100.00010010.00000000.001101 01
Netmask:   255.255.255.252 = 30 11111111.11111111.11111111.111111 00
Wildcard:  0.0.0.3              00000000.00000000.00000000.000000 11
=>
Network:   172.18.0.52/30       10101100.00010010.00000000.001101 00
HostMin:   172.18.0.53          10101100.00010010.00000000.001101 01
HostMax:   172.18.0.54          10101100.00010010.00000000.001101 10
Broadcast: 172.18.0.55          10101100.00010010.00000000.001101 11
Hosts/Net: 2                     Class B, Private Internet

Нашёл настройки рабочие, GRE-туннель между 2-мя cisco.

interface Tunnel57
 ip address 172.30.30.1 255.255.255.252
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/1
 tunnel destination 192.168.40.2

interface GigabitEthernet0/1
 ip address 192.168.40.1 255.255.255.252
 duplex auto
 speed auto

ИМХО, поправь IP-сети, они точно криво определены.

Deleted
()
Последнее исправление: WiZ_Ed (всего исправлений: 1)
Ответ на: комментарий от Deleted

эм... почему не совпадают?

HostMin:   172.18.0.53
HostMax:   172.18.0.54

0.53 адрес внутри туннеля, 0.54 адрес тунеля на первой машине.

Ninjatrasher
() автор топика
Ответ на: комментарий от Deleted

ну это между двумя цисками, а у меня между циской и debianом. конфиг циски

interface Tunnel1
description **** GRE to Squid server for WCCP ****
ip address 172.18.0.53 255.255.255.252
ip mtu 1276
tunnel source 172.18.1.1
tunnel destination 172.18.1.47
рабочий. с этим конфигом все работает и все хорошо, но вот машина 172.18.1.47 - Debian 6.0 а вот такой конфиг
interface Tunnel2
description **** GRE to Squid server for WCCP ****
ip address 172.18.0.49 255.255.255.252
ip mtu 1276
tunnel source 172.18.1.1
tunnel destination 172.18.1.48 
172.18.1.48 - машина с Debian 7.5. не работает насчет маски 252, все ж верно, будут два адрес 172.18.0.49 - это адрес на циске, 172.18.0.50 адрес на дебиане 7.5

Ninjatrasher
() автор топика
Ответ на: комментарий от Ninjatrasher

Ошибся. Вот с нерабочим дебианом.

$ ipcalc 172.18.0.49 255.255.255.252
Address:   172.18.0.49          10101100.00010010.00000000.001100 01
Netmask:   255.255.255.252 = 30 11111111.11111111.11111111.111111 00
Wildcard:  0.0.0.3              00000000.00000000.00000000.000000 11
=>
Network:   172.18.0.48/30       10101100.00010010.00000000.001100 00
HostMin:   172.18.0.49          10101100.00010010.00000000.001100 01
HostMax:   172.18.0.50          10101100.00010010.00000000.001100 10
Broadcast: 172.18.0.51          10101100.00010010.00000000.001100 11
Hosts/Net: 2                     Class B, Private Internet

Строка

tunnel destination 172.18.1.48 
172.18.1.48 - это адрес подсети для 172.18.1.49.30. Поэтому использование 172.18.1.48 некорректно. Должно быть 172.18.1.50 для дебиана.

Deleted
()

скажу дальше больше решил поднять по этой статье http://habrahabr.ru/post/227859/

сделал команды

HOST1: ip link add grel1 type gre1  local 172.18.1.48 remote 172.18.1.1
HOST1: ip link set grel1 up
HOST1: iptables -I INPUT -p gre -s 172.18.1.1 -j ACCEPT

тунель заработал. НО! нет адреса внутри тунеля у машины с Debian 7.5

Ninjatrasher
() автор топика
Ответ на: комментарий от Ninjatrasher

Вместо 172.18.1.48 укажи 172.18.1.50 на дебиане и cisco.

Если не заработает. То выложи обновленные конфиги cisco, debian.

Deleted
()
Ответ на: комментарий от Deleted

нет. это я к тому что при

ip link add gre1 type gre1  local 172.18.1.48 remote 172.18.1.1
ip link set gre1 up
iptables -I INPUT -p gre -s 172.18.1.1 -j ACCEPT

тунель поднимает. но машина с дебианом не получает адреса внутри тунеля, это для меня это очень критично.

это я к тому что ты говорил, что ошибка в адресе 172.18.1.48, получается, что с ip все правильно. ошибка, где то глубже в debian 7.5, либо в неправильном синтаксе при поднятии тунеля через interfaces.

так что тема еще далеко не закрыта)

Ninjatrasher
() автор топика
Ответ на: комментарий от Deleted

ну я тебе говорю, при выполнение команд, которые я указал выше, тунель до циски поднимается. идут пинги до циски и пинги внутрь тунеля. но машина без ip адреса внутри туннеля.

Ninjatrasher
() автор топика
Ответ на: комментарий от Deleted

ты можешь нормально обьяснить, в чем смысл менять 1.48 на 1.50? я решил поднять тунель руками, для этого использовал следующие команды

ip link add gre1 type gre1  local 172.18.1.48 remote 172.18.1.1
ip link set gre1 up
iptables -I INPUT -p gre -s 172.18.1.1 -j ACCEPT
ТУНЕЛЬ ПОДНЯЛСЯ. но у машины с дебианом в данном случае нет ip адреса внутри тунеля. она может пинговать 172.18.0.49. но с циски я могу ее пинговать только по 172.18.1.48. В чем будет отличие если я сменю на циске и на машине адрес?

Ninjatrasher
() автор топика
Ответ на: комментарий от Ninjatrasher

Адрес сети - это не адрес хоста. Пинговать можно, но при определённых условиях.

Просто поменяй IP-адрес и сделай по стандарту и проверяй.

Deleted
()
Ответ на: комментарий от Deleted

ну вразумительно обьяснения я так и не понял) по этому просто поменяю и на циске и на машине с дебианом ip адрес с 1.48 на 1.50 отпишусь по результату.

Ninjatrasher
() автор топика
Ответ на: комментарий от Deleted

Вы сами поднимали gre тунель с дебиана до циски? если да, тогда можно посмотреть ваш конфиг циски, и кусок файла interfaces

Ninjatrasher
() автор топика
Ответ на: комментарий от Deleted

вы сами понимаете, что пишете? что tunnel destination 172.18.1.48 - это адрес для циски со стороны unix

со стороный unix адрес тунеля это 172.18.1.1.

адрес 172.18.0.49 это адрес внутри тунеля со стороны циски адрес 172.18.0.50 это адрес внутри тунеля со стороны дебиана.

вы хоть раз тунели делали сами? или просто пишете, ради того, что бы писать?

Ninjatrasher
() автор топика

скорей всего дело не в ip адреса, а вот в чем: делаю команду на lsmod на машине с debian 6.0 получаю следующие

root@vs-msk00-prx04:/home/manage# lsmod
ip_gre                 12259  0

делаю ту же команду на машине с debian 7.5 получаю

root@vs-msk00-prx05:/home/manage# lsmod
ip_gre                 22164  0
gre                    12531  1 ip_gre

обясните, в чем различие этих двух модулей?

Ninjatrasher
() автор топика
Ответ на: комментарий от Ninjatrasher

Дело не в этом, просто с какого-то там ядра их разделили на демуксер (т.к. GRE юзается в PPTP и еще где-то) и на ip-gre модуль. Это нормально.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

не знаю, почему вы упорно грешите на циску, мое мнение проблема в дебиане, а конкретно в interfaces. но как и просил выкладываю

1.sh int tun 1

Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  Description: **** GRE to Squid server for WCCP ****
  Internet address is 172.18.0.53/30
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 172.18.1.1, destination 172.18.1.49
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255, Fast tunneling enabled
  Tunnel transport MTU 1476 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Last input 2d06h, output 2d06h, output hang never
  Last clearing of "show interface" counters 1w1d
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     6918 packets input, 814754 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     18690 packets output, 3071672 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

2. sh int tun 2

Tunnel2 is up, line protocol is up
  Hardware is Tunnel
  Description: **** GRE to vs-msk00-prx05 server for WCCP ****
  Internet address is 172.18.0.49/30
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 172.18.1.1, destination 172.18.1.48
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255, Fast tunneling enabled
  Tunnel transport MTU 1476 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Last input 00:04:36, output 01:45:35, output hang never
  Last clearing of "show interface" counters 06:26:05
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     305 packets input, 29016 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     128 packets output, 13856 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

3. sh ro

172.18.0.48/30 is directly connected, Tunnel2
L        172.18.0.49/32 is directly connected, Tunnel2
C        172.18.0.52/30 is directly connected, Tunnel1
L        172.18.0.53/32 is directly connected, Tunnel1

4. sh run int tun1 - рабочий тунель до дебиана 6.0

interface Tunnel1
 description **** GRE to Squid server for WCCP ****
 ip address 172.18.0.53 255.255.255.252
 ip mtu 1476
 ip wccp web-cache group-listen
 tunnel source 172.18.1.1
 tunnel destination 172.18.1.49
end

5. sh run tun2 - тунель до дебиана 7.5

interface Tunnel2
 description **** GRE to vs-msk00-prx05 server for WCCP ****
 ip address 172.18.0.49 255.255.255.252
 ip mtu 1476
 ip wccp web-cache group-listen
 tunnel source 172.18.1.1
 tunnel destination 172.18.1.48
end

Ninjatrasher
() автор топика
Ответ на: комментарий от Ninjatrasher

не знаю, почему вы упорно грешите на циску

Нужно увидеть картину с обеих сторон для полноты.

Я туннели поднимаю несколько иначе, попробуй убрать из interfaces его и вручную запустить, так:

/sbin/ip tunnel add gre1 remote 10.184.8.88 local 10.184.16.88 ttl 64
/sbin/ip address add dev gre1 192.168.254.1 peer 192.168.254.2
/sbin/ip link set dev gre1 mtu 1400 up
Т.е. не указывать адреса ptp в ip tunnel add, а потом в ip address add.

blind_oracle ★★★★★
()
Ответ на: комментарий от Ninjatrasher

Давай послушаем интерфейс езернетовый во время пингов:

tcpdump -i ethX -n 'proto gre'

Ну и модель цыски и версию иоса узнать неплохо бы.

Возможно, для работы нужно добавить в конфиг туннеля GRE-ключ для отличия одних пакетов от других:

/sbin/ip tunnel add gre1 key 666 remote 10.184.8.88 local 10.184.16.88 ttl 64
...
int tun1
 tunnel key 666

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle
root@vs-msk00-prx05:/home/manage# tcpdump -i eth0 -n 'proto gre'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:51:02.680057 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 1, length 64
11:51:03.689158 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 2, length 64
11:51:04.700284 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 3, length 64
11:51:05.707452 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 4, length 64
11:51:06.714601 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 5, length 64
11:51:07.725711 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 6, length 64
11:51:08.736839 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 7, length 64
11:51:09.747979 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 8, length 64
11:51:10.755127 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 9, length 64
11:51:11.762283 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 10, length 64
11:51:12.773403 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 11, length 64
11:51:13.784568 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 12, length 64
11:51:14.795678 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 13, length 64
11:51:15.802828 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 14, length 64
11:51:16.809969 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 15, length 64
11:51:17.821105 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 16, length 64
11:51:18.832228 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 17, length 64
11:51:19.839383 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 18, length 64
11:51:20.846543 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 19, length 64
11:51:21.857672 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 20, length 64
11:51:22.868843 IP 172.18.1.48 > 172.18.1.1: GREv0, length 88: IP 172.18.0.50 > 172.18.0.49: ICMP echo request, id 2617, seq 21, length 64

вот что tcpdump показывает

Ninjatrasher
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.