Przekierowania do hostów na Proxmox

@roobal Tak, network manager wyłączony. Faktycznie po wpisaniu br0 chyba jest ok teraz kwestia do konfigurowania w samym OPN-ie. Bridge-utils był instalowany. A wczoraj wertując po necie zauważyłem, że można zrobić bridga przez Network Managera oraz samego VM. Czy to jedno z drugim jest powiązane (Network Manager z Virt Managerem)?

@anon58841377 - Szczerze powiedziawszy dla mnie nie wiem czy byłoby łatwiej. Znam OPNsensa ponieważ mam go od kilku lat na starym Fujitsu Futro s550-2, na dodatek ma bardzo fajną dokumentację. Problem w tym, że na FF brakuje RAM-u i jedna karta jest Realteka - co mi uniemożliwia zrobienie IPS IDS + GeoIP (nie ma wsparcia przy tych kartach ). Dodatkowo procesor nie wspiera aesni.
I trochę chciałem pobawić się wirtualizacją.

Swoją drogą czytając i szperając wpadłem na https://xcp-ng.org macie może jakieś opinie na jego temat?

Ale squid to jest super sprawa i może robić za niby firewalla,ja np. blokuje sobie squidem skrypty śledzące.Wpisuje sobie

tail -f /var/log/squid/access.log

i patrze sobie na stronie jakie tam są adresy i blokuje śledzenie.

natomiast z samego firewalla nie będziesz mieć aż takiej kontroli.

NetworkManagerem można, ale on nie współpracuje z libvirt, może dlatego nie widzi Ci br0 tylko musisz wpisać z palca.

Stworzyłem br-WAN z przekierowaniem wprost do karty enp3s0 oraz br-LAN z włączonym DHCP. Kiedy br-WAN jest nieaktywny, mam połączenie z maszyną, działają DNS-y, VNC itd. Po włączeniu br-WAN adres jest przypisany prawidłowy natomiast nie mam kompletnie dns-ów, nawet pingi nie chodzą.

Dodały się wpisy w /etc/network/interfaces

# ifupdown has been replaced by netplan(5) on this system. See
# /etc/netplan for current configuration.
# To re-enable ifupdown on this system, you can run:
# sudo apt install ifupdown

auto br-wan
iface br-wan inet dhcp
bridge_ports enp3s0
bridge_stp on
bridge_fd 0.0
auto br-lan
iface br-lan inet static
address 172.30.200.0
netmask 255.255.255.0
gateway 172.30.200.1
bridge_ports enp2s0f0
bridge_stp on
bridge_fd 0.0

Poprawka, udało się zalogować po SSH do serwera

Imgur

a systemd-resolve --status daje poprawne wyniki dla serwerów DNS-owych, więc o co c’mon?

daniel@srv01vm:~$ systemd-resolve --status
Global
     DNS Servers: 10.0.17.2
                  10.0.145.3
                  10.0.145.2
      DNS Domain: xx.xx
      DNSSEC NTA: 10.in-addr.arpa
                  16.172.in-addr.arpa
                  168.192.in-addr.arpa
                  17.172.in-addr.arpa
                  18.172.in-addr.arpa
                  19.172.in-addr.arpa
                  20.172.in-addr.arpa
                  21.172.in-addr.arpa
                  22.172.in-addr.arpa
                  23.172.in-addr.arpa
                  24.172.in-addr.arpa
                  25.172.in-addr.arpa
                  26.172.in-addr.arpa
                  27.172.in-addr.arpa
                  28.172.in-addr.arpa
                  29.172.in-addr.arpa
                  30.172.in-addr.arpa
                  31.172.in-addr.arpa
                  corp
                  d.f.ip6.arpa
                  home
                  internal
                  intranet
                  lan
                  local
                  private
                  test

Link 8 (virbr0-nic)
  Current Scopes: none
   LLMNR setting: yes
MulticastDNS setting: no
  DNSSEC setting: no
DNSSEC supported: no

Link 7 (virbr0)
  Current Scopes: none
   LLMNR setting: yes
MulticastDNS setting: no
  DNSSEC setting: no
DNSSEC supported: no

Link 6 (br-wan)
  Current Scopes: none
   LLMNR setting: yes
MulticastDNS setting: no
  DNSSEC setting: no
DNSSEC supported: no

Link 5 (br-lan)
  Current Scopes: none
   LLMNR setting: yes
MulticastDNS setting: no
  DNSSEC setting: no
DNSSEC supported: no

Link 4 (enp2s0f1)
  Current Scopes: none
   LLMNR setting: yes
MulticastDNS setting: no
  DNSSEC setting: no
DNSSEC supported: no

Link 3 (enp2s0f0)
  Current Scopes: none
   LLMNR setting: yes
MulticastDNS setting: no
  DNSSEC setting: no
DNSSEC supported: no

Link 2 (enp3s0)
  Current Scopes: none
   LLMNR setting: yes
MulticastDNS setting: no
  DNSSEC setting: no
DNSSEC supported: no
daniel@srv01vm:~$

Znalazłem takie rozwiązanie przy pomocy Open vSwitch - i chyba to będzie lekarstwo na moją niewiedzę jednak wolę Was spytać, jako że jestem cienki jak sik pająka w routingu i sieciach

Ok dopiąłem swojego i udało się spełnić założenia.
Hypervisor to ubuntu server w wersji 18.04 LTS . Pytanie jakie teraz mi się nasuwa to, jak samego hypervisora skonfigurować, żeby dostał adresację z LAN, a nie z WAN.

