Proxmox+vm+ftp - nem megy

Fórumok

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.

conntrack_ftp és társai mennyire tűnik ördögtől valónak? 

Semennyire, de nem igazán használtam még...

 

Filezilla:

 

Állapot:    Cím feloldása a következőhöz: ftpszerver.com
Á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...
Válasz:    220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Válasz:    220-You are user number 3 of 50 allowed.
Válasz:    220-Local time is now 07:04. Server port: 21.
Válasz:    220-This is a private system - No anonymous login
Válasz:    220-IPv6 connections are also welcome on this server.
Válasz:    220 You will be disconnected after 15 minutes of inactivity.
Parancs:    USER ftpuser
Válasz:    331 User ftpuser OK. Password required
Parancs:    PASS ********************
Válasz:    230 OK. Current restricted directory is /
Parancs:    OPTS UTF8 ON
Válasz:    200 OK, UTF-8 enabled
Állapot:    Belépve
Állapot:    Könyvtár lista lekérdezése...
Parancs:    PWD
Válasz:    257 "/" is your current location
Parancs:    TYPE I
Válasz:    200 TYPE is now 8-bit binary
Parancs:    PASV
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.
Parancs:    MLSD
Hiba:    Az adatkapcsolat nem hozható létre: ECONNREFUSED - Szerver által visszautasított kapcsolat
Hiba:    20 másodperc után időtúllépés a kapcsolatban
Hiba:    A könyvtár lista lekérdezése nem sikerült
Állapot:    Kapcsolat bontódott a kiszolgálóval
Állapot:    Cím feloldása a következőhöz: ftpszerver.com
Á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...
Válasz:    220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Válasz:    220-You are user number 4 of 50 allowed.
Válasz:    220-Local time is now 07:04. Server port: 21.
Válasz:    220-This is a private system - No anonymous login
Válasz:    220-IPv6 connections are also welcome on this server.
Válasz:    220 You will be disconnected after 15 minutes of inactivity.
Parancs:    USER ftpuser
Válasz:    331 User ftpuser OK. Password required
Parancs:    PASS ********************
Válasz:    230 OK. Current restricted directory is /
Parancs:    OPTS UTF8 ON
Válasz:    200 OK, UTF-8 enabled
Állapot:    Belépve
Állapot:    Könyvtár lista lekérdezése...
Parancs:    PWD
Válasz:    257 "/" is your current location
Parancs:    TYPE I
Válasz:    200 TYPE is now 8-bit binary
Parancs:    PASV
Válasz:    227 Entering Passive Mode (192,168,100,105,164,210)
Á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
Válasz:    150 Accepted data connection
Válasz:    226-Options: -a -l 
Válasz:    226 20 matches total
Állapot:    Könyvtár listázás sikerült: "/"
Állapot:    Könyvtár lista lekérdezése: "/webdav"...
Parancs:    CWD webdav
Válasz:    250 OK. Current directory is /webdav
Parancs:    PWD
Válasz:    257 "/webdav" is your current location
Parancs:    PASV
Válasz:    227 Entering Passive Mode (192,168,100,105,166,50)
Á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
Válasz:    150 Accepted data connection
Válasz:    226-Options: -a -l 
Válasz:    226 4 matches total
Állapot:    Könyvtár listázás sikerült: "/webdav"
Állapot:    Könyvtár lista lekérdezése: "/webdav/web"...
Parancs:    CWD web
Válasz:    250 OK. Current directory is /webdav/web
Parancs:    PWD
Válasz:    257 "/webdav/web" is your current location
Parancs:    PASV
Válasz:    227 Entering Passive Mode (192,168,100,105,102,16)
Á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
Hiba:    20 másodperc után időtúllépés a kapcsolatban
Hiba:    A könyvtár lista lekérdezése nem sikerült
Állapot:    Kapcsolat bontódott a kiszolgálóval
Állapot:    Cím feloldása a következőhöz: ftpszerver.com
Á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...
Válasz:    220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Válasz:    220-You are user number 5 of 50 allowed.
Válasz:    220-Local time is now 07:04. Server port: 21.
Válasz:    220-This is a private system - No anonymous login
Válasz:    220-IPv6 connections are also welcome on this server.
Válasz:    220 You will be disconnected after 15 minutes of inactivity.
Parancs:    USER ftpuser
Válasz:    331 User ftpuser OK. Password required
Parancs:    PASS ********************
Válasz:    230 OK. Current restricted directory is /
Parancs:    OPTS UTF8 ON
Válasz:    200 OK, UTF-8 enabled
Állapot:    Belépve
Állapot:    Könyvtár lista lekérdezése: "/webdav/web"...
Parancs:    CWD /webdav/web
Válasz:    250 OK. Current directory is /webdav/web
Parancs:    TYPE I
Válasz:    200 TYPE is now 8-bit binary
Parancs:    PASV
Válasz:    227 Entering Passive Mode (192,168,100,105,138,243)
Á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
Válasz:    150 Accepted data connection
Válasz:    226-Options: -a -l 
Válasz:    226 3 matches total
Állapot:    Könyvtár listázás sikerült: "/webdav/web"

 

