The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Проброс 802.1q/access порта в Linux через IP-сеть
В 2007 году я написал заметку с похожим названием.

Тогда использовалась userspace-реализация с tap-интерфейсом и демоном vtund.
Особой производительностью этот вариант не отличался.
В свежих ядрах Linux появилась поддержка l2tpv3 ethernet pseudowire.

Организуем l2-линк с udp-инкапсуляцией между двумя хостами laptus и gw:

   laptus# ip l2tp add tunnel tunnel_id 1 peer_tunnel_id 1 udp_sport 5000 \\
      udp_dport 5000 encap udp local 192.168.1.39 remote 213.x.x.x
   laptus# ip l2tp add session tunnel_id 1 session_id 1 peer_session_id 1
   laptus# ip a a 192.168.30.2/24 dev l2tpeth0

   gw# ip l2tp add tunnel tunnel_id 1 peer_tunnel_id 1 udp_sport 5000 \\
      udp_dport 11932 encap udp local 213.x.x.x remote 188.134.x.x
   gw# ip l2tp add session tunnel_id 1 session_id 1 peer_session_id 1
   gw# ip a a 192.168.30.1/24 dev l2tpeth0

(так как машина laptus на NAT, то пришлось сначала сконфигурировать туннель на
нём и запустить ping 192.168.30.1 и на внешнем интерфейсе gw "подсмотреть"
ip:port, в который оттранслировались пакеты на выходе. Если у вас на обоих
концах публичные ip - всё просто).

Теперь попробуем сделать что-то полезное:

   laptus# ip link add link l2tpeth0 name vlan5 type vlan id 5
   laptus# ip link add link l2tpeth0 name vlan6 type vlan id 6
   laptus# ip a a dev vlan5 10.1.5.2/24
   laptus# ip a a dev vlan6 10.1.6.2/24

   gw# ip link add link l2tpeth0 name vlan5 type vlan id 5
   gw# ip link add link l2tpeth0 name vlan6 type vlan id 6
   gw# ip a a dev vlan5 10.1.5.1/24
   gw# ip a a dev vlan6 10.1.6.1/24

   laptus# ping 10.1.6.1
   PING 10.1.6.1 (10.1.6.1) 56(84) bytes of data.
   64 bytes from 10.1.6.1: icmp_req=1 ttl=64 time=5.77 ms
   64 bytes from 10.1.6.1: icmp_req=2 ttl=64 time=13.4 ms
   64 bytes from 10.1.6.1: icmp_req=3 ttl=64 time=17.6 ms
   ^C
   --- 10.1.6.1 ping statistics ---
   3 packets transmitted, 3 received, 0% packet loss, time 2002ms
   rtt min/avg/max/mdev = 5.776/12.295/17.671/4.922 ms

при этом tcpdump -e -n -i l2tpeth0 на gw покажет:

   16:44:30.055082 b2:19:70:63:90:85 > 76:a9:12:12:c7:30, ethertype IPv4 (0x0800), length 98: 192.168.30.2 > 192.168.30.1: ICMP echo request, id 26927, seq 1376, length 64
   16:44:30.055116 76:a9:12:12:c7:30 > b2:19:70:63:90:85, ethertype IPv4 (0x0800), length 98: 192.168.30.1 > 192.168.30.2: ICMP echo reply, id 26927, seq 1376, length 64
   16:44:30.990689 b2:19:70:63:90:85 > 76:a9:12:12:c7:30, ethertype 802.1Q (0x8100), length 102: vlan 6, p 0, ethertype IPv4, 10.1.6.2 > 10.1.6.1: ICMP echo request, id 27037, seq 2, length 64
   16:44:30.990734 76:a9:12:12:c7:30 > b2:19:70:63:90:85, ethertype 802.1Q (0x8100), length 102: vlan 6, p 0, ethertype IPv4, 10.1.6.1 > 10.1.6.2: ICMP echo reply, id 27037, seq 2, length 64