Może opiszę co mam i jaki jest stan na tą chwilę:

Hypervisor - trzy interfejsy sieciowe : WAN (enp3s0) , LAN (enp2s0f0) i jeden wolny (enp2s0f1). Hypervisor dostaje z sieci (ISP) adres 10.0.32.98 (oczywiście to tylko lab).

Br0 i Br1 udało się zrobić za pomocą netplan’a.

network:
ethernets:
    enp2s0f0:
        dhcp4: true
    enp2s0f1:
        dhcp4: true
    enp3s0:
        dhcp4: false
version: 2


bridges:
    br0:
        interfaces: [enp3s0]
        addresses: [10.0.32.98/24]
        gateway4: 10.0.32.1
        mtu: 1500
        nameservers:
           addresses: [10.0.17.2]
        parameters:
           stp: true
           forward-delay: 4
        dhcp4: false
        dhcp6: false

    br1:
        interfaces: [enp2s0f0]
        dhcp4: false
        dhcp6: false

daniel@srv01vm:/etc/netplan$ brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.9abae9f8ea55       yes             enp3s0
                                                        vnet0
br1             8000.d209d7a02fdb       no              enp2s0f0
                                                        vnet1
virbr0          8000.52540009a24c       yes             virbr0-nic


daniel@srv01vm:/etc/netplan$  virsh net-list --all
 Name                 State      Autostart     Persistent
----------------------------------------------------------
 br0                  active     yes           yes
 br1                  active     yes           yes
 default              active     yes           yes

Maszyny na KVM-ie


OPNsense który ma podpięty br0 (jako wan) i br1 (jako lan). Wan ustawiony na DHCP i dostał 10.0.32.108. Co prawda dostępu z zewnątrz nie ma, tylko z LAN-a (172.30.200.1). Ale jak to wyglądałoby w realnym środowisku, gdzie od ISP dostałem tylko jeden adres IP? Od strony sieci ISP czyli 10.0.32.0 mogę tylko poprzez SSH dostać się na Hypervisora po porcie 22.

daniel@srv01vm:/etc/netplan$ ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.32.98  netmask 255.255.255.0  broadcast 10.0.32.255
        inet6 fe80::98ba:e9ff:fef8:ea55  prefixlen 64  scopeid 0x20<link>
        ether 9a:ba:e9:f8:ea:55  txqueuelen 1000  (Ethernet)
        RX packets 3516524  bytes 2832963149 (2.8 GB)
        RX errors 0  dropped 337  overruns 0  frame 0
        TX packets 2195132  bytes 1480163467 (1.4 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

br1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::d009:d7ff:fea0:2fdb  prefixlen 64  scopeid 0x20<link>
        ether d2:09:d7:a0:2f:db  txqueuelen 1000  (Ethernet)
        RX packets 17026  bytes 1620042 (1.6 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 726  bytes 79236 (79.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp2s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 00:26:55:d6:d6:2a  txqueuelen 1000  (Ethernet)
        RX packets 71807  bytes 7189148 (7.1 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 92485  bytes 78831476 (78.8 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 18  memory 0xfe8e0000-fe900000

enp2s0f1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet6 fe80::226:55ff:fed6:d62b  prefixlen 64  scopeid 0x20<link>
        ether 00:26:55:d6:d6:2b  txqueuelen 1000  (Ethernet)
        RX packets 386  bytes 37195 (37.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 35  bytes 6720 (6.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 19  memory 0xfe880000-fe8a0000

enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether c8:cb:b8:cf:dc:3b  txqueuelen 1000  (Ethernet)
        RX packets 4502259  bytes 4276680228 (4.2 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3145239  bytes 1525105243 (1.5 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 18

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 3321  bytes 319769 (319.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3321  bytes 319769 (319.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:09:a2:4c  txqueuelen 1000  (Ethernet)
        RX packets 188858  bytes 10611806 (10.6 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 451681  bytes 678468077 (678.4 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::fc54:ff:fe20:35a5  prefixlen 64  scopeid 0x20<link>
        ether fe:54:00:20:35:a5  txqueuelen 1000  (Ethernet)
        RX packets 313619  bytes 23926935 (23.9 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1313424  bytes 1423957304 (1.4 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::fc54:ff:fee4:b2e9  prefixlen 64  scopeid 0x20<link>
        ether fe:54:00:e4:b2:e9  txqueuelen 1000  (Ethernet)
        RX packets 1030103  bytes 1408813377 (1.4 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 323760  bytes 25145894 (25.1 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

a może masz wyłączone echo request ICMP na tym 10.0.32.108 ,po ssh też powinno sie dać zalogować jak jest bridge na poziomie WAN hypervizora.Ten adres musi być widoczny z zewnątrz skoro dostał adres z DHCP a ping może nie chodzić bo jest wyłączona odpowiedz na ICMP.Jak by ten interfejs br0 byl nie widoczny to serwer DHCP tez by go nie widzial,tylko moze sa na nim jakies zabezpieczenia ,dziwne ustawienia.Np domyslne blokowanie wszystkiego z incoming + blokada echo icmp.

A jak byś miał tylko 1 adres możliwy to pewnie byś musiał zrobić przez NAT i forwarding portów tak jak w proxmoxie miałeś.Wtedy sobie np. przekierowujesz port 2222 na WAN hipervizor na port 22 za NAT do VM.Na proxmox miałeś to tu

    post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up iptables -t nat -A POSTROUTING -s '192.168.0.0/24' -o vmbr0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '192.168.0.0/24' -o vmbr0-j MASQUERADE