y2k (1.5.2006 23:50:12)
Již delší dobu řeším problém, fakt nevím jak dál...
Nemáte někdo nápad, jak docílit v kombinaci jedné veřejné IP adresy a proti tomu jedné "C" podsíťi směrování portů tak, aby byla dodržena ve směru z LAN do WAN číselná hodnota portu (jedná se o zdrojový port, cílový je samozřejmě dodržen) ? Provozuji zde směrování z WAN do LAN. Různé porty z WAN jsou směrovány na rozdílné PC v LAN. Potřebuji ovšem docílit, aby z jedné IP adresy v LAN bylo dodrženo při překladu IP adres a portů na routeru zdrojové číslo portu, jaké bylo odesláno z LAN PC aplikací. Odchází-li tedy z počítače X v LAN zdrojový port Y, tak aby při překladu na routeru byl z něj dále odeslán do WAN také jako zdrojový port Y.
Bohužel, ale při tomto překladu je na routeru zdrojový port Y většinou přeložen ze zdrojového Y na zdrojový port Z. Tento překlad mi způsobuje obrovské potíže, jelikož se v tomto případě jedná o odpověď na vyžádanou komunikaci. Protože se na straně, kde se provedl dotaz očekává odpověď ze zdrojového portu Y a ona skutečně dorazí po "špatném překladu" ze zdrojového portu Z, tak je komunikace na straně protihráče ve většině případů označena jako nevyžádána a tak je s ní i naloženo. Opravdu již nevím, jak na současném zařízení toto zabezpečit. Nejedná se mi o veškerou komunikaci, ale jen o jednu adresu LAN a na ní konkrétně o jeden port, který potřebuji zachovat 100% v nezměněné podobě (tedy číselné a to jak zdrojově, tak samozřejmě i cílově).
Zařízení : ZyXEL Prestige 662HW-63 s firmware 3.40-SC2-C1
NAT : momentálně SUA only + mapping set na IP v LAN dle portů
Moc dík za veškeré nápady, které jsou schopny řešit problém při současném HW vybavení. Rady typu PC a Linux fakt nepotřebuji........
Thorough (2.5.2006 13:39:21)
Popis je to sice chaotický, ale to chování jaké je teď je přirozené a toho čeho chceš docílit není přirozené. Navíc když se odešle požadavek, tak proces (aplikace), který ho odeslal čeká na odpověď na určitém portu, systém ve kterém proces běží čeká na odpověď na jiném portu a do cíle za routerem po překladu příjdou data, která mají uveden jako zdrojový port alias port pro odpověď taky jiný. Po cestě kterým data putují se postupně plní tabulka contrab podle které se porty při odpovědí zpětně přepisují resp forwardují a paket má v záhlaví příznak (ACK=1), který znamená, že jde o odpověď.
y2k (2.5.2006 14:49:51)
Za popis se omlouvám, ale podívej se, kdy vznikl ;-) To chování je opravdu přirozené, ale potřebuji jej zvrátit. Zapomněl jsem dodat, že se jedná o UDP paket. Nutně potřebuji docílit, aby při překladu byl dodžen zdrojový port. Je nějaká šance ?
Thorough (2.5.2006 17:29:25)
prakticky ne, protože ty porty dynamicky přiděluje systém..
y2k (2.5.2006 18:41:53)
Ale tos mi nepochopil.
Remote PC se táže zdrojovým portem X na cílový port Y
Router předá konexi
Local PC přijme relaci na cílovém portu Y ze zdrojového X
Local PC odpovídá zdrojovým portem Y na cílový port X
Router předá následně konexi :
zdrojový Y cílový X NAT zdrojový Z cílový X
Remote PC odmítá relaci s těchto důvodů :
očekává zdrojový Y na cílový X dle jeho tabulky
dostane zdrojový Z na cílový X
Tuto "vadu" samozřejmě vyhodnotí jen některé softwarové FW (v praxi jen ty, které hlídají i zdrojové porty) a většina routerů (z vyšší třídou NATu). Problém je v tom, že u mě na routeru je přeložen zdrojový port Y za zdrojový port Z. Potřebuji vymyslet takové nastavení, které dodrží číselně zdrojové porty (DMZ, úprava NATu na jednu IP, atd...)
y2k (2.5.2006 18:43:53)
Remote PC = jakékoliv PC v síťi internet
Router + Local PC = router + C LAN (1 PC > směrované porty)
Thorough (2.5.2006 19:12:26)
Právě že jsem tě pochopil :-) Jde o to, že cílový lokální počítač za NATem neodpovídá přímo na zdrojový port počítače, který odeslal požadavek, ale zdrojový port routeru. Zdrojový počítač nezkoumá, z jakého portu mu přišla odpověď, protože to je věcí vzdáleného systému, který neovlivní.
Zdrojový počítač pošle požadavek portem A na cílový port B
Požadavek obdrží router s NAT na portu B, předá ji lokálnímu PC na port B, čeká na odpověď na libovolném portu C
Lokální PC odpoví routeru na port C libovolným portem D
Router předá odpověď zdrojovému počítači libovolným portem E na zdrojový port A
Když ti na lokálním počítači běží třeba FTP server, tak ten přijímá požadavky na portu 21, ale odpověď vrací na portu, který si sám zvolí.
y2k (2.5.2006 20:23:10)
Přesně tak.
Jenomže u FTP a WEBu, Mailu atd., to nevadí, jenomže u datagramu v kombinaci s pařivkou je průser.... :-( Fakt mi už brnkají nervy, musí to nějak jít ;-)
JOE (7.5.2006 20:38:32)
Hm, to by asi chtělo nějakej sofistikovanější hardware, aby umožnil upravovat porty v NAT. Muselo by se asi také jednat jen o jednu lokální IP (což v Tvém případě je), protože jinak je jasné že každé PC z LAN musí za NATem dostat jiný source port, pokud by totiž dvě PC vyslali paket ze stejného source portu, nemohl by router poslat dva stejné pakety (veřejná IP a port), patřící dvěma různým PC. Z principu by pak musel všem ostatním local IP přidělovat jiné porty, ale jelikož předem neví jaké porty by zrovna chtělo použít ono privilegované PC, tak je to nesmysl. Mohlo by tedy jedině jít (pokud by to router uměl) nastavit local IP + source port, u které by router za Natem ponechal onen source port. Myslím že je to nesmysl. Jedině zakoupit více IP a vyřadit NAT.
y2k (8.5.2006 11:12:26)
Ano ano, to jsem se pokoušel řešit jako první možnost, ale to Nextra za žádnou cenu ke službám FUN a OFFICE nechce povolit......
Chjo, FORPSI.com toto nabízí k jakékoliv variantě i na linkách ČTc :-( Zatím zkouším vymýšlet pokusy z DMZ atd....., ale jsou to jen pokusy, bohužel....
Anonym (8.5.2006 13:23:40)
Taky nevím, proč na office linkách není možné přikoupit více ip :-(
