abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 15:00 | Pozvánky

Sdružení CESNET ve spolupráci se společností Trend Micro spustilo registraci do hackerské soutěže The Catch 2018. Soutěž proběhne stejně jako vloni v rámci Měsíce kybernetické bezpečnosti.

Ladislav Hagara | Komentářů: 0
dnes 10:33 | Nová verze

Po pěti měsících vývoje od vydání verze 1.15 byla vydána (YouTube) nová major verze 2.0 (2.0.1309.29) webového prohlížeče Vivaldi (Wikipedie). Přináší především synchronizaci uživatelských dat. Novinkou jsou také plovoucí panely. Dále je vylepšena přizpůsobitelnost nebo i práce s listy. Nejnovější Vivaldi je postaveno na Chromiu 69.0.3497.102.

Ladislav Hagara | Komentářů: 0
včera 23:33 | Nová verze

Opera 56, verze 56.0.3051.31, byla prohlášena za stabilní. Z novinek vývojáři upozorňují například na vylepšenou funkci vyskakovacích videí - v plovoucím rámci lze nově nastavovat hlasitost. Podrobný přehled změn v Changelogu. Přehled novinek pro vývojáře na blogu Dev.Opera. Opera 56 je postavena na Chromiu 69.

Ladislav Hagara | Komentářů: 9
včera 21:55 | Nová verze

Společnost Oracle oficiálně oznámila vydání Java SE 11 (JDK 11). Jedná se o verzi s prodlouženou podporou (LTS). Nových vlastností (JEP - JDK Enhancement Proposal) je 17. Nové verze Java SE vychází každých 6 měsíců.

Ladislav Hagara | Komentářů: 0
včera 18:44 | Nová verze

Byla vydána (en) betaverze Fedory 29. Jedná se o poslední zastávku před finálním vydáním a vzhledem k tomu, že byla zrušena alfa, tak také o první. K dispozici je v oficiálních edicích Workstation, Server a Atomic a také v podobě spinů, labů a verze pro ARM. Vydání Fedory 29 je plánováno na 30. října.

Ladislav Hagara | Komentářů: 0
včera 11:44 | Komunita

Aktuální verzi knihy Everything curl věnované řádkovému nástroji a knihovně pro přenos dat po různých protokolech curl lze koupit v papírové formě. Kniha je volně k dispozici na stránkách curlu nebo ke stažení ve formátech PDF, MOBI a EPUB. Ve spolupráci s BountyGraph byl spuštěn bug bounty program aneb za nalezení kritické bezpečnostní chyby v curlu lze vydělat aktuálně až 33 268 dolarů. Částkou 32 768 dolarů přispěl Dropbox. Curl již umí TLS

… více »
Ladislav Hagara | Komentářů: 0
včera 11:33 | Zajímavý projekt

Cloudflare spustil experimentální provoz ESNI - šifrovaného SNI (Server Name Indication), které umožňuje chránit soukromí uživatelů přistupujících k webům přes HTTPS. ESNI je podporováno zatím v testovací verzi Firefoxu. Při současném použití šifrovaného DNS (DNS-over-TLS či DNS-over-HTTPS) tak ISP či státy již nebudou mít žádnou přesnou možnost, jak kontrolovat či blokovat stránky, ke kterým uživatelé přistupují. Více viz také IETF draft.

xm | Komentářů: 0
24.9. 21:33 | Nová verze

Byla vydána nová major verze 1.8.0 open source systému pro filtrování nevyžádané pošty Rspamd (GitHub, ChangeLog). Z novinek lze zmínit nový framework selectors, optimalizaci modulu ClickHouse nebo vylepšení webového rozhraní.

Ladislav Hagara | Komentářů: 2
24.9. 18:44 | Bezpečnostní upozornění

Sabri Haddouche vytvořil stránku Browser Reaper, na které demonstruje zranitelnosti současných verzí webových prohlížečů Chrome, Safari i Firefox. Zveřejněné skripty dokážou zahltit nejen webové prohlížeče, ale v závislosti na nastavení, také celé operační systémy.

Ladislav Hagara | Komentářů: 13
23.9. 19:22 | Nová verze

Byla vydána verze 11.3 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností i s náhledy v příspěvku na blogu.

Ladislav Hagara | Komentářů: 0
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (14%)
 (14%)
 (20%)
 (24%)
 (24%)
 (4%)
 (0%)
Celkem 419 hlasů
 Komentářů: 35, poslední včera 09:16
Rozcestník

Dotaz: pomaly tok dat pres server s NATem

4.1.2005 18:25 qwertz
pomaly tok dat pres server s NATem
Přečteno: 36×
Dobry den,

mam tento problem. Mam lokalni sit a v nem pocitace A,B,C. Na pocitaci A (windows) bezi moje klientska aplikace, na pocitaci B (windows) bezi server pro tuto aplikaci. Pocitac C je linuxova brana (debian, kernel 2.6.8). Pocitac C ma dve rozhrani jedno do internetu a druhe do lokalni site kde je A a B a ma nastaveno aby prekladal veskere odchozi pripojeni z lokalni site a taky ma nastaveno aby prichozi zadosti o pripojeni z vnejsku na urcity port preposilal na pocitac B na port na kterem posloucha ten server. No a problem je v tom ze kdyz te klientske aplikaci nastavim aby komunikovala primo s pocitacem B tzn. odesila pozadavky na adresu B tak vsechno kumunikuje pekne rychle ale kdyz dam aby komunikoval pres C tzn. klient posila data na adresu C a ten to preposle B jak je nastaneno v iptables, tak to jede strasne pomalu. A pomalu tim nemyslim ze by to soustavne odesilalo pomalu data ale spis je to takove trhane, ze dlouho trva nez se akceptuje nejake spojeni a az jo tak vsechny ty data daneho spojeni profrci zas rychle. Aspon tak se mi to jevi. Myslel sem jestli to nahodou neni nejakou ochranou proti floodovani v jadre ale tu mam vyplou ( cat /etc/proc/sys/ipv4/tcp_syncookies = 0) . Dik za kazde postrehy

