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!
- 486 megtekintés
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.
- A hozzászóláshoz be kell jelentkezni
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
> dirCmd: 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
> dirCmd: 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
> dirCmd: 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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.7Ha ezzel sem megy, akkor nem tudom.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 ftpNem 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 0Ne 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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni