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:22 | Nová verze

    Byla vydána nová verze 18 integrovaného vývojového prostředí (IDE) Qt Creator. S podporou Development Containers. Podrobný přehled novinek v changelogu.

    Ladislav Hagara | Komentářů: 0
    dnes 12:55 | Nová verze

    Cursor (Wikipedie) od společnosti Anysphere byl vydán ve verzi 2.0. Jedná se o multiplatformní proprietární editor kódů s podporou AI (vibe coding).

    Ladislav Hagara | Komentářů: 1
    dnes 02:55 | Nová verze

    Google Chrome 142 byl prohlášen za stabilní. Nejnovější stabilní verze 142.0.7444.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 20 bezpečnostních chyb. Za nejvážnější z nich bylo vyplaceno 50 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.

    Ladislav Hagara | Komentářů: 0
    dnes 01:22 | IT novinky Ladislav Hagara | Komentářů: 0
    včera 17:00 | Upozornění

    Národní identitní autorita, tedy NIA ID, MeG a eOP jsou nedostupné. Na nápravě se pracuje [𝕏].

    Ladislav Hagara | Komentářů: 9
    včera 16:44 | IT novinky

    Americký výrobce čipů Nvidia se stal první firmou na světě, jejíž tržní hodnota dosáhla pěti bilionů USD (104,5 bilionu Kč). Nvidia stojí v čele světového trhu s čipy pro umělou inteligenci (AI) a výrazně těží z prudkého růstu zájmu o tuto technologii. Nvidia již byla první firmou, která překonala hranici čtyř bilionů USD, a to letos v červenci.

    Ladislav Hagara | Komentářů: 6
    včera 14:11 | Komunita

    Po Canonicalu a SUSE oznámil také Red Hat, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie).

    Ladislav Hagara | Komentářů: 2
    včera 13:55 | Nová verze

    TrueNAS (Wikipedie), tj. open source storage platforma postavená na Linuxu, byl vydán ve verzi 25.10 Goldeye. Přináší NVMe over Fabric (NVMe-oF) nebo OpenZFS 2.3.4.

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

    Byla vydána OpenIndiana 2025.10. Unixový operační systém OpenIndiana (Wikipedie) vychází z OpenSolarisu (Wikipedie).

    Ladislav Hagara | Komentářů: 0
    včera 13:22 | Zajímavý článek

    České základní a střední školy čelí alarmujícímu stavu kybernetické bezpečnosti. Až 89 % identifikovaných zranitelností v IT infrastruktuře vzdělávacích institucí dosahuje kritické úrovně, což znamená, že útočníci mohou vzdáleně převzít kontrolu nad klíčovými systémy. Školy navíc často provozují zastaralé technologie, i roky nechávají zařízení bez potřebných aktualizací softwaru a používají k nim pouze výchozí, všeobecně známá

    … více »
    Ladislav Hagara | Komentářů: 16
    Jaké řešení používáte k vývoji / práci?
     (36%)
     (48%)
     (19%)
     (19%)
     (22%)
     (17%)
     (21%)
     (16%)
     (17%)
    Celkem 285 hlasů
     Komentářů: 14, poslední 14.10. 09:04
    Rozcestník

    Dotaz: Velke ramce posielane serverom

    15.12.2011 22:54 timeos | skóre: 32
    Velke ramce posielane serverom
    Přečteno: 225×
    Ahojte vospolok,

    Mam server (linux debian lenny 5.0.9 amd64), ktory bezi na XenServeri. A mam klientov, ktori su schovani za IPSec tunelom nasledovnym sposobom:

    <Server> ---ethernet--- <IPSec_VPN_EndPoint> --( ISP )-- <IPSec_VPN_EndPoint> ---ethernet--- <Klient>

    A mam nasledovny problem: Na uvedenom serveri bezi webova aplikacia, na ktoru pristupuju klienti spoza IPSec tunela... lenze zobrazovanie web obsahu je neskutocne pomale a po investigacii (tcpdump/wireshark) som zistil, ze dochadza k velkemu mnozstvu retransmisii a strate packetov z dovodu, ze server proste posiela ramce lubovolnej velkosti kludne presahujucej 1500B (napr. 17000B ramec a pod.. v zavislosti od payloadu)!

    Podla mojho zistovania to klientom na rovnakej subnete ako je server, vobec nevadi. Vadi to az IPSec tunelu, ktory ma MAX MTU este o nieco nizsie ako je 1500 - konkretne 1260B. Teda pokus prepasovat kazdy ramec velkosti vacsej ako je 1260B skonci jeho dropnutim (ak je DF bit je na 1... a to veru ze nastaveny je). Za normalnych okolnosti tento problem pri pouziti IPSec tunela a inych serveroch riesim modifikovanim ziaducej MSS od klienta (na clamp-mss-to-pmtu cez iptables) a obe strany spojenia sa bez problemov prisposobia.

    Avsak pri tomto serveri to vsetko zlyhalo, konkretne:
    • modifikovanie klientom ziadanej MSS na hodnotu "MTU_IPSec_Tunela - 40"
    • modifikovanie/nastavenie MTU na NIC rozhrani servera (default je tam 1500, ale viditelne je to ignorovane...)
    • nastavenie statickej ip routy na serveri ku klientom za ipsec tunelom s parametrom "advmss" pripadne "mtu"
    ..proste vsetko je ignorovane....

    Zaujimave vsak je, ze pri zostavovani TCP spojenia si v SYN packetoch oba konce vymenia spravne hodnoty MSS.. presne podla toho, ako im to forcnem. Avsak server to proste ignoruje...

    Este dodam, ze problem sa netyka jednej aplikacie (web server), ale odskusal som to napr aj pri prenose suborov cez ssh (scp)... problem je uplne rovnaky.

    Za akekolvek rady dakujem.

    Odpovědi

    17.12.2011 21:08 timeos | skóre: 32
    Rozbalit Rozbalit vše Re: Velke ramce posielane serverom
    nemate niekto predstavu, co este skusit? alebo nejak resetnut DF bit... alebo neviem. Inak je to virtualka nad XenServerom... nemoze byt problem s ovladacom, ktory by sa dal vymenit?

    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.