veřejná IP<>private IP problém s FTPSSL

[milanc]

Ahoj,
mám server, na kterém běží proftpd (TSL on, SSLv23). Pokud byl tento server přímo v housingu a na interafcu měl veřejnou IP, bylo vše ok.
Server se fyzicky přemístil do LAN a má IP 10.0.3.99/24.
Na igw mikrotiku mám tyto pravidla

add action=dst-nat chain=dstnat disabled=no dst-address=82.99.161.24 to-addresses=10.0.3.99
add action=src-nat chain=srcnat disabled=no out-interface=ether9 src-address=10.0.3.99 to-addresses=82.99.161.24

ether9 je rozhraní k ISP.

Zabezpečené FTP spojení navazuje z internetu perl skript (pasivně), ale momentálně nefunguje. Sice se naváže, pak dlouho visí a následuje timeout.
Mám podezření, že mám něco špatně v tom promapování, protože na klientovi se v ftp-debug objevuje privátní IP 10.0.3.99 - možná je to tak ale správně (protože mikrotik to těžko v zašifrovaných paketech změní)?
Otázka je, jestli je to nějak řešitelné. Možná hledám chybu na špatném místě. Podstatné je to, že pokud má server přímo veřejnou, vše chodí bez problému.

Kód: Vybrat vše

root# ./down_ftp.pl
Net-FTPSSL Version: 0.22
Perl: 5.014002  [5.14.2],  OS: linux
Server (port): 82.99.161.24 (21)

Keys: (Debug), (Passive)
Values: (1), (1)

SKT <<< 220 ::ffff:[b]10.0.3.99[/b] FTP server ready
SKT >>> AUTH TLS
SKT <<< 234 AUTH TLS successful
>>> USER +++++++
<<< 331 Password required for <++++++>
>>> PASS *******
<<< 230 User <++++++> logged in
>>> TYPE I
<<< 200 Type set to I
>>> CWD LED-0162
<<< 250 CWD command successful
>>> PBSZ 0
<<< 200 PBSZ 0 successful
>>> PROT P
<<< 200 Protection set to Private
>>> PASV
<<< 227 Entering Passive Mode (10,0,3,99,219,149).
--- Host (10.0.3.99)  Port (56213)
connect: Spojení bylo příliš dlouho neaktivní at /usr/lib/perl5/Net/SSLeay/Handle.pm line 229.


[midnight_man]

Sú služby a protokoly ktore ti cez NAT nepôjdu, napr IPSEC a podobne....pravidlá maš podla mna dobre, je to NAT 1:1.

[milanc]

Děkuji.
Je to tedy tak, že šifrované FTP skrz nat nikdy fungovat nebude?
Není možné, že to je problém jen dané perl knihovny?
Když totiž z internetu zkusím FTPS z total commandera (passive), tak se bez problému připojím (z PC s veřejnou i z PC za NATem).

Milan

[maxdevaine]

Ahoj,
máš špatně nastaven proftpd.
Pokud je za natem, tak musí klientovi vracet prublic IP. Musíš v proftpd tedy nastavit :
MasqueradeAddress

V tom logu je to jasně vidět.
Total CMD možná takové věci ignoruje, což nevím, zda je dobře, nebo špatně.

ad : midnight_man
Říká vám něco NATT? Resp. NAT-TRAVERSION u IPSECu? Pak byste jistě věděl, že i IPSEC proleze skrz NAT.
Navíc třeba takový krabky od Zyxelu (USG100 apod.) mají nějakou techniku, že dokážou navázat tunel i bez NATT. Nezkoumal jsem, jak to dělají, ale asi to nebude moc čisté řešení, takže osobně všude s ipsecem a NATem používám NATT. V takovém případě pak stačí k serveru forward nejden UDP 500, ale i UDP 4500 pro NATT, pomocí nějž se pak obchází NAT vs. UDP vs. špatné checksumy.

Zdar Max

[milanc]

Díky Maxi!
Tuhle featuru jsem neznal, už to zase šlape jak má.

[Majklik]

Říká vám něco NATT? Resp. NAT-TRAVERSION u IPSECu? Pak byste jistě věděl, že i IPSEC proleze skrz NAT.
Navíc třeba takový krabky od Zyxelu (USG100 apod.) mají nějakou techniku, že dokážou navázat tunel i bez NATT. Nezkoumal jsem, jak to dělají, ale asi to nebude moc čisté řešení, takže osobně všude s ipsecem a NATem používám NATT. V takovém případě pak stačí k serveru forward nejden UDP 500, ale i UDP 4500 pro NATT, pomocí nějž se pak obchází NAT vs. UDP vs. špatné checksumy.
Zdar Max

NAT-Traversal není všemocné. A přišel na to i MS a od dob Win7 se snaží za každou cenu mu vyhnout (upřednostněním IPv6, dokonce i za cenu tunelování IPv6 skrz IPv4 (máli kompl neveřejku, tak pomocí Teredo, když má náhodou veřejku, tak 6to4, když vše selže, tak IPsec in HTTPS, ...).
A navíc NAT-T na straně serveru pro většinu režimů použití znamená konec důvěryhodnosti IPsec, pokud jedna za stran (či obě) jsou produkty Microsoftu. Také před takovým nasazením důrazně varují (NAT-T na straně klienta je OK).