Do diskuse momentálně není možné vkládat příspěvky. Děkujeme za pochopení.
Úvod > Diskuse > Obecná diskuse > mapování portů pro henrí server

mapování portů pro henrí server

Petr (18.6.2006 11:00:01)

čau, mám HL (CS) server. port vím, namapoval jsem nak pro tcp a udp, a stále se nikdo ke mně nedokáže připojit. poradí někdo ?

Anonym (18.6.2006 11:57:17)

S takhle debilnim popisem problemu ti nepomuze ani sam Bill Gates

Petr (18.6.2006 13:45:53)

XAVI 8122R port UDP 27015

y2k (18.6.2006 15:18:59)

Mno, sorry, ale neznám Tvé zařízení.

y2k (18.6.2006 12:17:28)

Tvůj popis problému je fakt dost chabý... Chybí zde jméno routeru, který používáš, čísla portů a ostatní informace. Ale pravděpodobně se jedná o problém, který řeším také a vyřešit lze jen dvěma způsoby : Musíš mít zařízení, které zvládne plnohodnotně přemostit (BRIDGE) linku na bázi IP. To znamená, zakončí linku PPPoA či PPPoE a jen vrstvu na bázi IP přemostí dál. Toto umí jen velmi málo routerů, protože většina předává dál i tunel (PPPoA a PPPoE) což v případě PPPoA je problém, neb PC neumí toto rozhranní řádně zakončit. A Ty potřebuješ nutně dostat pevnou veřejnou IP až na další PC, kde poběží server hry. Také je vhodné, aby na tomto PC běžel nějaký FW (Kerio WinRoute Pro), který bude ochraňovat a NATovat zbytek sítě. Akorát bacha, hra musí být aktivní na první síťovce, ještě před FW a NAT. Jako druhý způsob můžeš použít variantu, že si ponecháš jednu pevnou veřejnou IP pro své potřeby LANu (tedy za NATem) a zažádáš si o druhou pevnou veřejnou IP, kterou předáš (bez NAT!!) na nějaký PC v LANu, kde poběží hra. Osobně preferuji druhý způsob, ale konkrétně u mě jsem narazil na bariéru u ISP. Snad se dočkám toho, že po červenci vyházej u ISP staré struktury a půjde to jináč s lepšími lidmi :-) . K problému, Tvůj problém spočívá v tom, že server hry je za NATem, který v rámci zachování nejvyšší bezpečnosti překládá Tvé odchozí zdrojový porty na jiné. Tento překlad v 99% absolutně nevadí, protože router má záznam, kam má přeložit odpověď zpět tak, aby se data dostala zpět správně na Tvůj PC, z kterého byl vyslán požadavek. Tato funkce ovšem vadí ve hře, protože opět dochází k překladům. Jelikož se v tomto případě jedná o odpověď Tvého serveru vzdálenému klientovi, tak je to průser, protože klient dostane odpově'd z jiného portu, než jeho router očekává a komunikace je vyhodnocena jako nežádoucí a následně zahozena. Velmi zjednodušeně se klient táže na cílový port 28960 a po Tvém překladu se mu vrátí odpověď zpět z portu 25500, což je pro jeho FW neakceptovatelné. Pustil ses do docela složitého problému a předem říkám, že jestli nemáš alespoň základní vzdělání v oboru IT technologií a jestli nemáš slušného ISP, tak z tohoto problému nevybruslíš.

y2k (18.6.2006 12:21:58)

PS,- než začneš žádat a další pevnou veřejnou IP, tak si nejprve zjisti, jestli ji Tvé zařízení zvládne vůbec zpacovat !!!! Levné routery to většinou neumí. Pak by asi byl nejlepší PC z Linuxem a varianta 1.

Anonym (19.6.2006 07:43:16)

No ja bych zkusil jeste overit, jestli nema Win XP SP2 a netluce mu to firewall, aniz by o tom vedel...

Anonym (19.6.2006 09:08:16)

