[es] - Router bypass (port forwarding, tunneling... sta?)

((BugA))
Igor Djordjevic
Bor, Srbija

Član broj: 29241
Poruke: 196
91.150.101.*

ICQ: 66516695
Sajt: www.MalamutKlub.com

+17 Profil

Router bypass (port forwarding, tunneling... sta?)

^{13.02.2010. u 14:16 - pre 172 meseci}

Pozdrav svima :)

Nisam nasao funkcionalni odgovor na netu (ili nisam znao sta tacno da trazim?), a kako nisam vican mreznim protokolima zamolio bih za pomoc iskusnije programere. Sta je problem? U pitanju je igra (Age of Empires 2, DirectX7, DirectPlay), koja za igranje preko neta (rutera) trazi otvorene (forward) portove od 2300 do 2400 (tcp/upd), i port 47624 (tcp). Najlakse je forwardovati potrebne portove, i nema zime - medjutim, ideja je da se vecem broju korisnika koji se ne snalaze sa podesavanjima routera omoguci online igranje bez glavobolje.

Kako programirati aplikaciju (klijent/server) koja moze omoguciti igranje bez potrebe za otvaranjem portova?

E sad, da ne bi neko rekao kako ne moze, da ne znam da moze ne bih ni pitao ;) Primer je program GameRanger, koji radi upravo to - i pored zatvorenih (tj. neprosledjenih) portova omogucava igranje bez ikakvih problema. Iako i na samom sajtu programa pise da ne znaci da ce uvek sve raditi kako treba, u velikom broju (mislim preko 90%) slucajeva korisnici koji inace ne mogu da igraju preko neta (zbog rutera ili raznih problema sa portovima), preko GameRanger-a igraju sasvim valjano.

Za one koji imaju iskustva sa mreznom komunikacijom i citanjem logova, prilazem Wireshark logove, uz objasnjenja.

(napomena - portovi nisu forwardovani)

GameRanger(start,idle,close).pcap -- pokrecemo aplikaciju GameRanger, ostavljamo je da radi, gasimo je.
GameRanger(start,idle,host,close).pcap -- pokrecemo aplikaciju GameRanger, ostavljamo je da radi, otvoramo novu sobu (host), gasimo aplikaciju. Prilikom otvaranja (host-ovanja) sobe aplikacija prijavi da portovi nisu otvoreni, i nudi par opcija medju kojima biramo "Continue" - bez obzira na obavestenje i na zatvorene portove, ipak sve radi kako treba,
GameRanger(host, play).pcap -- aplikacija vec radi, soba vec otvorena (host). Prikljucuje nam se drugi igrac, ukljucujemo Wireshark log-ovanje, pokrecemo igru (start, launch). Pojavljuje se meni igre na kom vidimo i drugog igraca (uspesno ostvarena konekcija i pored zatvorenih portova oba racunara).
GameRanger.pcap -- (isto kao prethodno, drugi primer) aplikacija vec radi, soba vec otvorena (host). Prikljucuje nam se drugi igrac, ukljucujemo Wireshark log-ovanje, pokrecemo igru (start, launch). Pojavljuje se meni igre na kom vidimo i drugog igraca (uspesno ostvarena konekcija i pored zatvorenih portova oba racunara).

Da li neko ima neku ideju kako se ovde ostvaruje komunikacija (iz prilozenih logova, ili iz iskustva..?), i kako da nesto slicno sami napravimo? Odgovaralo bi u C#, ali ni C++ nije problem, samo da nadjemo resenje :) (mislim da je i GameRanger radjen u C++). Idealno bi bilo da se komunikacija odvija p2p (direktno izmedju igraca), a da eventualno server posluzi kao posrednik pri ostvarivanju konekcije.

Hvala unapred.

_{[Ovu poruku je menjao ((BugA)) dana 13.02.2010. u 20:13 GMT+1]}

Odgovor na temu

((BugA))
Igor Djordjevic
Bor, Srbija

Član broj: 29241
Poruke: 196
*.dynamic.isp.telekom.rs.

ICQ: 66516695
Sajt: www.MalamutKlub.com

+17 Profil

Re: Router bypass (port forwarding, tunneling... sta?)

^{15.02.2010. u 16:26 - pre 172 meseci}

