vsftp pasv_resolve lan-on és wan-on?

Hálózatok általános

sziasztok
eddig volt egy kisebb gondom a vsftpd-vel, de erre találtam egy fél-"megoldást". most viszont routert cseréltem, és már nem működik a fél-megoldás sem.
alapvetően az a gond, hogy a szerver egy nat router mögött van, wan ip címe dinamikus, és egy dyndns címe is van. a vsftpd erre a dyndns címre oldja fel a passzív címet.
a routeren át van irányítva a 20 és 21 port, valamint a passzív port tartomány. (ez eddig is így volt a régi routeren). most még a biztonság kedvéért iptables-ben is kinyitottam ezeket a portokat a szerveren, de hiába.
a gond: kívülről aktív módban minden frankó. kívülről passzív módban (és sajnos a legtöbb kliens defaultban passzív módban csatlakozna) is megy a dolog. lan-ról viszont nem megy a passzív mód, mivel a wan címre old fel. erre régen azt csináltam, hogy pasv_promiscouos=yes, amivel lanról ment aktív és passzív módban is, kintről pedig aktívban ment, passzívban pedig nem minden klienssel/nem volt megbízható.
most az új routeren promisc.-kal egyáltalán nem megy már a passzív mód kívülről, promisc nélkül viszont kiválló. (tudom, hogy a promisc-nak semmi köze ehhez a dologhoz, de mégis segített valamelyest a régi routerrel)
a másik gond pedig az, hogy amennyiben nincsen internet valamiért, akkor a vsftpd elindul ugyan, de rögtön össze is omlik, vagy legalábbis kilép (tehát a démon nem fut tovább), így lan-ról sem használható. arra gondoltam, hogy ez is talán a névfeloldáshoz kapcsolható: ha nincs internet, nem tudja feloldani a pasv címet, és ettől tán összeomlik?

tehát: az lenne a kérdésem, hogyan lehetne ezt normálisan megcsinálni, hogy menjen lan-ról is, wan-felől is, aktív és passzív módban, és mindig a megfelelő címet oldja fel a passzív módhoz (lan-on a lan ip-t adja vissza, wan felől pedig a wan ip-t)
van erre valakinekl valami ötlete?

vsftpd.conf idevágó része:

userlist_enable=YES
userlist_deny=NO
pasv_enable=YES
#pasv_promiscuous=YES
pasv_min_port=25025
pasv_max_port=25099
pasv_addr_resolve=YES
pasv_address=valami.dyndns.cim
max_per_ip=10
hide_ids=YES
use_localtime=YES
max_login_fails=3
delay_failed_login=5

  • 1529 megtekintés

( sany | 2009. 02. 12., cs – 22:24 )

Ha van a routerben proxy dns menupont,
akkor a belső cím/hostnévvel minden gépet minden gépnek
"ismerté" tehetsz a Lanban.
Az enyémben van. :)

"pasv_address=valami.dyndns.cim"

pasv_address=valami
hostname-t adod meg?

nincs sajnos ilyen. semmi dns-sel kapcsolatos nincs. hacsak nem a "static dhcp" alatt, ott lehet engedélyezni mac address alapján a hozzáférést, és itt lehet host neveket is megadni a mac címekhez.
olyan van, hogy:
wan menüben: dynamic ip address részben "domain name" mező. (optional) ide nem írtam semmit eddig, mivel van egy dyndns frissítő funkció is a routerben, ott frissítem a domain ip címét.
lan menüben: a router ip címe és subnet maskja mellett van itt is egy "domain name" mező, ide sem írtam még semmit. kellene?
ddns menü: itt lehet a dyndns hostot megadni, és azt frissíti, mikor változik a wan ip címem.

pasv_address-ben nem a hostname van megadva, hanem a dyndns domain név.

(router = dlink di-524, jelenleg tesztelés alatt áll pont az ilyesmik miatt)

( stra | 2009. 02. 13., p – 09:39 )

"mindig a megfelelő címet oldja fel a passzív módhoz (lan-on a lan ip-t adja vissza, wan felől pedig a wan ip-t)"
"pasv_address=valami.dyndns.cim"
Mi az oka annak, hogy ezt külön megadtad, és mi volt a baj a default működéssel? Ahogy a man is egyértelműen leírja, így a belülről érkező kérés esetén is a külső címet oldja fel. Te pedig éppen ezt nem szeretnéd.

"talán a névfeloldáshoz kapcsolható: ha nincs internet, nem tudja feloldani a pasv címet"
"a vsftpd erre a dyndns címre oldja fel a passzív címet."
Természetesen ha az indításkor nem oldható fel a cím, akkor nem tudhatja, hogy abban a pillanatban mit csináljon.

man vsftpd.conf:
"pasv_address
Use this option to override the IP address that vsftpd will advertise in response to the PASV command."
"Default: (none - the address is taken from the incoming connected socket)"

"ha nem adom meg a pasv_address-t, akkor a helyi hálózati ip címet adja vissza a wan kliensek felé is, és nem a tényleges wan ip címet."
Ha jól értem, a vsftpdt futtató gépnek csak egy ethernet interfésze van, ami a LAN-ra van kötve a router belső interfészével együtt. Így a vsftpd nem is tehet különbséget a kliensek között. A router WAN IP-jét csak a router tudja beletenni vagy nem beletenni. A passzív portok tartományának a forwardját vedd ki a routerből, azt automatikusan kellene kezelnie. Az a sejtésem, hogy a manuális portforwardot előbb dolgozza fel a router, mint az FTP NAT-ot, így nem változtatja az adatrészben átvitt IP-t és portot. A 20-as port átirányítása pedig szintén felesleges.

Összefoglalva: a szervernek semmi köze ahhoz, hogy honnan jön a kapcsolat, a router NAT lekezeli.

"természetesen?" ezt nem értem. akkor mi értelme van a pasv_min|max_ports beállításnak?
igazából az az oka, hogy router tűzfalban mindent lezártam, és csak azt a pár portot engedem át, ami feltétlenül szükséges, és így könnyebb tűzfalazni, ha kevesebb a nyitott port és egy kisebb tartományban vannak. (elég buta egy firewall, de főleg az előző routerben, ott még butább volt)

"természetesen?" ezt nem értem. akkor mi értelme van a pasv_min|max_ports beállításnak?"
Elsősorban akkor lenne értelme, ha nem lenne előtte NAT. A router megtehetné, hogy ha tudja, megtartja a portszámot, de ezt nem kell garantálnia. Kevés kivételtől eltekintve nincs értelme.

"az az oka, hogy router tűzfalban mindent lezártam, és csak azt a pár portot engedem át, ami feltétlenül szükséges, és így könnyebb tűzfalazni"
Állapottartó tűzfal esetén nincs értelme a passzív kapsolatok portjait külön beengedni, sőt nagyobb lyukat nyit feleslegesen. FTP-nél az egyetlen kontrollcsatornát kell manuálisan átengedni, a többi a tűzfal dolga. Az FTP portforwardja nem csak egy egyszerű TCP NAT.

köszi az infót, így már kezdem jobban megérteni!
még egy utolsó kérdés: több helyen azt olvastam, hogy a connect_from_port_20 paraméter alapértelmezésben NO, de ezzel több ftp kliensnek bajai szoktak lenni, ezért pl. redhat install esetében ők alapértelmezésben YES-re állítják. így tettem én is, hogy ne legyen gond kliens oldalon. ezért volt a 20-as port is átengedve a routeren. akkor most erre szükség van? mármint a 20-as portra a routeren?