neboj netluče, z nouze jsem ho odstřelil i v paměti v Task Manageru

y2k (19.6.2006 16:48:05)

Tím FW na WinXP to nebude... Jinak lze vypnout "čistěji". Ve správci je to služba, která je "zbytečná". Akorát bacha, velký Bill zase něco zeslonil, protože když je v LAN více PC bez serveru z rozlišením WINS , tak se alespoň na jednom PC musí ponechat služba zapnutá. Jinak se PC v LANu přestanou navzájem vidět. Komunikace je pak možná jen přes \\IP nebo \\DNS . Ovšem DNS funguje až dlouho po startu... Prostě Gates, jak by řekl Kryten... Mááááááágóóóóóóóóó*.

Legi (20.6.2006 18:20:52)

Lol, no ty ses mi teda odbornik. Ja uz chtel reagovat na ten tvuj predchozi prispevek, ktery byl take, stejne jako tento, spojenim castecne pravdy a castecne nesmyslu. Je to normalni standartni "chovani" protokolu TCP/IP, pokud chces znat jmena, musis pouzit bud nejakou nadstavbu protokolu, nebo jiny protokol, nebo specialni server WINS. Protokol TCP/IP v sobe nenese jmena pocitacu a je jedno, na jakem systemu ho pouzivas. Pokud teda chces jmena znat a videt je v okolnich pocitacich a nemas WINS server, staci zapnout polozku "Povolit rozhrani NETBIOS nad protokolem TCP/IP". Snad uz budes vedet, kde to najit. Je to defaultne zakazano z bezpecnostniho hlediska. FW rozhodne kvuli toho zapnuty byt nemusi.

nick (20.6.2006 20:38:42)

Asi jsi ho nepochopil. On mluvil o tom, ze ve widlich ti to obsluhuje jedna sluzba. Pokud ji ve spravci sestrelis, pripravis se o preklad jmen PC v lokalni siti. Proto to lze vypnout cisteji, jak y2k pise. Pak se vypne jen FW a neprijdes o preklad jmen... Jinak problem bych videl ve spatne nastavenem port forwardingu, pac HL(CS) je bezproblemova aplikace a za NATem nedela zadney bordel a to jsem to forwardoval pres dva preklady adress / NAT. nick

Legi (21.6.2006 20:03:54)

No nevim. Nevim, jestli to myslel takhle a ani nevim, jaky je rozdil v tom, jestli sluzbu "killnes" nebo "stopnes". Kazdopadne o ni prijdes. Pokud teda jen nemyslis vypnuti firewallu jako volby v nastaveni. Jenze mam dojem, ze mluvil o sluzbe a jejim vypnuti jako takove. Kazdopadne ji nepotrebujes, pokud pouzijes NETBIOS. Je to sice zastaraly protokol pro rozlisovani jmen, ale z duvodu kompatibility se porad pouziva. Nebo se pletu? Pokud jo, necham si to vysvetlit :)

y2k (21.6.2006 22:23:26)

Takže, TCP/IP není protokol, ale instrukční sada různých protokolů jako třebas : HTTP (HyperText Transfer Protocol) NNTP (Network News Transfer Protocol) TFTP (Trivial File Transfer Protocol) FTP (File Transfer Protocol) SNMP (Simple Network Management Protocol) NTP (Network Time Protocol) LDAP (Lighweight Directory Access Protocol) WHOIS rlogin a jiné... Zajisté je Ti známo, že se sada protokolů TCP/IP skládá z aplikační, transportní a síťové vrstvy spolu z další nadstavbou síťového rozhranní. Nebavil jsem se do podrobna o NETBIOSU a jeho implementaci do OS WinXP a jeho vazbách na různé systémové služby. Předpokládal jsem, že narozdíl od Tebe čtou diskuzi buď amatéři a nebo lidé, kteří IT rozumí. V obou případech mé vysvětlení stačilo, neb amatér tak provede a zkušený uživatel si to vyzkouší. Ovšem zapomněl sem na kategorii trablemakerů, kteří si přečetli pár článků a jsou ihned kovanými odborníky jako Ty. Proto jsem psal, že jde sice vypnout úplně služba brány ICS a sdílení připojení k síťi internet, ale že když to uděláš na všech PC v LANu, tak se po určité době přestanou mezi sebou navzájem ostatní PC vidět bez ohledu na NETBIOS. Bohužel, ale služba brány firewall je takto hloupě provázána a alespoň na jednom PC v LAN (který je zapnutý jako první a nebo furt) musí být tato služba zapnuta. Jediná výjimka je tam, kde jede server WINS, protože ten plnohodnotně nahradí službu NETBIOS. Mám pro Tebe radu, když něco neznáš, tak se raději nevtírej, protože co příspěvek v této diskuzi, to hloupost ! Pls, no flame.

Anonym (21.6.2006 22:56:21)

No trosku v tom mas hockey. Rekneme ze mame zaklad IP protokol na sitovy vrstve. Ten je jenom jeden a neni to zadna sada protokolu. To by byl teda dost velkej hukot tuhle celou sadu nekde ve stacku implementovat to ti reknu. Kdyz se mrknes do /etc/services tak se ti protoci ocka co tam toho je. Jo kde jsem to prestal. Tak potom nad nim jsou TCP a UDP. No a pak mas na aplikacni vrstve tyhlety ostatni wergly jako HTTP,FTP a tak dal. Este v tom vetsi bordel dela ten SNMP ktere j je implementovanej mimo IP i na IPX a ATM. Proste tydle aplikacni protokoly muzou defacto fachat i jinde nez na IP.

Legi (22.6.2006 09:12:03)

No, vypada to, ze jsi opravdu na slovo vzaty odbornik. Takze TCP/IP definuje, jak ma vypadat HTTP, FTP atd. No lol. Reknu ti to takhle: TCP i IP jsou protokoly, coz je zrejme uz z nazvu - P je "Protocol". Nejniz z techto protokolu je protokol TCP (nebo druhy jednodussi UDP). Ten pripravuje data, deli je na balicky, ridi prenos, zajistuje cestu. Teprve nad nim je protokol IP, ktery zastresuje chovani TCP v internetu, tzn. zajistuje to, aby se ty balicky dostaly na spravne misto ve spravnem poradi. Urcite je ti znamo, ze v internetu muze jit kazdy balicek svou cestou. Dulezite je zpatky poskladat. Na to se nabaluji dalsi tzv. aplikacni protokoly, ale to uz jsou protokoly definovane pro urcite sluzby, aplikace apod. jako prave HTTP, FTP... Ono se tomu rika sada protokolu TCP/IP, ale prave proto, ze jsou na TCP/IP postaveny. Pokud teda jako odbornik pises, ze se sada protokolu TCP/IP sklada z aplikacni, transportni a sitove vrstvy, pak bys mel vedet, ze ta aplikacni je uplne nejvys a jsou to prave protokoly jako HTTP, transportni vrstva jsou mj. protokoly TCP, UDP, IP a uplne nejniz je sitova vrstva. Obracene - sitovou vrstvu vubec nezajima, jakym transportnim protokolem jsou data prepravovana, stejne jako protokol TCP/IP nezajima, jestli nese data protokolu HTTP nebo jineho. Doufam, ze jsem ti to vysvetlil dostatecne laicky, protoze mam dojem, ze jsi si neco nastudoval, ale mas v tom chaos. Mozna by nebylo od veci, kdyby sis zkusil takovy prenos dat naprogramovat. Nevim, jestli bys to umel, protoze ja to umim, ale aspon by ti to pomohlo pochopit princip. Mam pro tebe radu na zaver - kdyz neco neznas, tak se nevtirej, protoze co prispevek, to hloupost :))

Anonym (22.6.2006 09:24:04)

Omlouvam se za chybu, IP nepatri do transportni vrstvy, ale vrstvy sitove. Jsem to psal citove rozrusen :)

y2k (21.6.2006 22:45:52)

Přesně tak. Hru HL(CS) neznám, ale mám bohaté zkušenosti z CoD a to je opravdu nepropracovaný . Sice je hra úžasná, ale rozjet ji plnohodnotně za NATem je fakt žůžo. Většinou to dopadne tak, že se polovina lidí nepřipojí a Ti, kteří se připojí hrají vždy na jiném portu, než je správný, pakliže nejsou připojeni jako první. Zpravidla nevadí starší verze NATu a některé verze FW (kupříkladu zrovna ten ve WinXP).

y2k (21.6.2006 22:50:56)

Ještě upřesnění.... "vždy na jiném portu, než je správný" Klient se připojuje na IP XXX.XXX.XXX.XXX port 28960, ale díky NATu na mé straně hraje ve skutečnosti na IP XXX.XXX.XXX.XXX port 29654. Na serveru je samozřejmě vše v pořádku, překlad portů nastane až na mém routeru. Tento překlad ovšem nestráví všechny HW a SW :-(

Legi (22.6.2006 13:56:43)

Tohle je urcite "zvlastni". Muzes napsat, kde, na ci strane a jak jsi ten port zjistil? Co znamena, ze je to na strane serveru v poradku? To spise vypada, ze to bude ten pripad, kdy server otevira dalsi komunikaci (jako FTP v active modu, jak jsem psal vyse). Pak by bylo jasne, ze port bude prelozen. Zkousel ses podivat treba pomoci TCPView, ktere porty ma server otevrene? Neni to tak, ze by port 28960 zustaval otevreny pro pripojovani dalsich klientu a uz pripojene klienty spojoval na jinych portech? Nevim, tuhle hru neznam. U vsech standartnich spojeni (HTTP, FTP, VPN, VNC atd.) mi zustava port stejny, to vim nabeton. Muzu ti poslat i vypis z logu nejakeho analyzeru. Pokud se pripojuju na HTTP, tak z HTTP mi odpoved prijde, at jsem za NATem ja, Server, nebo oba.

y2k (22.6.2006 17:13:47)

Konečně, pochopils. Snad se přestaneme hloupě hádat a splodíme něco rozumnějšího. Analizoval jsem pakety programem ETHERDETECT jak za serverem, tak za routerem. Tedy před i za NAT. Před NAT je vše vpořádku. Vynechám-li mašinérii na routeru a na straně klienta, tak proběhne požadavek na správný otevřený port 28960 z libovolného zdrojového portu a je vždy korektně odpovězeno klientovi na zdrojový port, z kterého se táže. Odpověď samozřejmě vždy proběhne ze správného portu 28960, který je pro tuto relaci již jako zdrojový. Toto pravidlo platí bez ohledu na připojené klienty a jejich počet. Ovšem za routerem (NAT) je již skoro vždy průser. Zde je původní zdrojový port 28960 přeložen dle náhodného algorytmu někam jinam. Vše ostatní samozřejmě sedí. Tato "chyba" se stane takřka vždy, pouze někdy, když se připojí klient jako první po dlouhé nečinosti, tak je zdrojový port na NATu ponechán. Tato "chyba" se děje na několika zařízeních (Cisco; ZyXEL; 3COM; Edimax a SW příkladně Kério WinRoute Pro). Ona to vlastně není ani chyba, ale správná funkce NATu, tedy přesněji řečeno pouze NATu typu "Port Restricted Cone NAT a Restricted Cone NAT". Ostatní dva typy NATu "Full Cone NAT a symmetric NAT" nejsou tímto zasaženy. Na straně klienta také nemusí být vždy zle. Když on sám má na routeru NAT typu "Full Cone NAT", tak ke spojení dojde, ač ve skutečnosti hraje na jiném portu, než se při připojení dotazoval. To samé platí pro některé SW firewally (příkladně z OS WinXP). Pravděpodobně se jedná o ty, které nekontrolují zdrojové porty, ale to nemám prakticky vyzkoušeno. Tak, snad jsme se konečně dohodli a došlo k pochopení problému, který jsem se snažil jen povrchně popsat tazateli.

Legi (22.6.2006 21:09:32)

Ja tomu, jak to myslis ty, rozumim celou dobu. Jenze jak jsem psal, u mne se to takhle nechova. Mam to vyskouseno jak na HW routeru, tak ne Kerio Winroute. Zkousel jsem to kvuli tobe dokonce z NATu do NATu. Zkousel jsem ty sluzby, co jsem psal - HTTP, FTP, VNC. Odpovedi vzdy prichazeji ze spravneho portu. Jak rikam, zrejme se CoD chova jinak a je to otazkou aplikacniho protokolu. Boje o tom, co je TCP nebo UDP, jsou tady zbytecne. Schvalne si zkus treba jen HTTP. Jestli se ti neco vrati z jineho portu, tak jsem papez :) Samozrejme predpokladam, ze server bude za NATem. Chces rict, ze SYN packet prijde odpoved ACK z jineho portu? Tomu neverim. Na druhou stranu je fakt, ze u UDP to bude asi jine. To ted nevyzkousim. U UDP se nesestavuje spojeni, mozna proto router bere odpoved jako samostatnou komunikaci, kterou uz musi prelozit. Ja nejsem sitar, tuhle problematiku podrobne neznam. Jen vim, jak se chovaji tyhle protokoly z hlediska programovani.

y2k (22.6.2006 21:21:04)

Záleží na tom na jakém typu NATu jsi to zkoušel. Ale obecně TCP je vpohodě a z UDP jsou problémy. Zkus toto nasimulovat a uvidíš...

NEO (24.6.2006 16:39:31)

mas recht me to dela taky skoro nikdo si nezahraje btw ten legi je nejaky chytrolin

Legi (26.6.2006 09:48:31)

Hehe, jsem :)

Anonym (19.6.2006 16:56:35)

A co firewall/ip filter v modemu??? :)

Stoupa (19.6.2006 18:29:53)

taktéž OFF

Legi (20.6.2006 18:45:26)

Musim ted reagovat i na tohle. Ja nejdriv reagoval na prispevek nize, tam by uz tahle reakce byla jaksi mimo. To ze NAT preklada porty je pravda. Neni to ani tak z hlediska bezpecnosti jako nutnosti. Kdyby byly v siti treba 3 pocitace a vsechny najednou sahaly na FTP port 21, tak by to bylo v podstate nemozne. Proto se tyhle porty prekladaji do jineho rozsahu. U profesionalnich zarizeni (treba CISCO) je samozrejme mozne porty neprekladat, protoze to je opravdu nekdy nutne. Protoze jsou ale tyhle routery predem urceny na domaci pouziti, tahle funkce u nich chybi. V zadnem pripade se nemuze stat, ze klient odesle pozadavek na jeden port a dostane odpoved z jineho portu. NAT port prelozi na jiny port pro server, ale klientovi se uz zpatky vraci opdoved z puvodniho dotazovaneho portu. Kdyby tomu tak nebylo, vubec by z principu nebylo spojeni mozne. O tom se lze presvedcit v jakemkoliv packetovem analyzeru. Problem muze nastat jedine v pripade, ze tento server predpoklada prichozi komunikaci z urciteho portu a ta prijde prave z jineho - prelozeneho NAT-em. Tohle ale neni v zadnem pripade tento pripad. Neznam zadnou hru, ktera by vyzadovala spojeni konkretnich portu, vzdy byva pouze stanoven port, na kterem hra nasloucha. To si lze taky snadni overit v analyzeru. Pro odchozi komunikaci pak byva zvolen nahodny port, stejne treba jako u internetoveho prohlizece. NAT teda preklada nejen ve smeru tam ale i zpatky. Kdyby ne, nemohl by si clovek ani precist postu. Co se tyka problemu Petra, mohl by se rozepsat, ktere porty kam nasmeroval, kazdopadne na internetu se daji najit navody na forwardovani "steamovane" verze. Na verzi bez steamu jsem nikde nic nenasel. Mozna to bude totez, ale protoze tu hru nemam, nemam to jak overit

Anonym (21.6.2006 08:38:58)

Zkusil jem BIMAP, pak RDR ((http://www.portforward.com/english/routers/port_forwarding/Xavi/8021R/Steam_Server.htm)), vše s portem 27015. Ve finále mi server zobrazí IP 10.0.0.xxx:27015, na kterou je možné se připojit. Ale nikdo se nepřipojí.

Nargon (21.6.2006 09:00:45)

Hmm, poradil bych asi tohle: Nainstalovat na PC firewall. Nastavit BIMAP pravidlo. To smeruje vsechno na PC s uvedenou IP. Pak vypnout IP filter (Secure Level NONE). Ted opravdu staci nastavovat softwerovej firewall (imho je to mnohem jednoduzsi nez ten v tom modemu a muzes si vybrat firewall ktery ti vyhovuje. Ikdyz sw firewall nechrani tak dobre jako hw (pred utokem z internetu je asi stejne dobrej, ale pokud mas v PC iteligentniho vira, tak si muze odesilat data a firewall o nem nevi :)) To ze se ti server zobrazi jako 10.0.0.1:27015 je pouzitelne jen pro tvoji sit. Z PC ve tve siti se na ten server s pouzitim tehle IP a portu dostanes. Ale z internetu ne. Pokud tohle zada nekdo v internetu, tak to hleda v JEHO siti. A tam ten server mozna take bezi, ale urcite to nebude ten tvuj. Lide co se na tebe chteji pripojit musi pouzit tvoji verejnou IP (napriklad: 1.2.3.4:27015) Router v modemu, diky Bimap pravidlu toto presmeruje na 10.0.0.1:27015 a uz se ten clovek pripoji na tvuj server. Svoji verejnou IP zjistis treba tady: http://www.whatismyip.com/

Petr (21.6.2006 10:30:34)

díky zkusím, FW mám na kompu furt, alre ještě jsem nikdy nezkusil Secure Level NONE. Večer napíšu výsledek ...

Nargon (21.6.2006 10:49:36)

Tak to je ta chyba :DD Tenhle modem patri mezi ty "blbejsi" (podle me)nebo podle nekoho "chytrejsi" a proste kdyz si forwardujes port v natu, tak tenhle firewall je schopny ten port stale blokovat, proto se nikdo nemuze pripojit. A doporucuji pouzit BIMAP pravidlo. To presmeruje vsechny porty na pocitac. Pokud totiz vypnete ipfilter tak se z internetu muze nekdo pripojit na konfiguraci modemu. A jestli tam jeste mate defaultni heslo, tak je to jako nechat odemceny dvere, kdyz jdete z domu. Pri pouziti bimap se presmeruje i port 80 dale, a uz neni mozne se z internetu dostat na ten modem, pripadny utocnik bude az na PC :) Tam by se stejne po nastaveni modemu mohl dostat, ale takhle alespon nemuze rekonfigurovat modem.

Petr (21.6.2006 18:44:32)

použil jsem tvůj postup z jiný debaty, funguje, díky moc ...

Dan (6.11.2006 22:25:47)

10.****** je mistni adresa pro vyuziti v lokalni sitich. (viz Linux prirucka. :) ), stejne jako 192.168.***.***. Na tuhle adresu se ti nikdo zvnejska nepripoji, protoze kdyz ji napise ve svym pocitaci, jeho packety jdou pouze do lokalni site a ne ven, k tomu jsou tyhle adresy urceny (podniky, testovani, atd.)... takze pokud se ti ukazuje 10.*, nebezis.. :)

y2k (21.6.2006 20:44:55)

Ale, i Ty brepto .... Od toho má router směrovací tabulku, aby si do ní zapsal který PC se táže na který port tak, aby dokázal vrátit odpověď zpět. Právě toto dokázal paketový analyzér. Klient se táže na cílový port X. Aplikace odpovídá již ze zdrojového portu X. Router přenatuje zdrojový port X na port Y, který se dostane ke klientovi. U něj je ovšem zdrojový port Y zahozen, protože se očekává odpověď ze zdrojového portu X. Pravděpodobně si nepochopil, že se jedná o zdrojový port, ne cílový, ten je samozřejmě dodržen, jinak by komunikace nemohla fungovat, jak si správně napsal.

y2k (21.6.2006 22:40:58)

Ještě pro upřesnění, nesmíš zapomenout, že dotyčný chce ze sebe udělat server, což je pro koncové zařízení (levný router)něco, na co není příliš upraven. On je totiž rozdíl, jestli NATuješ odchozí komunikaci (zde překlad zdrojových portů fakt nevadí) a nebo když NATuješ odpovědi ze serveru, který je schovaný v LANu. Zde již za jistých okolností překlady zdrojových portů vadí, hlavně tehdy, když na to není aplikace přizpůsobena. Předpokládám že dokážeš pochopit, že když se tážeš na cílový port X, tak očekáváš odpověď ze zdrojového portu X. Když Ti něco po cestě změní zdrojový port X na Y, tak za jistých okolností u nějakého HW a SW může dojít k zahození paketu.

Legi (22.6.2006 08:35:53)

My si pravdepodobne asi nerozumime :) Podle toho co popisujes to vypada, ze se bavis ne o komunikaci samotneho protokolu TCP, ale protokolu nekde nad nim, ktery je otazkou implementace v aplikaci. Ja bych to pospal tak: klient se taze na cilovy port X ze zdrojoveho portu Y. Na natu je samozrejme Y prelozen dejme tomu na Z, ale packet putuje dal na port X. Server obdrzi na svem X dotaz a odpovida na port Z. Pri ceste zpet je tedy cilovy port Z prelozen zpet na Y a klient obdrzi odpoved na svem puvodnim zdrojovem portu, ale porad je to odpoved z portu X. Zrejme uvazujes o dalsi komunikaci, kdy server navazuje dalsi komunikaci ke klientovi. To uz je ale fakt otazka toho, jak je ktera aplikace naprogramovana. Pokud vezmu v potaz treba klasicke HTTP a chovani Internet Exploreru nebo jakehokoliv jineho browseru. Kliknu na odkaz a pripojuju se z nahodneho zdrojoveho portu Y (treba 12345, to je jedno) na cilovy HTTP port 80 - X. Zdrojovy port muze byt na NATU prelozen na treba 54321 - Z, ale putuje na X port 80. Veskera odpoved serveru z portu 80 je smerovana na prelozeny port Z 54321, na NATu je zpet prelozen na 12345 a IE tak obdrzi spravne odpoved. Prichazi vsak stale z portu 80. Obdobna situace je i treba v protokolu FTP v passivnim modu, jen tech portu je tam vice. Neco jineho je FTP v aktivnim modu. FTP klient posila dotaz z libovolneho portu (treba 12345) na port 21. FTP server odpovida na port 12345, ale dalsi komunikaci uz navazuje server (je aktivni). Protoze ji navazuje on, rozhoduje sam, z jakeho portu bude - jestli obligatni datovy port 20 nebo nejaky nahodny. Smeruje ji na puvodni port urceny klientem, ale protoze zdrojovy port je uz jiny, router packet opravdu zahodi. Proto se musi u pripojovani na FTP z NATovane site pouzit passive rezim, ve kterem si komunikaci ridi klient. Server mu pouze posle port, na kterem nasloucha, aby port 21 zustal volny pro dalsi spojeni. Jenze tohle vsechno uz je otazkou protokolu, ktere jsou nad standartem TCP. HTTP, FTP a jakykoliv jiny protokol maji sva pravidla a ty muzou opravdu delat problemy. Neni to ale pripad hry HalfLife ani zadne jine. Aspon o tom nevim. Tyhle aplikace se chovaji obdobne jako treba IE. Proste klient navazuje komunikaci a stale si ji ridi. Server jen zpatky odpovida. Kdyby to tak nebylo, tak by si asi nikdo nezahral.

y2k (22.6.2006 16:56:50)

TCP/IP = sada kominikačních protokolů TCP = Transmission Control Protocol IP = Internet Protocol Tento protokol (TCP/IP) se používá po celé síťi Internet a nejenom na ni. Příkladem jeho dalšího použití mohou být platformy jako UNIX, Banyan VINES, Microsoft LAN Manager či Novell NetWare. Přestože se stal standardním souborem protokolů teprve v poslední době, je starý již více jak dvacet let. V počátku byl použit pro spojení vládních počítačů (síť ARPANET - předchůdce dnešního Internetu), nyní je jeho největší využití právě v síti Internetu, jenž se stala největší celosvětovou sítí. Jako TCP/IP standard se tento síťový protokol začal prosazovat v době, kdy byl implementován do systému UNIX a jemu podobných, zhruba někdy kolem 80 let. Díky této podpoře a zároveň díky jeho vyplývající historické kompatibilitě vůči velkému množství hardwarových a softwarových systémů se dnes těší velké rozšíření. Tolik z teorie o TCP/IP. Stále si ale nepochopil, že 99% pařivek používá datagramy, tedy protokol UDP. Také si stále nepochopil, že v 99% přpadech jsou tyto servery umístěné viditelně na síťi internet (nejsou "schované" za NAT, jak požaduje tazatel) Ty neustále popisuješ chování NATu na straně klienta a nechceš si připustit, že NAT je v tomto případě i na straně serveru. Použiju-li Tvůj model, tak situace vypadá takto : Ja bych to pospal tak: klient se taze na cilovy port X ze zdrojoveho portu Y. Na natu NA STRANE KLIENTA je samozrejme Y prelozen dejme tomu na Z, ale packet putuje dal na port X. Server ZA NATEM obdrzi na svem X dotaz a odpovida ZE ZDROJOVEHO PORTU X na port Z. Pri ceste zpet je NA NATU NA STRANE SERVERU tedy cilovy port PONECHAN A JE ODPOVEDENO NA Z a ZAROVEN JE PRELOZEN ZDROJOVY PORT X NA ZDROJOVY PORT B a klient obdrzi odpoved na svem puvodnim zdrojovem portu, ale BOHUZEL je to odpoved z portu B, NA KTEREM NENI ODPOVED OCEKAVANA, PROTOZE SE OCEKAVA NA PORTU X. Doufám, že alespoň pochopíš, co jsem doplnil. Kdyby se Ti to zdálo moc složité, tak doplněný text je psaný velkým písmem (velké písmenko se píše z klávesou SHIFT nebo CAPS LOCK). Snad Ti bude vysvětlení stačit, ač v to nevěřím.....

Anonym (6.11.2006 23:44:47)

To jak to popisuješ je správně, akorát mě překvapuje, že alespoň některé hry neumí techniky porážení natu, třeba UDP hole punching. Zase tak složitý to není... to by mělo fungovat i v NAT - NAT módu.

Anonym (19.6.2006 08:57:35)

Hmm, divny. Jsem dospod hodil podrobnej navods a nejakej admon to smazal s dalsima prispevkama. Asi holt nema zajem aby ti nekdo radil :-(((

Petr (20.6.2006 08:36:12)

moc blbé ...

Anonym (25.6.2006 11:18:10)

spravne to ma byt "henry server"