classic.ISPforum.cz

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.

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.

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

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

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

maxdevaine píše:Ří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).