Skoči na vsebino

Težave s požarnimi zidovi in/ali ostalo zaščito


premza

Priporočene objave

Malo za zabavo sem napisal enostavno arkadno igro, ki dela prek NET-a (TCP/IP protokol). Zadeva ima strežnik, nanj pa se povezujejo odjemalci (igralci). Težava je v tem, da pol odjemalcev (navadno na kakih večjih firmah) nikakor ne more komunicirati s strežnikom (PING-ajo ga lahko, ampak nič ne gre skozi :? ). Komunikacija je seveda obojestranska.

Edino kar sem do sedaj ugotovil je, da pomaga, če zadevo s PORTa XY prestavim na PORT 80. Sita so tako bolj prepustna, ampak še vedno marsikdo ostane zunaj. <_<

Tako strežnik, kot odjemalec sem napisal sam, tako da lahko spreminjam vse, tudi sam protokol, če bo potrebno (ga zavijem v XML, HTML,... ali kako podobno obliko). Zdaj je v čisto navadni tekstovni obliki.

Iskal sem že literaturo, da bi preveril kaj natančno preverjajo požarni zidovi in podobna navlaka, pa mi ne uspe najti ničesar. Če kdo ve kaj več o tem, bi prišlo zelo prav. :yes:

Povezava do komentarja
Delite na drugih straneh

Bom vprašal drugače... :D

A kdo v podrobnosti pozna delovanje požarnih zidov in/ali proxy strežnikov? :hmm:

Povezava do komentarja
Delite na drugih straneh

Mislim, da bi bil kar pravi naslov :)

Sam da ne bi kaj spraseval o tistih software jajcih ki jih na winse instaliras... Govorim o pravih firewallih in dedicated proxy-jih.

Povezava do komentarja
Delite na drugih straneh

Pol lahko pa kar začneva... :D

Težava... :hmm:

Igra je arkadna in zato je čas (hitrost, zakasnitev ali kakorkoli temu rečeš) prenosa zelo pomembna! Vse kar je več od 0.2s pomeni upočasitev in neusklajenost ter potrebo po sinhronizaciji, zato je stalna in neposredna povezava nujna.

Dokler ni kakih resnih požarnih zidov in proxy-jev zadeva dela kot namazana, ko pa so, se začne veselje...

Povzetek stanja... :afro1:

Povezavo vzpostavim direktno. TCP/IP strežnik na eni in TCP/IP odjemalec na drugi strani. Povezava je stalna (dokler je igralec-odjemalec prijavljen). Protokol je preprost tekstovni. Pošiljanje enostavno strukturiranega texta sem in tja. V večini gre za zahteve, ki jih odjemalec pošilja strežniku, ta pa vrača odgovor, nekaj pa je tudi takih brez (strežnik pošilja odjemalcem podatke brez da bi ti to zahtevali, enostavno poslušajo in čakajo).

Kaj sem že sam ugotovil... :doze:

Če dam na nestandareden port, zadeva ne gre skoz, ker jo požarni zidovi ne spustijo. Če dam na standarden port (npr. 80) sicer pomaga, a ne povsod.

Tukaj pa me znanje zjebe... :wacko:

Ali je težava v tem, da se zahteva preusmeri na proxy (tam nima taka "on-line" povezava kaj iskat) ali pa se preverja vsebina, ki gre skozi port 80, ki seveda ni HTTP oblike. Sam protokol je moj in ga lahko poljubno spremenim (npr. zavijem v HTTP obliko)!

In če povzamem na kratko... B)

So kaki standardno odprti porti, ki se ne preusmerjajo na proxy?

Če obstajajo, kako se kontrolirajo?

Se kontrolira vsebina in kako?

Obstaja kakšna druga rešitev?

Če sem napisal kako neumnost, je to zato, ker sem za požarne zidove in proxy-je "izvedel" šele včeraj! :blink:

Povezava do komentarja
Delite na drugih straneh

Ne vem sicer, zakaj imaš klienta in server ločen s firewallom ampak ok.

Situacija je taka:

Če imaš server za firewallom in je klient 'zunaj' in se klient hoče priklopiti na server, ki posluša določen port, moraš ta port, na firewallu v NAT nastavitvah, forwardirati na LAN IP serverja.

Če pa imaš server zunaj firewall in klienta za firewallom, pa se spet klient hoče povezati na server na določenem portu, ni potrebno odpirati na firewallu nič, ker firewall praviloma spušča ven vse, klient v tem primeru naredi z serverju socket in je tudi konekcija nazaj na klienta odprta.

Povezava do komentarja
Delite na drugih straneh

Ne vem sicer, zakaj imaš klienta in server ločen s firewallom ampak ok.

Jaz lahko vplivam samo na to, kar je na server strani. Tukaj ni panike. Priblem je, ker so nekateri klienti za firewalli, do katerih pa seveda nimam dostopa.

