[Megoldva] Proxmox host és OpenVPN belső LAN

Elso korben juss el odaig, hogy a LAN tartomanyod felol a VPN ip-(ke)t mi routeolja el a megfelelo iranyba.

1. kérdés: A fent említett két szabályon kívül van valami még a táblákban?

iptables -vnL -t raw
iptables -vnL -t mangle
iptables -vnL -t nat
iptables -vnL -t filter

2. Ha "üres" az iptables, akkor valami ilyen kell neked: (Persze sok minden függ attól, hogy mi van jelenleg a táblákban)

# FILTER tábla
# Conntrack használat
iptables -t filter -A FORWARD -j ACCEPT -m conntrack --ctstate ESTABLISHED
iptables -t filter -A FORWARD -j ACCEPT -m conntrack --ctstate RELATED

# VPN hálózatból induló, LAN hálózatba menő kapcsolatok elfogadása
iptables -t filter -A FORWARD -j ACCEPT -s 10.8.0.0/24 -d 192.168.0.0/24

# VPN hálózatból induló, LAN hálózatba menő kapcsolatok elfogadása
iptables -t filter -A FORWARD -j ACCEPT -s 192.168.0.0/24 -d 10.8.0.0/24

3. A NAT táblában az " -o 192.168.0.0/24"-nak semmi értelme, mert az "-o" output interface-t jelent és nem IP címet.

4. A legfontosabb kérdés, hogy a különböző hálózatokban (tehát a vmbr0-ban és a VPN-ben) lévő gépeknek mi van routing táblájukban. Más néven: Tudnak-e a gépek arról, hogy a másik oldal a Proxmox szerveren keresztül érhető el? Ehhez adj ki egy "ip r" parancsot egy-egy vmbr0-ban és a VPN-ben lévő gépen.

Dobj be esetleg egy /etc/network/interfaces kimenetet is.

Illetve ez tudom, hogy nem válasz a kérdésre, de WireGuard VPN esetleg nem játszik? Azon egyszerűbb tapasztalataim alapján a routing-ot belőni és megtalálni hol a hiba. Az OPENVPN direkt fut l3 módban? Ha a VM-eket akarod elérni és nincs akadálya, rakd be l2 módban a vmbr0 bridge-be és látni fog mindenki mindenkit.

Ha traceroute-olsz a VPN kliensről valamely VM felé, az 1. hop a VPN szerver?

Ha valamit lehet javasolni akkor egy vm-be vagy konténerbe tedd be az openvpn servert (inkább vm).
Semmi nem garantálja neked hogy egy következő proxmox update nem fogja felülvágni a host oldali network setupodat.
A VM-edben meg az van amit beleteszel.

Nálam a vpn szerveren az eszköz (nem proxmox):

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
       inet 10.8.0.1  netmask 255.255.255.0  destination 10.8.0.1

iptables, hogy lássam a belső hálót (ami: 192.168.0.0/24 és 10.1.1.0/24):
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE

Én - kellően barbár módon - azt mondanám, hogy a tun helyett tap eszközt használnék, a VPN-en belül ugyanabból a tartományból osztanék IP-t, amiben a guestek is vannak, az openvpn tap interface-t meg benyomnám a vmbr0 bridge-be és ezen a ponton route-olás, forwardolás és tűzfalazás nélkül működne az egész mutatvány. (Természetesen IP cím osztást csak ésszel, hogy ne legyen IP cím ütközés - de ez megoldható úgy, hogy pl. fix IP-ket a .10 - .99 közötti tartományból adok ki, a helyi DHCP a .100 - .199 tartományból oszt, míg az OpenVPN megkaphatja a .200 - .249 tartományt.)

Ami nekem jelenleg roppant gyanús és amín szerintem a jelenlegi próbálkozás elvérzik, az az, hogy eddig a ProxMox-on se tűzfal szabály nem volt beállítva, se forwarding. Ha a kliensek mégis láttak netet, akkor az nekem azt jelenti, hogy a vmbr0 bridge-be nem csak a guestek vannak belógatva, de abba van betéve a fizikai hálókártya is, így a guestek gyakorlatilag a belső háló részévé válnak. Ezen a ponton viszont a megoldásban vázolt VPN subnet felé az átjáró a LAN gw, a 192.168.0.1, oda is fogják küldeni a válasz csomagot a kliensek, így a ProxMox nem fogja el, nem fogja vissza route-olni a válasz csomagokat a VPN csatiba - csak az "oda" forgalom megy, a "vissza" nem él --> nincs kommunikáció.
Lábjegyzet: ha sikerül megoldani a kommunikációt és a gyanúm helyes, akkor nem csak a guesteket, hanem a ProxMox melletti teljes belső hálót is látni lehet majd a VPN felől. Ez mennyire cél? (Megjegyzés: a jelen felállás működhet, ha a nat tábla POSTROUTING ágán maszkolás történik azon csomagok esetén, amelyek a VPN felől jöttek. De ekkor minden VPN-ből induló kapcsolat a végponton úgy fog látszani, mintha a kérés a ProxMox-ról indulna és az olyan trükkös protokollok, mint amilyen pl. az ftp is, csak conntrack-helper modulokkal fognak működni, mert amikor az IP cím protokollon belül egyeztetett, azt a mezei NAT nem írja át, csak ha van conntrack az adott protokollhoz.)

Igazából az se tiszta, hogy ha a feltételezés igaz, hogy a ProxMox egy védett belső hálóban van és igazából nem is routeol a kliesek és a LAN között, akkor miért itt termináljuk a VPN kapcsolatot?

Egyébként a forgalom vizsgálatára ajánlom a tcpdump utility-t, megfelelően paraméterezve: pl. az eth0 interface esetén érdemes erősen szűrni portra is, hogy a saját ssh kapcsolatunk forgalmát ne listázza - ezzel újabb, dumpolandó forgalmat generálva. Kellően informatív tud lenni arra nézve, hogy:

- bejön-e a kérdéses csomag azon az interface-n, amelyiken várom?

- kimegy-e azon az interface-n, amelyiken várom?

- ha NAT van, akkor az IP cím csere megtörténik-e?

- bejön-e a válasz csomag a megfelelő interface-n?

- kimegy-e a vékasz csomag a megfelelő interface-n?

- ha volt NAT, akkro a csomag visszaalakítása megtörtént-e?