Izgleda da sam nasao resenje - "UDP hole punching".

Ovo se cini idealnim :) Za one koji nisu upoznati, samo ukratko pojasnjenje...

Imamo klijente A i B (igraci koji zele da igraju igru), i server S (javni server koji i inace hostuje lobije/sobe za igrace). Pre objasnjenja, prvo napomena - kada klijent posalje poruku preko odredjenog porta, on logicno ocekuje neki odgovor sa adrese na koju je poruku poslao - sto znaci da ovo ostavlja port otvorenim, i klijent osluskuje hoce li biti odgovara sa IP adrese na koju je poslao poruku. Kako se sad odvija komunikacija bez forwardovanja portova?

Oba klijenta (A i B) salju poruku serveru S i uspostavljaju komunikaciju sa serverom. Server S pamti IP adrese i portove sa kojih su poruke poslate (npr. A = 1.1.1.1:1000, B = 2.2.2.2:2000). Sada se desava glavna caka - server S nalozi klijentu A da posalje poruku klijentu B (1.1.1.1:1000 -> 2.2.2.2:2000). Klijent A salje poruku klijentu B, ali klijent B odbija da primi poruku jer ne ocekuje odgovor sa IP adrese klijenta A (a pritom port nije forwardovan). Medjutim, klijent A sada ocekuje poruku sa IP adrese klijenta B, ne znajuci da je ovaj poruku blokirao (klijent A osluskuje svoj port 1000, koji je ostao otvoren nakon slanja poruke). Server sada nalaze klijentu B da posalje poruku klijentu A (2.2.2.2:2000 -> 1.1.1.1:1000), i obzirom da je klijent A vec iscekivao odgovor sa adrese na koju je poslao svoju poruku, on prihvata poruku klijenta B kao odgovor na svoju prvobitno poslatu poruku (ne znajuci da je ta prva poruka blokirana).

Ovime je komunikacija i zvanicno uspostavljena - sada klijent B iscekuje odgovor klijenta A (klijent B zadrzava otvorenim svoj port 2000), i kada klijent A posalje novu poruku klijentu B on ce je ovoga puta prihvatiti (a zatim i obrnuto, klijent A ce prihvatiti poruku klijenta B). Server S vise ne figurira izmedju klijenata, i oni mogu medjusobno direktno da razmenjuju poruke koristeci svoje IP adrese i portove koji su automatski otvoreni (A = 1.1.1.1:1000, B = 2.2.2.2:2000).

I za ovo postoje situacije u kojima se mogu javiti propusti, ali mislim da ce nam ovo resiti veci deo problema, a za ostalo cemo se vec snalaziti u hodu.

Nadam se da ce ovo jos nekome biti od koristi, a ako neko vec ima iskustva sa ovime, neka se slobodno javi da nas upozori na moguce probleme i da ideje za njihovo resavanje :)

Pozdrav svima, BugA

Odgovor na temu

mkova194
Matija Kovačić

Član broj: 47321
Poruke: 25
*.adsl.net.t-com.hr.

Profil

Re: Router bypass (port forwarding, tunneling... sta?)

^{08.10.2012. u 11:36 - pre 140 meseci}

Proučavao sam "UDP hole punching" i jedan dio u cijeloj ideji mi nije jasan. Proučavao sam ovdje npr. točka 3.4 dio:

Citat:

Now client A follows the hole punching procedure described above to establish a UDP communication session directly with B. First, A sends a request message to S asking for help connecting with B. In response, S sends 's public and private endpoints to A, and sends A's public and private endpoints to B. A and B each start trying to send UDP datagrams directly to each of these endpoints.

Razumijem kad A šalje upit prema S i dobije odgovor (sa adresom od B). Ali nije mi jasno kako S šalje (adresu od A) prema B. Zašto vatrozid ne odbije poruku? Kako je taj dio riješen?

Znači pitanje je kako server S daje uređaju B do znanja da ga uređaj A želi kontaktirati? Dali B svako malo provjerava (šalje upit)? Negdje sam pročitao da nakon slanja upita mogućnost za primanje odgovora traje samo 20sec. Nije li to malo prečesto slanje upita? Ne sviđa mi se baš takav način rada ako stvar radi tako! Dali postoji više načina da se to riješi?

Djeki

Odgovor na temu