Če pa imaš server zunaj firewall in klienta za firewallom, pa se spet klient hoče povezati na server na določenem portu, ni potrebno odpirati na firewallu nič, ker firewall praviloma spušča ven vse, klient v tem primeru naredi z serverju socket in je tudi konekcija nazaj na klienta odprta.

Točno taka je situacija. Klient je za firewalom, vzpostavila naj bi se socket povezava, pa se ne. Client nikakor ne more vzpostaviti socket povezave s strežnikom. Ponekod pomaga, če zadevo speljem prek porta 80, ponekod pa tudi to ne. :hmm:

Povezava do komentarja
Delite na drugih straneh

Torej je samo klient za firewallom, server pa ne?

Hmm... aha, berem, da to preizkušaš tako, da so nekateri klienti v firmah za firewallom.

No v tem primeru je situacija taka: dražji firewalli, ki jih uporabljajo podjetja imajo tudi navzven zaprte določene porte.

Za to, kateri so odprti, pa moraš vprašati njihove admine.

Povezava do komentarja
Delite na drugih straneh

Trik je samo v tem, kje gre ven... Vsi firewalli (po mojem vedenju) v firmah so nastavljeni, da spusti not established seje - normalno delovanje TCPja je, da naredi client request na npr port 80, masina pa mu vrne na port s katerega je spraseval - kar je randomly izbran visoki port 1024+n. Firewall mora spustit odgovore skozi, ker drugace tudi navaden http ne bi deloval.

Seveda je problem, da mora firewall ven clienta spustiti ne-filtriranega - se pravi brez proxijev.

Ena od resitev je, da bi imel v igri nastavljiv port in bi lahko user sam izbiral na ker port naj gre (naprimer da imajo odprt ftp, bi se lahko povezal na port 21 oz 20 - control in data porta) - se pravi standardne 20, 21, 22 (ssh) in 23 (telnet) ter znani 80 za http.

Nazaj pa ne bi smelo biti problema.

Seveda to pomeni, da bi moral server poslusat na vec portih ne samo na enem.

Povezava do komentarja
Delite na drugih straneh

Trik je samo v tem, kje gre ven... Vsi firewalli (po mojem vedenju) v firmah so nastavljeni, da spusti not established seje - normalno delovanje TCPja je, da naredi client request na npr port 80, masina pa mu vrne na port s katerega je spraseval - kar je randomly izbran visoki port 1024+n. 

Lahko prosim tole malj bolj razumljivo poveš? Predvsem tisto poševno in podčrtano mi ni jasno.

Port s katerega je spraševal? A ni to 80? :wacko:

Mogoče me bega moja socket povezava, kjer je port na obeh straneh vedno isti (serverju določim samo PORT, clientu pa HOST IP in PORT)! :huh:

Firewall mora spustit odgovore skozi, ker drugace tudi navaden http ne bi deloval.

A mogoče preverja vsebino? In je ne spusti, če ni HTTP? :hmm:

Da vem, če se mi zadevo splača kamuflirat?

Ena od resitev je, da bi imel v igri nastavljiv port in bi lahko user sam izbiral na ker port naj gre (naprimer da imajo odprt ftp, bi se lahko povezal na port 21 oz 20 - control in data porta) - se pravi standardne 20, 21, 22  (ssh) in 23 (telnet) ter znani 80 za http.

Nazaj pa ne bi smelo biti problema.

Seveda to pomeni, da bi moral server poslusat na vec portih ne samo na enem.

Jaz lahko poslušam tudi na več portih (to mam že zdaj, ampak imam za vsakega svoj server). Pač server mal popravim, saj to ne more bit kak problem (če sem ga spisu, ga bom tud popravu). :D Cliente pa lahko popravim tako, da na več portih probajo, pa če jim na kakem rata... :D

Ampak..., a ima to smisel? Če ne gre skozi 80, a bo šlo skozi 20, 21,22, ...? Pa tud proxy bo verjetno še vedno problem? :wacko:

Sem se tega lotu, da se naučim v Delphi-ju programirat, pa se bom zgleda še marsikaj druzga nauču... :slap:

Hvala vsem, ki imate potrpljenje z mano. :worship:

Dobite igrico, ko bo tole poštimano, pa za pir ob priliki! :yea2:

Povezava do komentarja
Delite na drugih straneh

Ustvarite račun ali se prijavite za komentiranje

Za objavljanje se morate najprej registrirati

Ustvarite račun

Registrirajte se! To je zelo enostavno!

Registriraj nov račun

Prijava

Že imate račun? Prijavite se tukaj.

Vpišite se
  • Zadnji brskalci   0 članov

    • Noben registriran uporabnik, si ne ogleduje to stran.


×
×
  • Ustvari novo...

Pomembne informacije

Z uporabo te strani se strinjate z uporabo piškotkov in se strinjate s pravili o varovanju zasebnosti!