Odpovědi

4.1.2005 18:58 Petr Šobáň | skóre: 79 | blog: soban | Olomouc
Rozbalit Rozbalit vše Re: pomaly tok dat pres server s NATem
To je jednoduché proč ty data cpete někomu komu nepatří ???

Pokud jsou A a B na jedné síti proč to chcete posílat na C ?

A jenom tak pro zajímavost by mě zajímalo jak to posíláte přes to C ?? Na tu veřejnou adresu co je natovaná grrrr to se nedivím když potom zblbnete tu logiku natu, jak on má vědět že paket co mu přišel z lokálního eth zařízení má zase poslat na lokální zařízení když tam máte veřejnou IP. (když má natovat pouze veřejné rozhraní)

Prostě aby se našla chybka musíte poslat jak máte ty IP tables nastavené, nat se provádí většinou pouze pro eth které směřuje ven a když tam přijde paket s veřejnou IP která má správně přicházet z internetu tak se nedivím že to nechodí.
4.1.2005 18:58 Michal Kubeček
Rozbalit Rozbalit vše Re: pomaly tok dat pres server s NATem
Že by tradičně nefungující reverzní lookup adresy klienta, resp. v tomto případě adresy, na kterou se to NATuje?
5.1.2005 08:38 Zdeněk Štěpánek | skóre: 57 | blog: uz_mam_taky_blog | varnsdorf
Rozbalit Rozbalit vše Re: pomaly tok dat pres server s NATem
Zdravim

Osobne si myslim ze ten NAT mas nastaven nejak spatne, protoze tohle vubec fungovat nemuze. Teoreticky to jde obejit nejakou zbesilou kombinaci SNAT+DNAT, ale proc takovou blbost delat. Pokud to chces kvuli BFU aby byly klienti ve vnitrni i vnejsi siti nastaveny stejne (na verejnou IP) tak pouzij DNS. Zvnejsklu je to jasny a vevnitr si udelej svuj DNS server kterej bude server.tvojedomena.cz prekladat na 192.168.1.2.

Zdenek
www.pirati.cz - s piráty do parlamentu i jinam www.gavanet.org - czfree varnsdorf
5.1.2005 18:05 Martin Čížek | skóre: 20 | Praha
Rozbalit Rozbalit vše Re: pomaly tok dat pres server s NATem
Jen pro doplnění: U DNS serveru Bind hledej klíčové slovo "view".
Kdyby dva z nás byli dvěma z nich, všichni z nás by mohli být všemi z nich.
5.1.2005 22:10 qwertz
Rozbalit Rozbalit vše Re: pomaly tok dat pres server s NATem
Diky vam vsem, mali ste pravdu, kdyz jsem si tu situaci nakreslil na papir tak mi to hned doslo. Postavilo me to ale pred novou otazku..jakto ze to vubec funguje ? Jakto ze nejaka komunikace prochazi ? Popisu tu situaci jak ji vidim

A: pocitac s klientem 192.168.1.10

B: pocitac s serverem 192.168.1.20

C: brana s NATem vnitrni: 192.168.1.1 vnejsi: 10.20.30.40

C:/# iptables -t nat -L

Chain PREROUTING (policy ACCEPT)

target prot opt source destination

DNAT tcp -- anywhere 10.20.30.40 tcp dpt:1234 to:182.168.1.20:1234

Chain POSTROUTING (policy ACCEPT)

target prot opt source destination

SNAT tcp -- 192.168.1.0/24 anywhere to:10.20.30.40

SNAT udp -- 192.168.1.0/24 anywhere to:10.20.30.40

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

mno a ted A vysle dotaz.. packet vypada takto (source::destination) 192.168.1.10::10.20.30.40. Pak to prijde na C, tam se to prelozi a z C odejde 192.168.1.10::192.168.1.20. Pak to prijde na B a ten se z packetu dovi ze odpoved ma odeslat na 192.168.1.10. Tak se zepta kdo ma tuto IP adresu a dozvi se linkovou adresu A a odesle odpoved 192.168.1.20::192.168.1.10 a linkovou adresou A. Jenze na C uz tato odpoved nedojde (a to i kdyz tu je HUB) protoze na linkove vrstve ma jinou adresu (ma adresu A), a neprijme tuto odpoved ani A protoze ten ocekava ze odpoved prijde se zdrojovou adresou C a ne B. Krom toho to asi musi zpusobit to ze na C se zacne plnit NATovaci tabulka nevyrizenyma zaznamama. :)

Urcite mi neco unika protoze to precejenom komunikuje. Diky.
6.1.2005 08:55 Zdeněk Štěpánek | skóre: 57 | blog: uz_mam_taky_blog | varnsdorf
Rozbalit Rozbalit vše Re: pomaly tok dat pres server s NATem
Zdravim

To mas nejaky zmatecny, posli spis rc.firewall (na slacku) nebo neco takoveho.

Maskarada se dela takhle:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

To znamena ze vsechno co odchazi skrze eth0 (externi sitovka) se zamaskaraduje IPckem te eth0, na lokalni sitovky to vubec nesaha.

Zdenek
www.pirati.cz - s piráty do parlamentu i jinam www.gavanet.org - czfree varnsdorf

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.