l2tpeth можно объединить бриджом с физическим интерфейсом. 
выглядит это примерно так:

   root@atomus:~# ip a s l2tpeth0

   7: l2tpeth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vl0 state UNKNOWN qlen 1000
    link/ether 1e:7f:ec:bd:cf:6a brd ff:ff:ff:ff:ff:ff

   root@atomus:~# ip a s vl0

   9: vl0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 1e:7f:ec:bd:cf:6a brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.10/24 brd 10.1.1.255 scope global vl0

   root@atomus:~# ip a s vlan5

   11: vlan5@vl0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 1e:7f:ec:bd:cf:6a brd ff:ff:ff:ff:ff:ff
    inet 10.1.5.10/24 brd 10.1.5.255 scope global vlan5

   root@atomus:~# ip a s vlan222

   12: vlan222@vl0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 1e:7f:ec:bd:cf:6a brd ff:ff:ff:ff:ff:ff
    inet 10.1.222.10/24 brd 10.1.222.255 scope global vlan222

   root@atomus:~# brctl show

   bridge name     bridge id               STP enabled     interfaces
   vl0             8000.1e7fecbdcf6a       no              l2tpeth0

   root@gw:~# ip a s vlan222

   68: vlan222@l2tpeth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1488 qdisc noqueue state UP 
       link/ether c6:8c:43:30:88:03 brd ff:ff:ff:ff:ff:ff
       inet 10.1.222.1/24 brd 10.1.222.255 scope global vlan222

   root@gw:~# ip a s l2tpeth0

   64: l2tpeth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether c6:8c:43:30:88:03 brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.1/24 brd 10.1.1.255 scope global l2tpeth0

   root@atomus:~# ping 10.1.5.1
   PING 10.1.5.1 (10.1.5.1) 56(84) bytes of data.
   64 bytes from 10.1.5.1: icmp_req=1 ttl=64 time=6.37 ms
   64 bytes from 10.1.5.1: icmp_req=2 ttl=64 time=5.53 ms
   ......

   root@atomus:~# ping 10.1.222.1
   PING 10.1.222.1 (10.1.222.1) 56(84) bytes of data.
   64 bytes from 10.1.222.1: icmp_req=1 ttl=64 time=10.0 ms
   64 bytes from 10.1.222.1: icmp_req=2 ttl=64 time=4.24 ms
   .....

Как видим, к нам приходит тегированный трафик:

   root@gw:~# tcpdump -n -e -i l2tpeth0

   tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
   listening on l2tpeth0, link-type EN10MB (Ethernet), capture size 65535 bytes
   19:21:33.962979 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype 802.1Q (0x8100), length 102: vlan 5, p 0, ethertype IPv4, 10.1.5.10 > 10.1.5.1: ICMP echo request, id 3765, seq 139, length 64
   19:21:33.963047 c6:8c:43:30:88:03 > 1e:7f:ec:bd:cf:6a, ethertype 802.1Q (0x8100), length 102: vlan 5, p 0, ethertype IPv4, 10.1.5.1 > 10.1.5.10: ICMP echo reply, id 3765, seq 139, length 64
   19:21:33.986660 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype 802.1Q (0x8100), length 102: vlan 222, p 0, ethertype IPv4, 10.1.222.10 > 10.1.222.1: ICMP echo request, id 3764, seq 149, length 64
   19:21:33.986698 c6:8c:43:30:88:03 > 1e:7f:ec:bd:cf:6a, ethertype 802.1Q (0x8100), length 102: vlan 222, p 0, ethertype IPv4, 10.1.222.1 > 10.1.222.10: ICMP echo reply, id 3764, seq 149, length 64
   19:21:35.165848 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype 802.1Q (0x8100), length 102: vlan 5, p 0, ethertype IPv4, 10.1.5.10 > 10.1.5.1: ICMP echo request, id 3765, seq 140, length 64
   19:21:35.165903 c6:8c:43:30:88:03 > 1e:7f:ec:bd:cf:6a, ethertype 802.1Q (0x8100), length 102: vlan 5, p 0, ethertype IPv4, 10.1.5.1 > 10.1.5.10: ICMP echo reply, id 3765, seq 140, length 64
   19:21:35.168489 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype 802.1Q (0x8100), length 102: vlan 222, p 0, ethertype IPv4, 10.1.222.10 > 10.1.222.1: ICMP echo request, id 3764, seq 150, length 64
   ...

