Sziasztok!
A következő gonddal szívok (lehet nem látom a fától az erdőt):
Van egy proxmox szerver több vm-mel és ct-vel.
Alapértelmezetten a fizikai gép enp0s31f6 csatolója rendelkezik egy fix ip-vel. (mondjuk 1.2.3.4) Az egyik vm-nek is kellett egy fix ip (mondjuk 1.5.6.7) Ez megjelnik, mint vmbr1. A belső hálózat vmbr0 192.168.100.1 - ez a fizikai gép címe. A vm-nek a belső címe 192.168.100.105.
Szeretném, hogy a 21-es porton kívülről elérjem a vm 21-es portját.
A tűzfal szabályokba ezért felvettem a következő:
iptables -A FORWARD -i enp0s31f6 -p tcp -m tcp --dport 30000:50000 -d 192.168.100.105 -j ACCEPT
iptables -A FORWARD -i enp0s31f6 -p tcp --dport 20 -d 192.168.100.105 -j ACCEPT
iptables -A FORWARD -i enp0s31f6 -p tcp --dport 21 -d 192.168.100.105 -j ACCEPT
iptables -A PREROUTING -i enp0s31f6 -p tcp -t nat --dport 21 -j DNAT --to-destination 192.168.100.105:21
iptables -A PREROUTING -i enp0s31f6 -p tcp -t nat --dport 20 -j DNAT --to-destination 192.168.100.105:20
iptables -A PREROUTING -i enp0s31f6 -p tcp -m multiport -t nat --dports 30000:50000 -j DNAT --to-destination 192.168.100.105:30000-50000
Maszkolás bekapcsolva, ip forward bekapcsolva, pure-ftpd-ben felvéve a force passzív ip (1.5.6.7), passzív portok megadva (30000-50000)
Csatlakozásnál random módon hol csatlakozik, hol nem. Hiba üzenet ennyi:
mlsd
error the data connection could not be established econnrefused - connection refused by server
Két, három próbálokozás után, belép, majd megy egy ideig, majd a könyvtár listázásnál hal el. (filezilla)
ncftp-nél is észlelhető a hiba, de ott nem akad meg az egész ilyen látványosan
Mit rontok el?
Köszi!
Hozzászólások
Az egyik, amit látok: a FORWARD szabályok az internet --> VM irányt engedik, de a válasz csomagok VM --> internet irányba közlekednek. Azzal mi van? (Gyanítom, a VM az alapgépen keresztül "kap netet", így a VM --> internet irány ott engedélyezett, de logikailag ide is tartozik.)
A másik dolog, hogy a 20-as port az ftp-data, ami azért hangsúlyos, mert ebben az esetben fordítva működik a kapcsolat. Tehát ha aktív módban vagy, akkor a szerver hív ki a kliens felé és ekkor a szerver forrásportja lesz a 20/tcp, de ebből adódóan azt nem beengedni kell, hanem kiengedni mint forrásport és ennek megfelelően nem a PREROUTING ágon kell portforwarddal betolni a VM felé, hanem POSTROUTING ágon kiengedni a net felé, de MASQUERADE targettel.
Amit pontosítanék: melyik csatlakozásról beszélünk? Tehát ha jó a tippem, akkor a 21/tcp parancscsatorna minden esetben jól felépül és működik, de az adatcsatorna nem. ftp kliensen debug mód: milyen parancsokat küldött, milyen válaszokat kapott? ftp server tuti jól van konfigva, biztos felveszi a passziv port konfigot?
Érdeklődni szeretnék továbbá, hogy a conntrack_ftp és társai mennyire tűnik ördögtől valónak? Csak mert ha a 21-es parancscsatorna forgalma nem titkosított, akkor ezen modulok elemzik a forgalmat és automatikusan biztosítják az adatcsatorna felépüléséhez szükséges beállításokat. Jól belőtt contrack modulokkal elég a 21-es portot betolni a VM felé, a többire ekkor nem lesz szükség.
Semennyire, de nem igazán használtam még...
Filezilla:
ncftp (mondjuk itt ha jó portot használt -30000-50000- akkor nem volt hiba):
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
A szerver konfigba hasznos lenne felvenni egy olyan opciót, hogy a látható IP címe 1.5.6.7.
Hogy jelenleg nem így van, azt két sor is bizonyítja:
- Filezilla: Válasz: 227 Entering Passive Mode (192,168,100,105,9,10)
Állapot: A kiszolgáló nem lekérdezhető című passzív választ küldött. A szerver címének használata ehelyett.
- ncftp: 227: Entering Passive Mode (192,168,100,105,42,30)
Fixing bogus PASV data address from 192.168.100.105:10782 to 1.5.6.7:10782.
A másik gyanúm, hogy a szerver nem veszi fel a passzív portra vonatkozó korlátozásokat. Ezt abból gondolom, hogy ezt írod: ncftp (mondjuk itt ha jó portot használt -30000-50000- akkor nem volt hiba)
Mivel a passzív port értékét a szerver mondja meg és te beállítottad, hogy mekora tartományból oszthat, akkor ha a portszám mégsem esik ebbe bele, annak csak egyetlen magyarázata van: a szerver ezt a beállítást ignorálta.
helyette
A "FORWARD" ágon még lehet szűkíteni, de "-d" és "-s" az mindenképp benne kell legyen.
Csiszolni kell rajta kicsit, hogy jó legyen :)
Köszi.
Ezzel is ugyanaz a hiba, hogy mint a népmese... Hol volt ftp kapcsolat, hol nem...
Ha nem adom meg neki ezt:
iptables -A PREROUTING -i enp0s31f6 -p tcp -m multiport -t nat --dports 30000:50000 -j DNAT --to-destination 192.168.100.105:30000-50000
akkor meg sem nyikkan.
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
Pedig mennie kellene port nyitás nélkűl is, nem kell ekkora tartomány, elég 50000:60000 -között.
Még ezek esetleg:
A helyzet az, hogy nincs változás. Illetve ha szűkítem a passzív port tartományt, egyre több a hiba. Mintha a kliens programok nem tudnák, hogy melyik tartományban mehetnek. A filezillanak kézzel megadva is ugyanez a helyzet. Most megemeltem 10000-60000 köz és 10-15 lekérdezésenként egy hiba esik be. Szerintem itt van valami, ami nem stimmel...
Amúgy nem proftpd, hanem pure-ftpd...
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
Próbáld meg így:
Ha ezzel sem megy, akkor nem tudom.
Szerintem valami olyan gond lesz, hogy az FTP szerver által kezdeményezett kapcsolatok nem az 1.5.6.7 forrás IP címmel indulnak, és a kliens olyan ezzel nem tud mit kezdeni. debtamas88 válasza ezt kezeli mondjuk, de nekem kapásból az nem egyértelmű, hogy az 1.5.6.7 cím forgalma hogyan jut el a host-ra, ha ez a cím csak egy belső bridge-en van felvéve? Sima route-tal rá van tolva az 1.2.3.4 IP-re az 1.5.6.7 forgalma?
Ezen felül honnan teszteled? Egy teljesen külső gépről, vagy valamelyik 192.168.100.x című VM-ből?
Ez logikus is lenne, ha egyzserűen nem működne, de mint írtam nem nem megy, hanem akadozik.
A vmbr1-re felvettem az ip-t és a vmbr1-et hozzáadtam a vm-hez (ezt a proxmox fórumon olvastam valahol):
auto vmbr0
iface vmbr0 inet static
address 192.168.100.1
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0
auto vmbr1
iface vmbr1 inet static
address 1.5.6.7
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0
Külső gépről tesztelem.
Íme:
Állapot: Cím feloldása a következőhöz: ftpdomain.hu
Állapot: Csatlakozás a következő kiszolgálóhoz: 1.5.6.7:21...
Állapot: Az adatkapcsolat létrejött, várakozás az üdvözlő üzenetre...
Állapot: Belépve
Állapot: Könyvtár lista lekérdezése...
Állapot: A kiszolgáló nem lekérdezhető című passzív választ küldött. A szerver címének használata ehelyett.
Állapot: Könyvtár listázás sikerült: "/"
Állapot: Könyvtár lista lekérdezése: "/web"...
Állapot: A kiszolgáló nem lekérdezhető című passzív választ küldött. A szerver címének használata ehelyett.
Állapot: Könyvtár listázás sikerült: "/web"
Állapot: Könyvtár lista lekérdezése: "/web/admin"...
Állapot: A kiszolgáló nem lekérdezhető című passzív választ küldött. A szerver címének használata ehelyett.
Parancs: MLSD
Hiba: Az adatkapcsolat nem hozható létre: ECONNREFUSED - Szerver által visszautasított kapcsolat
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
Ha egy VM-nek kell az 1.5.6.7 címen szolgáltatni, akkor miért a host-ta teszed a címet, ráadásul egy bridge-re, amire rákötöd azt a virtuális gépet, aminek azon a címen szolgáltatnia kellene... Nem látom, hogy ez így miért lenne jó, és egyáltalán, miért működne.
Ha azt szeretnéd, hogy a host-on legyen a cím, és DNAT-tal kerüljön a forgalom a megfelelő VM-re, akkor tedd egy loopback if-re (vagy a címnek megfelelő fizikai IF-re) a címet a host-on, legyen DNAT és SNAT a megfelelő VM 192.xxx címével.
De még egyszerűbben járnál, ha a VM-be tennéd az 1.5.6.7/32 címet loopback-ra, és egy route-tal a VM-re menne a forgalom egyenesen.
Vagy, ha az adott cím él egy alhálózaton, amire a host is csatlakozik, akkor a vmbr1-et ahhoz az alhálózathoz kösd, csatold hozzá a VM-et és a VM-ben állítsd be arra a csatolóra ezt a publikus címet.
Ezt segítenél értelmezni, ha
enp0s31f6 1.2.3.4
vmbr0 192.168.100.1
és a vm-nek a belső ip címe 192.168.100.105
Köszi!
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
Szerintem a "1.2.3.4" fő ip, minden további publikus ip-t oda routol a szolgáltató "1.5.6.7"
A bridge-nek (OpenVswitch) annyi előnye van hogy tud generálni sflow, IPFIX statisztikát, ami a monitoring-hoz jó.
Nem vettem észre én sem ezt a problémát,
pomm
Ne ezt használd mert ez a "bridge-utils", régi elavúlt - nálam nem működött rendesen amikor VM-VM kommunikáció volt.
Ez kell helyette: OpenVswitch ( Proxmox repo tartalmazza a saját openvswitch build-át )
https://pve.proxmox.com/wiki/Open_vSwitch
apt install openvswitch-switch
iptables konfig meg az előző hozzászólásokban.
A Linux bridge nem avult el egyáltalán. Sőt. Ha neked nem működött a VM-VM kommunikáció Linux bridge-dzsel, akkor valamit nagyon rosszul csináltál abban a konfigban.
Az OpenVSwitch egy új lehetőségként jelent meg, ha olyasmi funkcionalitás kellene, mint a VMware distributed vswitch. Amennyiben egyetlen host-ról beszélünk, teljesen felesleges bonyolítás az OpenVSwitch használata, és még akkor is meggondolandó, ha több host van, de egy fizikai hálózatra csatlakoznak. Az OpenVSwitch ott lesz hasznos, ahol a host-ok más-más fizikai hálózatra csatlakoznak, mégis kell közéjük húzni egy logikai közös (VLAN képes) saját hálózatot.
Ez így nem igaz.
Alap funkciókra is kiváló: ebben semmivel nem bonyolultabb mint a "bridge-utils" - cserébe nem bugzik és stabil.
ovs-vsctl add-br bridge1
ovs-vsctl add-port bridge1 eth1
ovs-vsctl del-port bridge1 eth1
Vannak kiterjesztett funkciói, amit nem kötelező beállítani/használni.
Én nem mondtam, hogy az OVS nem jó sima bridge-nek, én azt mondtam, hogy tök felesleges sima bridge-nek OVS-t használni. Ráadásul a dokumentációja finoman szólva is igényel némi átszellemülést, hogy megértse az ember, nem olyan triviális (azon túl, hogy a Proxmox doksiból pár alap dolgot ki lehet copy-paste módszerrel venni).
Nem értem a "nem bugzik" kijelentést. Mintha annyi sokat lehetne a Linux bridge hibás működéséről olvasni.
Meg azt sem értem, hogy a "gyári" Linux bridge-hez viszonyítva mondod, hogy "stabil" az OVS? Mert az eredeti bridge megvalósítás nem stabil?
Az OVS-sel alapból az a baj, hogy telepíteni kell, tehát plusz szoftver, nem a rendszer része (Proxmox esetében sem kerül fel automatikusan). Ha azon funkciókat használod belőle, amit a sima bridge is tud, akkor teljesen feleslegesen futtatsz plusz egy szoftvert, feleslegesen konfigurálsz. Ha viszont azon funkciói kellenek, amik miatt ki lett találva/fejlesztve, akkor nyilván nem kérdés a használata.
Ez olyan, mintha egy konfig állományt elgépeltem volna nano-ban, ezért nem fut jól a szolgáltatás, erre beírnád, hogy a nano bugos és instabil, telepítsek inkább egy komplett Emacs-ot, mert az mindent tud amit a nano és még többet is ha kell.
Félre ne érts, én nem beszéllek le az OVS használatáról. Nekem annyi a problémám a téma bedobásával, hogy az eredeti problémát hibásan értelmezett és hibásan kivitelezett konfigurálás okozza, és Te még ezt bonyolítod meg a kérdezőnek azzal, hogy mindezt a hibás elméletet ne a már meglévő Linux bridge-dzsel, hanem OVS-sel valósítsa meg inkább. De az OVS használata nem lesz megoldás a problémájára, mert nem a bridge okozza a gondot, hanem a rossz helyre felvett publikus IP cím és az e mellé tett nem megfelelő port továbbítások. Vagy azt is mondhatnám, hogy az eredeti koncepció a hibás úgy ahogy van a feladat megoldására, és nem a bridge a kérdés benne.
Nos, igen van...
A helyzet az, hogy kezdetben volt egy proxmox 2-3 lxc-vel, meg 2 vm-mel és egy publikus ip-vel (1.2.3.4). Itt nyilván az egyes portokat az igényeknek megfelelően forwardoltunk a vm-ek, lxc-k felé.
Aztán jött az igény, hogy egyes vm-et más publikus ip (1.5.6.7) alatt kellene elérni. (Nyilván a már meglévő dolgoknak mennie kell tovább zavartalanul)
Ekkor forward-dal és prerouting-gal, masquarde-del megoldódott az ügy. Megy az apache, ssh, stb. Egészen az ftp-ig nem tűnt ez rossz ötletnek, most viszont a fenti problémába ütköztem.
Tehát a meglévő infrastruktúra felrúgása nem lehetséges és nem is kívánatos (pl. ovs használata).
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt