Некоторым в первую очередь нужны грубые основы:

• Есть маршрутизация, то есть IP-адреса и пакеты на уровне 3.
• Есть коммутация, то есть MAC-адреса и кадры на уровне 2.

Далее вы говорите о vmbr0 / 1/30, но в вашей конфигурации отображаются только 0 и 30. Shorewall не имеет значения для вашего подключения к виртуальной машине (iptables - это layer3, ebtables будет Layer2 для контраста, но ваши кадры должны просто летать мимо shorewall, не доходя до HV, а вместо этого переходя непосредственно к виртуальной машине. Shorewall - это просто интерфейс, использующий iptables на заднем фоне).

С этим в стороне:

Обычно маршрутизация на МОСТах proxmox не требуется. Для вас мост - это переключатель. vmbr0 - это виртуальный внешний мост, который вы связали с eth0 (таким образом, создавая внутреннюю связь между физическим ником и вашим виртуальным интерфейсом, чтобы пакеты вообще передавались). Мост также может работать без привязанного к нему IP-адреса. Но для того, чтобы HV был доступен, обычно к нему подключается внешний IP-адрес. В противном случае вам придется настроить шлюз брандмауэра плюс VPN-туннель, дать vmbr30 внутренний IP-адрес, а затем вы сможете получить доступ к внутреннему IP-адресу HV из Интернета после установления туннельного соединения, но пока это только для целей иллюстрации.

Проблема с подключением к ipsec ужасно похожа на неправильно настроенный VPN, но также мобильный IPSEC часто является проблемой для работы из-за различий в реализации протоколов, openvpn работает НАМНОГО лучше, но вы должны знать свои основы PKI и сертификатов. чтобы реализовать это. Плюс, если opnsense так же нелогичен, как pfsense, когда дело доходит до openvpns, вы, возможно, в течение недели легко столкнетесь с темнотой. Для pfsense есть устанавливаемый пакет экспорта конфигурации openvpn, который значительно упрощает жизнь, не знаю, доступен ли он и для opnsense.

Это не столько похоже на то, что вы называете асинхронной маршрутизацией, сколько на проблему с брандмауэром, которая у вас возникла в отношении первого изображения. Для вашего туннельного брандмауэра (интерфейс IPSEC или интерфейс openvpn на opnsense, в зависимости от туннеля, который вы используете) просто оставьте его на ipv4 any: any to any: any, вы должны попасть в сеть LAN в любом случае только по определению туннеля. Сам по себе opnsense будет автоматически отправлять пакеты только через интерфейс LAN, как показано на втором рисунке.

net.ipv4.ip_forward = 1 = включить маршрутизацию в ядре на всех интерфейсах ОС Linux, где вы ее активировали. Вы можете выполнять NAT-ting через iptables, тем самым делая возможным проникновение в вашу локальную сеть, теоретически используя внешний IP-адрес HV на vmbr0, но это не то, чего вы должны достичь случайно, вы можете снова отключить пересылку без потери связи. По крайней мере, для HV, я не уверен, есть ли у вас дополнительные маршруты для других внешних IP-адресов, но они должны быть настроены таким же образом изнутри opnsense напрямую (создайте там двухточечные ссылки, кадры будут прозрачно проходить через vmbr0 и eth0 на шлюз hetzner) и работать, что бы чище.

Кроме того, вам не следует делать виртуальную машину ранчера доступной извне напрямую и, таким образом, в обход вашего брандмауэра, я сомневаюсь, что это то, чего вы хотите достичь. Вместо этого поместите внешний IP-адрес в opnsense (как виртуальный IP-адрес типа ip alias), настройте NAT 1: 1 с IP3 на внутренний IP-адрес rancher-vm и выполните межсетевой экран через opnsense.

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

[hetzner gw]
  |
  |
  |
[eth0] (everything below happens inside your server)
  ||
  || (double lines here to hint at the physical-virtual linking linux does)
  || (which is achieved by linking eth0 to vmbr0)
  ||
  || +-- HV acess to via IP1 -- shorewall/iptables for hv firewalling 
  || |
[vmbr0]                                                    [vmbr30]
 IP1                                                        | | |
  |                                                         | | |
  |                                                         | | |
[wan nic opn]                                               | | | 
  IP2 on wan directly,                                      | | |
  IP3 as virtual IP of type ip alias                        | | |
  x                                                         | | |
  x (here opn does routing/NAT/tunnel things)               | | |
  x                                                         | | |
  x set up 1:1 NAT IP3-to-10.1.7.11 in opn for full access  | | |
  x set up single port forwardings for the 2nd vm if needed | | |
  x                                                         | | |
[lan nic opn]-----------------------------------------------+ | |
 10.1.7.1                                                     | |
                                                              | |
                                                   +----------+ |
                                                   |            |
                                              [vm1 eth0]   [vm2 eth0]
                                               10.1.7.11    10.1.7.151

Если вы также хотите настроить брандмауэр HV через opnsense, следующие шаги должны быть выполнены при сохранении возможности подключения:

1. удалить IP1 из [vmbr0]
2. надень это [wan nic opn]
3. поместите внутренний IP (IP_INT) из opn lan на [vmbr30]
4. настроить NAT 1: 1 с IP
5. установить все правила брандмауэра
6. ругаться как черт, когда вы ломаете брандмауэр и больше не можете добраться до hv
7. посмотрите, можете ли вы получить доступ к HV через решение iKVM, надеясь получить на него общедоступный IP-адрес, поэтому вы можете использовать окно консоли в proxmox, надеясь исправить или переустановить брандмауэр.