Proxmox с OPNsense в качестве брандмауэра /GW - проблема маршрутизации
Эта настройка должна основываться на Proxmox, находящемся за виртуальной машиной opnsense, размещенной на самом Proxmox, которая будет защищать Proxmox, предлагать брандмауэр, приватную локальную сеть и DHCP/DNS для виртуальных машин и предлагать IPsec-соединение с локальной сетью для доступа ко всем виртуальным машинам. /Proxmox, которые не являются NAT. Сервер является типичным сервером Hetzner, поэтому только на NIC, но несколько IP-адресов или / подсетей на этом NIC.
Из-за кластерного блокиратора с настройкой PCI-passthrough это моя альтернатива
- Сервер Proxmox с 1 сетевой картой (eth0)
- 3 общедоступных 1IP, IP2/3 маршрутизируются MAC в центре обработки данных (до eth0)
- Настройка моста KVM ( eth0 no ip, vmbr0 соединен с eth0 с IP1)
- Частная сеть на vmbr30, 10.1.7.0/24
- Shorewall на сервере Proxmox
Чтобы лучше обрисовать схему, я создаю этот чертеж: (не уверен, что он идеален, скажите, что нужно улучшить)
Текстовое описание:
Сетевые интерфейсы на Proxmox
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
pre-up sleep 2
auto vmbr0
# docs at
iface vmbr0 inet static
address External-IP1(148.x.y.a)
netmask 255.255.255.192
# Our gateway is reachable via Point-to-Point tunneling
# put the Hetzner gateway IP address here twice
gateway DATACENTER-GW1
pointopoint DATACENTER-GW1
# Virtual bridge settings
# this one is bridging physical eth0 interface
bridge_ports eth0
bridge_stp off
bridge_fd 0
pre-up sleep 2
bridge_maxwait 0
metric 1
# Add routing for up to 4 dedicated IP's we get from Hetzner
# You need to
# opnsense
up route add -host External-IP2(148.x.y.b)/32 dev vmbr0
# rancher
up route add -host External-IP2(148.x.y.c)/32 dev vmbr0
# Assure local routing of private IPv4 IP's from our
# Proxmox host via our firewall's WAN port
up ip route add 10.1.7.0/24 via External-IP2(148.x.y.b) dev vmbr0
auto vmbr30
iface vmbr30 inet static
address 10.1.7.2
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0
pre-up sleep 2
metric 1
Shorewall на Proxmox
интерфейсы
wan eth0 detect dhcp,tcpflags,nosmurfs
wan vmbr0 detect bridge
lan vmbr30 detect bridge
политика:
lan lan ACCEPT - -
fw all ACCEPT - -
all all REJECT INFO -
OPNsense
- WAN - это ExternalIP2, подключенный к vmbr0 с MAC-XX
- ЛВС 10.1.7.1, подключена к vmbr30
Что работает:
- Базовая настройка работает нормально, я могу получить доступ к opnsense с IP2, я могу получить доступ к proxmox на IP1 и получить доступ к rancher-VM на ip3 - это то, что не требует никакой маршрутизации.
- я могу подключиться с помощью мобильного клиента IPSec к OPNsense, предлагая доступ к локальной сети (10.1.7.0/24) из виртуального диапазона IP-адресов 172.16.0.0/24
- я могу получить доступ к 10.1.7.1 ( opnsense) при подключении к OpenVPN
- я могу получить доступ к 10.1.7.11 / 10.1.7.151 из OPNsense(10.1.7.1) (оболочка)
- я могу получить доступ к 10.1.7.11 / 10.1.7.1 из othervm(10.1.7.151) (shell)
Что не работает:
а) подключение к 10.1.7.11/10.1.7.151 или 10.1.7.2 от клиента IPsec
b) [решено в ОБНОВЛЕНИИ 1] с подключением к 10.1.7.2 из 10.1.7.1 ( opnsense)
c) Кажется, у меня асинхронная маршрутизация, и хотя я могу получить доступ, например, 10.1.7.1:8443, я вижу много записей
d) Совместное использование локальной сети IPSec будет включать в себя правило в цепочке IPSEC, "от * к LAN ACCEPT" - но это не сработало для меня, мне пришлось добавить "from * to * ACCEPT" 
Вопросы:
I) Конечно, я хочу исправить a) b) c) d), вероятно, начиная с понимания c) и d)
II) Поможет ли в этой настройке добавить второй сетевой адаптер?
III) может ли это быть проблема, что я активировал net.ipv4.ip_forward на хосте proxmox (не следует ли его скорее маршрутизировать?)
Когда я это выясню, мне очень хотелось бы разместить подробное руководство о том, как запустить OPNsense в качестве устройства с частной сетью в Proxmox, передавая некоторые сервисы во внешний мир с помощью HAproxe+LE, а также получая доступ к частной локальной сети с помощью IPsec.
Update1:
Удаление up ip route add 10.1.7.0/24 via IP2 dev vmbr0 из vmbr0 на proxmox исправлена ошибка, из-за которой ни proxmax не мог получить доступ к 10.1.7.0/24, ни к нему не мог быть доступ из сети LAN.
UPDATE2:
Я создал обновленную / измененную настройку, где используется pci-passthrough. Цели одинаковые - это снижает сложность - смотрите здесь
1 ответ
Некоторым в первую очередь нужны были грубые основы:
- Есть маршрутизация, которая является IP-адресами и пакетами на layer3.
- Там есть переключение, которое MAC и кадры на layer2.
Далее вы говорите о vmbr0/1/30, но в вашей конфигурации отображаются только 0 и 30. Shorewall не имеет значения для вашего подключения к vm (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 автоматически отправляет пакеты только из интерфейса локальной сети на втором изображении.
net.ipv4.ip_forward = 1 = включить маршрутизацию в ядре вообще на интерфейсах ОС Linux, где вы его активировали. Вы можете выполнять NAT-ting через iptables, что позволяет теоретически войти в вашу ЛВС с помощью внешнего HV IP на vmbr0, но это не то, чего вы должны достичь случайно, вы можете снова отключить переадресацию без потери связи. По крайней мере, для HV, я не уверен в том, есть ли у вас дополнительные маршруты для других внешних IP-адресов, но они должны настраиваться таким же образом изнутри opnsense напрямую (создавайте двухточечные связи там, кадры будут прозрачно проходить через vmbr0 и eth0 до шлюза hetzner) и работа, которая будет чище.
Кроме того, вы не должны делать Rancher-VM доступным извне напрямую и, таким образом, обходить брандмауэр, я сомневаюсь, что это то, чего вы хотите достичь. Вместо этого поместите внешний ip в opnsense (как виртуальный ip псевдонима типа ip), установите 1:1 NAT с 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, это будет сделано при сохранении подключения:
- удалить IP1 из [vmbr0]
- наденьте его [wan nic opn]
- поместите внутренний ip (IP_INT) из opn lan на [vmbr30]
- настроить 1:1 NAT от IP
- установить все правила брандмауэра
- ругаться до чертиков, когда ты нарушаешь брандмауэр и больше не можешь достичь hv
- Посмотрите, можете ли вы получить доступ к HV через решение iKVM, надеясь получить на него общедоступный IP-адрес, чтобы вы могли использовать окно консоли в Proxmox, надеясь исправить или переустановить брандмауэр.