Sziasztok!
Egy kis segítség kellene nekem:
Adott a következő teszt konfiguráció:
pfsense két nic-el: wan (192.168.1.2), lan (192.168.2.1)
haproxy pfsense modul feltelpítve:
proxmox (7.0) 1 nic-el: 192.168.2.2-es ip-n és default 8006-os porton https-el (self signed certtel) és ezen pár konténer (2.3-tól 2.6-ig ip-zve).
A célom az lenne, hogy a 192.168.1.0/24 ip tartományból ha meghívom a webszerver01.example.com címet, akkor a 192.168.2.3-as ip-re reverse proxizzon át a pfsense (ez megy is, http típusú frontenddel, illetve a webserver02... átirányít a 2.4-es ip-re, ahogyan az kell). Értelemszerűen a proxmoxnak a proxmox.example.com címet adtam.
proxmox esetén viszont akármit kattintgattam a backend/frontend oldalon, nem akarta a jót (tehát 443-as portos standard https url-t írok be és a 8006-os tcp portos proxmox nyíljon meg), kivéve ha a 8006-os portra raktam egy haproxy frontendet tcp típussal és ennek megfelelő backenddel.
A kérdés az lenne, hogy tcp típusú frontend esetén lehet-e bármilyen url alapú szabályt megadni, hogy mi nyíljon meg, vagy ha nem, akkor tcp-ben lehet-e url-re bármilyen szabályt alkalmazni?
Mivel tanuló környezet, így bármit lehet módosítani, nagy hibát nem tudok előidézni (max újrahúzok mindent...), az egyedüli kritérium, hogy mindezt a pfsense webes felületén meg lehessen csinálni (direktben szerintem nem tanácsos a fájlokat piszkálni, mivel úgyis felülír mindent a gui egy módosítás esetén).
Előre is köszönöm mindenkinek, aki segít!
- 321 megtekintés
Hozzászólások
Maga a haproxy TCP modban is tud az SSL clienthello-ban kuldott SNI alapjan donteni, hogy melyik backendet valassza (URL alapon nem, ahhoz mar nem TCP, hanem HTTP modban kene mennie). Hogy mindezt ossze tudod-e kattogtatni a rendszereden, azt passzolom, nem ismerem, amit hasznalsz.
- A hozzászóláshoz be kell jelentkezni
Szia!
Két megoldás van:
1., Apache + mod_proxy
2., "2x SSH portforward" ( VM -re csatlakozol, majd innen mégegy ssh portforward a Promox-Host -ra )
Az 1., megoldás hátránya, hogy nem fog menni pl.: HTML5 console - ( valamilyen websocketet használ ), valamint nem lehet subdir-be rakni proxmox-webui-t, mivel a válaszba "/" - várja ( rewrite-al lehet kezdeni vele valamit, de a javascript fájlok nem fognak működni )
Példa:
/etc/apache2/sites-enabled/000-default.conf
-------------------------------------------
<Virtualhost *:443>
<Proxy *>
Order allow,deny
Allow from all
</Proxy>
ProxyPass / http://127.0.0.1:8006/ retry=0 timeout=60
ProxyPassReverse / http://127.0.0.1:8006/
</Virtualhost>
-------------------------------------------
A 2., megoldással működik minden funkció, annyi szükséges, hogy a VM-ből elérhető legyen a Proxmox MGMT-interfésze, valamint fusson rajta az ssh ( /etc/ssh/sshd_config: "AllowTcpForwarding yes" ).
SSH -> VM -> SSH -> Proxmox-Host
Példa:
$PC> ssh -L 8006:127.0.0.1:8006 user@<public-ipv4> -p 9111
$VM> ssh -L 8006:127.0.0.1:8006 user@<PROXMOX-MGMT-ipv4> -p 22
$PC> web-browser ( lokális gépen fogod elérni közvetlen a Proxmox-MGMT -ét )
https://127.0.0.1:8006/
Ezt a megoldást úgy is lehet használni, hogy csinálsz egy dedikált VM-et amit csak a Proxmox-MGMT-re használsz ( virtuális gép grafikus felülettel, webböngészővel ) - ehhez az kell hogy a VM-nek VNC portját beállítjuk a Promox-Host-on, a PC-gépen pedig csak SSH + VNC viewer kell (pl.: TigerVNC) - valamint mivel SSH keresztűl megy a VNC ezáltal titkosított.
Példa:
/etc/pve/qemu-server/xxxx.conf
-------------------------------------------
args: -vnc 127.59.1.70:0
-------------------------------------------
Itt a ":0" az az 5900 portot jelenti - így kell megadni, tehát ezek alapján:
$PC> ssh -L 5911:127.0.0.1:5911 user@<public-ipv4> -p 9111
$VM> ssh -L 5911:127.59.1.70:5900 user@PROXMOX-MGMT-ipv4 -p 22
$PC> VNC-viewer ( connect 127.0.0.1:5911 )
- A hozzászóláshoz be kell jelentkezni
Szia,
Mindkét megoldás jó, de mint írtam haproxy-val megy a tcp mód, tehát a dupla ssh-s bohóckodás felesleges, na meg ha akarom, akkor sima portforwardot is tudok csinálni, szóval nem sok értelme van.
Apache esetén szintén működik, jupitert már proxy-ztam, ami szintén WS-t is használ.
Ennyi kellett hozzá pluszban:
<Location "/api/kernels">
RequestHeader set X-SCRIPT-NAME /
ProxyPassReverse https:/192.168.1.13:8080/
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/ [NC]
RewriteCond %{QUERY_STRING} transport=websocket [NC]
RewriteRule /(.*) wss://192.168.1.13:8080/$1 [P,L]
</Location>
Szóval WS-t is át lehet pöckölni, csak böngésző dev tools-ból ki kell nézni, hogy melyik linkre kell a proxy-t belőni.
Mindent leszámítva azért köszi a kerülő megoldásokat, de egyelőre nem ezeket keresem.
A lényeg lényege lényegében lényegtelen.
- A hozzászóláshoz be kell jelentkezni