Packetloss от openVPN-клиента к VLAN это присоединено
я немного потерян с этим und, было бы благодарно за Вашу справку!
Сеть Установки состоит из переключателей HP V1910-24G. Целая компания, работающая в идентификаторе VLAN 100 в 192.168.2.0. Сервер, который выполняет openVPN-сервер на Сервере Ubuntu, присоединен к идентификатору VLAN 30 в 192.168.22.0.
Сервер работает: Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-70-универсальный x86_64)
В будущем, я wan't для создания нескольких VLAN с VPNs, которые соединяются с ними. Поэтому полагайте, что это установка оценки.
Интерфейсы Серверов соединены для Портирования 14 на переключателе, который настроен как это:
untagged membership: 30
tagged membership: 100
Link Type: Hybrid
PVID: 30
Интерфейсы сервера:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 4c:cc:6a:44:e0:db brd ff:ff:ff:ff:ff:ff
inet 192.168.22.100/24 brd 192.168.22.255 scope global enp2s0
valid_lft forever preferred_lft forever
inet6 fe80::4ecc:6aff:fe44:e0db/64 scope link
valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
link/none
inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::877c:3d1b:90fa:736a/64 scope link stable-privacy
valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:0c:12:89:73 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
7: VLAN_100@enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 4c:cc:6a:44:e0:db brd ff:ff:ff:ff:ff:ff
inet 192.168.2.100/24 brd 192.168.2.255 scope global VLAN_100
valid_lft forever preferred_lft forever
inet6 fe80::4ecc:6aff:fe44:e0db/64 scope link
valid_lft forever preferred_lft forever
Конфигурация openVPN
port 1194
proto udp
dev tun
ca ......
cer ......
key ......
dh ......
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
push "route 192.168.22.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3
explicit-exit-notify 1
Проблема я не могу проверить с помощью ping-запросов устройство в 192.168.2.0 сетях помимо шлюза/маршрутизатора (192.168.2.1) по соединению VPN. 99% пакетов теряются. Здесь у меня есть tcpdump, показывая пакет ping, который успешно выполнился назад к устройству проверки с помощью ping-запросов.
13:52:33.558835 In ethertype IPv4 (0x0800), length 100: 10.8.0.6 > 192.168.2.20: ICMP echo request, id 5501, seq 51, length 64
13:52:33.558862 Out 4c:cc:6a:44:e0:db ethertype IPv4 (0x0800), length 100: 10.8.0.6 > 192.168.2.20: ICMP echo request, id 5501, seq 51, length 64
13:52:33.558866 Out 4c:cc:6a:44:e0:db ethertype 802.1Q (0x8100), length 104: vlan 100, p 0, ethertype IPv4, 10.8.0.6 > 192.168.2.20: ICMP echo request, id 5501, seq 51, length 64
13:52:33.559398 In 00:1d:aa:b5:ee:e8 ethertype 802.1Q (0x8100), length 104: vlan 100, p 0, ethertype IPv4, 192.168.2.20 > 10.8.0.6: ICMP echo reply, id 5501, seq 51, length 64
13:52:33.559398 In 00:1d:aa:b5:ee:e8 ethertype IPv4 (0x0800), length 100: 192.168.2.20 > 10.8.0.6: ICMP echo reply, id 5501, seq 51, length 64
13:52:33.559427 Out ethertype IPv4 (0x0800), length 100: 192.168.2.20 > 10.8.0.6: ICMP echo reply, id 5501, seq 51, length 64
Вот пакет, который не ушел назад к клиенту VPN.
13:52:34.571763 In ethertype IPv4 (0x0800), length 100: 10.8.0.6 > 192.168.2.20: ICMP echo request, id 5501, seq 52, length 64
13:52:34.571790 Out 4c:cc:6a:44:e0:db ethertype IPv4 (0x0800), length 100: 10.8.0.6 > 192.168.2.20: ICMP echo request, id 5501, seq 52, length 64
13:52:34.571794 Out 4c:cc:6a:44:e0:db ethertype 802.1Q (0x8100), length 104: vlan 100, p 0, ethertype IPv4, 10.8.0.6 > 192.168.2.20: ICMP echo request, id 5501, seq 52, length 64
13:52:34.572286 In 00:1d:aa:b5:ee:e8 ethertype IPv4 (0x0800), length 100: 192.168.2.20 > 10.8.0.6: ICMP echo reply, id 5501, seq 52, length 64
Кажется, что что-то неправильно с vlan_tag в пакетах. Проверка с помощью ping-запросов с сервера локально хорошо работает. (192.168.2.100-> 192.168.2.20 и наоборот)
Как может, я диагностировал это? Спасибо всем!
IP шоу маршрута
default via 192.168.22.1 dev enp2s0 proto static
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.2.0/24 dev VLAN_100 proto kernel scope link src 192.168.2.100
192.168.22.0/24 dev enp2s0 proto kernel scope link src 192.168.22.100
1 ответ
Кажется, что вся эта мысль является неправильной.
С этим путем пакет ping непосредственно отправляется от сервера OpenVPN до 192.168.2.20 по VLAN 100. 192.169.2.20 ответа на 10.8.0.6, но должен отправить его ответ на шлюз (192.168.2.1), потому что он не знает 10.8.0.6. В этой точке это, вероятно, который это получает, отбросило, потому что это прибывает из другого MAC-адреса, когда это было отправлено в.
Поскольку существует шлюз так или иначе между VLAN, я просто добавил статическое правило от 192.168.22.100 до 192.168.2.0 и вице-стих от 192.168.2.0 до 10.8.0.0. Таким образом, теперь существует шлюз между сервером и всеми VLAN.