Amazon EC2: сервер OpenVPN не будет направлять мостовые пакеты от клиента в подсеть VPC

У меня есть мостовая установка OpenVPN на сервере Linux в Amazon EC2 VPC. (Потратил часы на документацию, читая похожие проблемы, здесь, форумы openVPN, пока не повезло.)

Мостовой интерфейс включен и содержит оба подчиненных интерфейса:

# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0e7c15e787b0       no              eth0
                                                        tap0

Маршрутизация на VPN-сервере, очевидно, в порядке; Я могу подключиться по SSH, пинговать, ответить на запрос VPN от клиента:

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG        0 0          0 br0
10.0.0.0        0.0.0.0         255.255.0.0     U         0 0          0 br0

я жестяная банка ping от клиентов Windows и Mac к IP-адресу VPN-сервера, но не к любому другому IP-адресу в подсети VPC. (Эти другие IP-адреса в порядке; они доступны для проверки связи с сервера VPN.)

Когда я tcpdump на мостовом интерфейсе br0 на сервере VPN это видит запросы "у кого есть ARP" от клиента Windows. Однако они не попадают в подсеть VPC! tcpdump на IP назначения не видит приходящий ARP. Кэш Windows ARP остается незаполненным. (10.0.0.128 - клиент Windows; 10.0.0.58 - VPN-сервер; 10.0.0.180 - другой IP-адрес в подсети; выходные данные ниже получены от VPN-сервера.)

root@vpn:# tcpdump -i br0 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:00:21.092367 ARP, Request who-has 10.0.0.180 tell 10.0.0.128, length 28

[сверчки]

Я отключил Source / Dest. проверьте в консоли EC2 единственный сетевой интерфейс VPN-сервера.

Я настроил IP-таблицы, как рекомендовано в HOWTO по мосту, и в целом точно следовал этим инструкциям.

# iptables -L INPUT -v
Chain INPUT (policy ACCEPT 9 packets, 1008 bytes)
 pkts bytes target     prot opt in     out     source               destination
   38 12464 ACCEPT     all  --  tap0   any     anywhere             anywhere
10447 1297K ACCEPT     all  --  br0    any     anywhere             anywhere

# iptables -L FORWARD -v
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  918  167K ACCEPT     all  --  br0    any     anywhere             anywhere

https://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html

Я не считать Мне нужно сбросить полные конфигурации, потому что, очевидно, многое работает: аутентификация, сертификаты, сжатие, пул адресов, установка соединения в целом. Неужели Amazon VPC просто отказывается пересылать пакеты, и для этого я действительно должен находиться в менее виртуальном облаке?

БОЛЬШЕ ЭКСПЕРИМЕНТОВ НА СЛЕДУЮЩИЙ ДЕНЬ: VPC явно не ведет себя как настоящая подсеть уровня 2. В частности, ARP who-has трансляции на самом деле не транслируются! Когда я пингую несуществующий IP-адрес (скажем .5) из .180, .58 не видит запрос. Очевидно, что VPC оптимизирует широковещательные передачи ARP и отправляет их только на .5, если .5 был настроен в VPC через консоль управления / API. Уходя tcpdump -vv -i eth0 arp на некоторое время показывает только трафик между хостом и шлюзом для всех хостов.

Кроме того, пинг широковещательного адреса в подсети вообще не работает. Это подтверждается FAQ по Amazon VPN.

Таким образом, VPC, скорее всего, отказывается распознавать неизвестный MAC-адрес 0,129, поскольку он не существует в собственном «виртуальном коммутаторе Ethernet». Я, вероятно, перенесу это как ответ через неделю или около того. Чтобы расширить VPC с помощью вашего собственного VPN, он должен быть через формальный «шлюз VPC», который предназначен только для работы в качестве расширения корпоративной интрасети, поддерживаемой выделенным аппаратным маршрутизатором и статическим IP-адресом, а не в сценарии роуминга портативного компьютера I ' м стремясь к.