ncftp (mondjuk itt ha jó portot használt -30000-50000- akkor nem volt hiba):

NcFTP 3.2.5 (Feb 02, 2011) by Mike Gleason (http://www.NcFTP.com/contact/).
Connecting to 1.5.6.7...                                                                                         
--------- Welcome to Pure-FTPd [privsep] [TLS] ----------
You are user number 8 of 50 allowed.
Local time is now 06:34. Server port: 21.
This is a private system - No anonymous login
IPv6 connections are also welcome on this server.
You will be disconnected after 15 minutes of inactivity.
Logging in...                                                                                                          
OK. Current restricted directory is /
Logged in to ftszerver.com.                                                                                              
ncftp / > debug 1   
ncftp / > cd webdav/
> cd webdav/

Cmd: CWD webdav
OK. Current directory is /webdav
250: OK. Current directory is /webdav
ncftp /webdav > dir       
> dir

Cmd: OPTS MLST type;size;modify;UNIX.mode;UNIX.uid;UNIX.gid;
200:  MLST OPTS type;size;sizd;modify;UNIX.mode;UNIX.uid;UNIX.gid;unique;
Cmd: PASV
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.
connect failed: Kapcsolat elutasítva.
connect failed: Kapcsolat elutasítva.
Retrying PASV mode (2 tries left).
Cmd: PASV
227: Entering Passive Mode (192,168,100,105,75,49)
Fixing bogus PASV data address from 192.168.100.105:19249 to 1.5.6.7:19249.
connect failed: Kapcsolat elutasítva.
connect failed: Kapcsolat elutasítva.
Retrying PASV mode (1 try left).
Cmd: PASV
227: Entering Passive Mode (192,168,100,105,246,125)
Fixing bogus PASV data address from 192.168.100.105:63101 to 1.5.6.7:63101.
connect failed: Kapcsolat elutasítva.
connect failed: Kapcsolat elutasítva.
Retrying PASV mode (0 tries left).
List failed.
ncftp /webdav > dir
> dir

Cmd: PASV
227: Entering Passive Mode (192,168,100,105,12,59)
Fixing bogus PASV data address from 192.168.100.105:3131 to 1.5.6.7:3131.
connect failed: Kapcsolat elutasítva.
connect failed: Kapcsolat elutasítva.
Retrying PASV mode (2 tries left).
Cmd: PASV
227: Entering Passive Mode (192,168,100,105,32,152)
Fixing bogus PASV data address from 192.168.100.105:8344 to 1.5.6.7:8344.
connect failed: Kapcsolat elutasítva.
connect failed: Kapcsolat elutasítva.
Retrying PASV mode (1 try left).
Cmd: PASV
227: Entering Passive Mode (192,168,100,105,109,239)
Fixing bogus PASV data address from 192.168.100.105:28143 to 1.5.6.7:28143.
connect failed: Kapcsolat elutasítva.
connect failed: Kapcsolat elutasítva.
Retrying PASV mode (0 tries left).
List failed.
ncftp /webdav > dir
> dir

Cmd: PASV
227: Entering Passive Mode (192,168,100,105,62,251)
Fixing bogus PASV data address from 192.168.100.105:16123 to 1.5.6.7:16123.
connect failed: Kapcsolat elutasítva.
connect failed: Kapcsolat elutasítva.
Retrying PASV mode (2 tries left).
Cmd: PASV
227: Entering Passive Mode (192,168,100,105,102,53)
Fixing bogus PASV data address from 192.168.100.105:26165 to 1.5.6.7:26165.
connect failed: Kapcsolat elutasítva.
connect failed: Kapcsolat elutasítva.
Retrying PASV mode (1 try left).
Cmd: PASV
227: Entering Passive Mode (192,168,100,105,151,150)
Fixing bogus PASV data address from 192.168.100.105:38806 to 1.5.6.7:38806.
Cmd: MLSD
150: Accepted data connection
226: Options: -a -l 
     4 matches total
Remote listing contents {
    type=cdir;sizd=4096;modify=20210301132501;UNIX.mode=0770;UNIX.uid=5008;UNIX.gid=5008;unique=801g12a0033; .
    type=pdir;sizd=4096;modify=20210302180301;UNIX.mode=0755;UNIX.uid=0;UNIX.gid=0;unique=801g12a002c; ..
    type=dir;sizd=4096;modify=20210301133200;UNIX.mode=0770;UNIX.uid=5008;UNIX.gid=5008;unique=801g12a19f4; web
    type=file;size=55;modify=20210301132501;UNIX.mode=0644;UNIX.uid=0;UNIX.gid=0;unique=801g12a1b2b; web.htdigest
}
drwxrwx---                márc  1 14:32   web
drwxrwx---                márc  1 14:32   web
-rw-r--r--           55   márc  1 14:25   web.htdigest
-rw-r--r--           55   márc  1 14:25   web.htdigest
 

ü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.

Szerkesztve: 2021. 03. 03., sze – 19:02

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

helyette


enp0s31f6 -> 1.2.3.4   gw:?
vmbr1 -> 1.5.6.7/32
vmbr0 -> 192.168.100.1
vmbr0/vm -> 192.168.100.105 ftp

( HOST gépen, amin a public IP van )
$> modprobe nf_conntrack
$> modprobe nf_conntrack_ftp

iptables -A PREROUTING -t raw -m tcp -p tcp --dport 21 -j CT --helper ftp
...
iptables -A INPUT -t filter -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -t filter -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
...
iptables -A FORWARD -t filter -s 192.168.100.105 -j ACCEPT
iptables -A FORWARD -t filter -d 192.168.100.105 -j ACCEPT
...
iptables -A OUTPUT -t filter -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -t filter -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A PREROUTING -t nat -i enp0s31f6 -d 1.5.6.7 -m tcp -p tcp --dport 20 -j DNAT --to 192.168.100.105:20
iptables -A PREROUTING -t nat -i enp0s31f6 -d 1.5.6.7 -m tcp -p tcp --dport 21 -j DNAT --to 192.168.100.105:21
...
iptables -A POSTROUTING -t nat -o enp0s31f6 -s 192.168.100.105 -j SNAT --to 1.5.6.7

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:

/etc/proftpd/proftpd.conf
----------------------------------------------------
DefaultAddress                  192.168.100.105
MasqueradeAddress               1.5.6.7
Port                            21
PassivePorts                    50000 60000
----------------------------------------------------

/etc/sysctl.conf
----------------------------------------------------
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-filter-pppoe-tagged = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
net.bridge.bridge-nf-pass-vlan-input-dev = 0

net.ipv4.ip_local_port_range = 32768 65535
net.ipv4.tcp_max_orphans = 65535
----------------------------------------------------

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:

 

$> modprobe nf_conntrack
$> modprobe nf_conntrack_ftp
$> modprobe nf_nat_ftp


iptables -A PREROUTING -t raw -d 1.5.6.7 -m tcp -p tcp --dport 21 -j CT --helper ftp
...
iptables -A INPUT -t filter -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -t filter -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
...
iptables -A FORWARD -t filter -s 192.168.100.105 -j ACCEPT
iptables -A FORWARD -t filter -d 192.168.100.105 -j ACCEPT
iptables -A FORWARD -t filter -m conntrack --ctstate RELATED -m helper --helper ftp -i enp0s31f6 -p tcp --dport 1024: -j ACCEPT
iptables -A FORWARD -t filter -m conntrack --ctstate RELATED -m helper --helper ftp -o enp0s31f6 -p tcp --dport 1024: -j ACCEPT     
...
iptables -A OUTPUT -t filter -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -t filter -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A PREROUTING -t nat -i enp0s31f6 -d 1.5.6.7 -m tcp -p tcp --dport 20 -j DNAT --to 192.168.100.105:20
iptables -A PREROUTING -t nat -i enp0s31f6 -d 1.5.6.7 -m tcp -p tcp --dport 21 -j DNAT --to 192.168.100.105:21
...
iptables -A POSTROUTING -t nat -o enp0s31f6 -s 192.168.100.105 -j SNAT --to 1.5.6.7

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?

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

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.

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.

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ó.

enp0s31f6 -> 1.2.3.4   gw:?
vmbr1 -> 1.5.6.7/32
vmbr0 -> 192.168.100.1
vmbr0/vm -> 192.168.100.105 ftp

Nem vettem észre én sem ezt a problémát,

 

pomm

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

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

auto enp0s31f6
iface enp0s31f6 inet manual

auto br0
iface br0 inet static
  address 1.2.3.4
  network (?)
  netmask (?)
  gateway x (?)
  ovs_type OVSBridge
  ovs_ports enp0s31f6

auto br0:10
iface br0:10 inet static
  address 1.5.6.7
  network 1.5.6.7
  netmask 255.255.255.255

auto vmbr0
iface vmbr0 inet static
  address 192.168.100.1
  network 192.168.100.0
  netmask 255.255.255.0
  ovs_type OVSBridge

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