а тут уже тегов нет:

   root@gw:~# tcpdump -n -e -i vlan5   

   tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
   listening on vlan5, link-type EN10MB (Ethernet), capture size 65535 bytes
   19:22:17.038686 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype IPv4 (0x0800), length 98: 10.1.5.10 > 10.1.5.1: ICMP echo request, id 3765, seq 182, length 64
   19:22:17.038759 c6:8c:43:30:88:03 > 1e:7f:ec:bd:cf:6a, ethertype IPv4 (0x0800), length 98: 10.1.5.1 > 10.1.5.10: ICMP echo reply, id 3765, seq 182, length 64
   19:22:18.041890 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype IPv4 (0x0800), length 98: 10.1.5.10 > 10.1.5.1: ICMP echo request, id 3765, seq 183, length 64
   19:22:18.041935 c6:8c:43:30:88:03 > 1e:7f:ec:bd:cf:6a, ethertype IPv4 (0x0800), length 98: 10.1.5.1 > 10.1.5.10: ICMP echo reply, id 3765, seq 183, length 64


   root@gw:~# tcpdump -n -e -i vlan222

   tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
   listening on vlan222, link-type EN10MB (Ethernet), capture size 65535 bytes
   19:23:14.155061 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype IPv4 (0x0800), length 98: 10.1.222.10 > 10.1.222.1: ICMP echo request, id 3764, seq 249, length 64
   19:23:14.155100 c6:8c:43:30:88:03 > 1e:7f:ec:bd:cf:6a, ethertype IPv4 (0x0800), length 98: 10.1.222.1 > 10.1.222.10: ICMP echo reply, id 3764, seq 249, length 64
   19:23:15.150799 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype IPv4 (0x0800), length 98: 10.1.222.10 > 10.1.222.1: ICMP echo request, id 3764, seq 250, length 64
   19:23:15.150833 c6:8c:43:30:88:03 > 1e:7f:ec:bd:cf:6a, ethertype IPv4 (0x0800), length 98: 10.1.222.1 > 10.1.222.10: ICMP echo reply, id 3764, seq 250, length 64

если требуется "протащить" несколько trunk-интерфейсов, то достаточно сказать:

   ip l2tp add session tunnel_id 1 session_id 2 peer_session_id 2

В рамках одно туннеля может быть 65535 сессий.
 
05.02.2012 , Автор: Roman Timofeev
Ключи: ip, tunnel, vlan, l2tpv3, ethernet / Лицензия: CC-BY
Раздел:    Корень / Администратору / Сетевая подсистема, маршрутизация / Туннелинг, VPN, VLAN

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, anonymous (??), 15:17, 06/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Красиво конечно, но как я понимаю поддержка на уровне ядра появилась в 3.2? До поддержки в продакшин-ориентированных дистрибутивах еще ждать и ждать.
     
     
  • 2.3, ragus (ok), 16:11, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    поддержка появилась в 2.6.35
    единственное условие - это свежий iproute2, т.к. userspace часть несколько отстаёт от kernel.

    я брал самый свежий тут: http://mirror.yandex.ru/debian/pool/main/i/iproute/
    и собирал пакет под себя.

     
  • 2.14, vvvua (ok), 15:27, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Красиво конечно, но как я понимаю поддержка на уровне ядра появилась в
    > 3.2? До поддержки в продакшин-ориентированных дистрибутивах еще ждать и ждать.

    3.0 debian есть. Ниже говорят, что с 2.6.35 появилось.
    только нужно



    modprobe l2tp_netlink



    сделать.

     

  • 1.2, anonymous (??), 15:23, 06/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Какая версия iproute2 нужна?
    В 3.1 нет еще ip l2tp
    Решение интересное.
    Я так понимаю, на nag'е вы известны как rage?
     
     
  • 2.4, ragus (ok), 16:14, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Какая версия iproute2 нужна?
    > В 3.1 нет еще ip l2tp

    iproute2 - это просто утилита, которая обменивается с ядром сообщениями.

    > Решение интересное.
    > Я так понимаю, на nag'е вы известны как rage?

    да, верно. хочу добавить, что вариант, по идее, должен быть совместим с xconnect у cisco.


     
     
  • 3.6, anonymous (??), 16:47, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Я не совсем верно выразился - в моей генте версии пакета iproute именуются так:
    ls -1 /usr/portage/sys-apps/iproute2/
    ChangeLog
    files
    iproute2-2.6.29.1-r1.ebuild
    iproute2-2.6.35-r2.ebuild
    iproute2-2.6.35-r3.ebuild
    iproute2-2.6.38.ebuild
    iproute2-3.1.0.ebuild
    iproute2-9999.ebuild

    Стояла, соответственно, версия 3.1.0)

     

  • 1.5, vvvua (ok), 16:46, 06/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вариант с vtund хоть и тормозной, но есть 2 больших плюса:
    1) легко шифровать (решаемо и тут, но чуть сложнее
    2) если мы за натом и/или адрес динамический - то нужен бубен...
     
     
  • 2.8, ragus (ok), 17:08, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    вариант с vtund - это несколько для другого: l2/l3 vpn для себя и небольшого количества коллег и доступом из любой глухомани за nat/double nat/etc

    А l2tpv3 - это для промышленного применения, больших пакетрейтов и объёмов трафика.

     
     
  • 3.19, vvvua (ok), 18:50, 24/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вот созрела надобность в связи узлов CDN.
    >А l2tpv3 - это для промышленного применения, больших пакетрейтов и объёмов трафика.

    Нет случайно данных о скорости относительно OpenVPN с tun/tap и GRE туннелей?
    В принципе, скорей всего, захотят слать multicast. Это ведёт к сравнению tap/GRE/l2tpv3 ...

     

  • 1.9, a (??), 22:16, 06/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я бы не рискнул это делать в продакшен сети. Прежде всего это не грамотно выстроенная архитектура сети. Но иногда такое решение очень сильно спасает.
     
     
  • 2.15, ragus (ok), 02:56, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    простите, а причём тут неграмотная архитектура?
    l2tpv3 - рекомендуемое циской решение для vpn, если без mpls.
     

  • 1.10, McLeod095 (??), 12:01, 07/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Fedora 16/x64
    ip l2tp
    Object "l2tp" is unknown, try "ip help".

    Видимо для CentOS еще долго не будет

     
     
  • 2.11, Stax (ok), 12:36, 07/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    В F16 вы прямо сейчас можете пересобрать http://koji.fedoraproject.org/koji/buildinfo?buildID=281521 - если не хочется ждать F17, где будет из коробки.

    Для центос это вопрос.. иногда в очередном релизе ред хат обновляет такие штуки до последних версий. Но тут, скорее всего, нужны платные клиенты, возжелавшие этой фичи в редхатовской багзилле.

     
  • 2.16, ragus (ok), 02:58, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Fedora 16/x64
    > ip l2tp
    > Object "l2tp" is unknown, try "ip help".
    > Видимо для CentOS еще долго не будет

    появилось в 2.6.35, требует свежего iproute2.

     

  • 1.17, ragus (ok), 05:26, 23/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    хочу уточнить:
    сессий внутри туннеля может быть не 65535, а 2^32-1, т.е. 4294967295
     
  • 1.18, Брызгалов Константин (ok), 10:02, 16/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Автор, молодец! Спасибо за труд.
     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру