В 2007 году я написал [[http://www.opennet.me/tips/info/1389.shtml эаметку]] с похожим названием.Тогда использовалась 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 сессий.
URL:
Обсуждается: http://www.opennet.me/tips/info/2664.shtml
