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 05:55 | Komunita

Dries Buytaert, autor a vedoucí projektu Drupal a prezident Drupal Association, požádal soukromě před několika týdny Larryho Garfielda, jednoho z klíčových vývojářů Drupalu, aby projekt Drupal opustil. Larry Garfield minulý týden na svých stránkách napsal, že důvodem jsou jeho BDSM praktiky a rozpoutal tím bouřlivou diskusi. Na druhý den reagoval Dries Buytaert i Drupal Association. Pokračuje Larry Garfield [reddit].

Ladislav Hagara | Komentářů: 26
dnes 04:44 | Humor

Společnost SAS zveřejnila na svých stránkách studii s názvem Open Source vs Proprietary: What organisations need to know (pdf). Organizace by měly například vědět, že ideální je mix 40 % open source softwaru a 60 % proprietárního softwaru [Slashdot].

Ladislav Hagara | Komentářů: 6
včera 23:33 | Zajímavý software

Byl vydán ShellCheck ve verzi 0.4.6. Jedná se o nástroj pro statickou analýzu shellových skriptů. Shellové skripty lze analyzovat na webové stránce ShellChecku, v terminálu nebo přímo z textových editorů. Příklady kódů, na které analýza upozorňuje a doporučuje je přepsat. ShellCheck je naprogramován v programovacím jazyce Haskell. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GPLv3.

Ladislav Hagara | Komentářů: 0
včera 23:33 | Pozvánky

Czech JBoss User Group zve na setkání JBUG v Brně, které se koná ve středu 5. dubna 2017 v prostorách Fakulty informatiky Masarykovy univerzity v místnosti A318 od 18:00. Přednáší Pavol Loffay na téma Distributed Tracing and OpenTracing in Microservice Architecture.

… více »
mjedlick | Komentářů: 0
včera 11:33 | Zajímavý článek

Národní centrum kybernetické bezpečnosti (NCKB) vypracovalo (pdf) 26 podrobných bezpečnostních doporučení pro síťové správce. Tato doporučení jsou nastavena tak, aby je bylo možné aplikovat v každé instituci. Jsou rozdělena na tři základní části: bezpečnost infrastruktury, bezpečnost stanic a serverů a bezpečnost uživatelů.

Ladislav Hagara | Komentářů: 15
včera 05:55 | Komunita

Prezident Nadace pro svobodný software (FSF) Richard M. Stallman vyhlásil na slavnostním ceremoniálu v rámci konference LibrePlanet 2017 vítěze Free Software Awards za rok 2016. Ocenění za společenský přínos získal SecureDrop (Wikipedie). Za rozvoj svobodného softwaru byl oceněn Alexandre Oliva (Wikipedie).

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

Byla vydána verze 0.7.0 debugovacího nástroje cgdb. Mezi novinky patří například zvýrazňování syntaxe jazyka Rust. Podrobnosti v poznámkách o vydání.

Neel | Komentářů: 0
25.3. 22:00 | Komunita

Portál Stack Overflow po roce opět vyzpovídal své uživatele, jedná se především o vývojáře softwaru, a zveřejnil (podcast) detailní výsledky průzkumu. Průzkumu se letos zúčastnilo více než 64 tisíc vývojářů. Jejich nejmilovanější platformou je linuxový desktop. Ten je také druhou nejpoužívanější platformou vývojářů.

Ladislav Hagara | Komentářů: 7
24.3. 11:55 | Komunita

Vývojový tým OpenSSL ve spolupráci s iniciativou Core Infrastructure konsorcia Linux Foundation spustil proces přelicencování této kryptografické knihovny ze současné licence na licenci Apache Licence v 2.0 (ASLv2). Nová licence usnadní začleňování OpenSSL do dalších svobodných a open source projektů. Všichni dosavadní vývojáři OpenSSL (Authors) obdrží v následujících dnech email s prosbou o souhlas se změnou licence.

Ladislav Hagara | Komentářů: 33
24.3. 01:11 | Komunita

Před třemi týdny Mozilla.cz představila projekt Photon, jehož cílem je návrh a implementace nového vzhledu Firefoxu. Včera zveřejnila první náhled vzhledu Photon. Práce na projektu Photon jsou rozděleny do pěti týmů, které celkem čítají 19 lidí. Zaměřují se na zlepšení prvního spuštění Firefoxu a zaujetí nových uživatelů, celkovou úpravu vzhledu, zlepšení animací, zrychlení odezvy uživatelského rozhraní a také upravení nabídek. Vývoj lze sledovat v Bugzille.

Ladislav Hagara | Komentářů: 50
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (14%)
 (2%)
 (71%)
 (3%)
 (10%)
Celkem 950 hlasů
 Komentářů: 72, poslední 1.3. 11:16
    Rozcestník

    Dotaz: Náhodné výpadky komunikace mezi subnety v místní síti

    19.2.2012 04:05 vasek
    Náhodné výpadky komunikace mezi subnety v místní síti
    Přečteno: 472×
    Ahoj. Z "ladících" důvodů mám dva subnety připojené v jedné fyzické síti:
    |-router
    |
    |-server_a - 1. subnet
    |-server_b - 2. subnet
    |-server_c - 2. subnet
    
    Mezi oběma subnety routuju pomocí routeru, který má jedno rozhraní mající ip adresy z obou subnetů. Mám ale hrozné problémy s "duchy v síti". Po restartu firewallu na serveru_a se nemůže server_b dopingat na server_a (wiresharkem mám ale ověřeno, že na serveru_a je paket přijat a je odeslána i odpověď, vše projde přes accept na firewallu). Pokud nějakým jakýmkoliv způsobem na chvíli navážu komunikaci ze serveru_b na server_a (např. telnet server_a 80), pak již ping funguje. Opačně ping funguje vždy. Nejedná se ale jen o ping. Na serveru_c běží apcupsd, k němuž se připojuje server_a. Server_a ztrácí spojení s apcupsd na serveru_c cca 30x denně. Mezi routerem a servery a v jednotlivých subnetech je komunikace vždy ok. Nevíte někdo co tohle může způsobovat? Automatický nexthop? Neměl už někdo někdy podobný problém?

    Odpovědi

    19.2.2012 09:53 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti

    Někde se vám ztrácí ICMP redirect zprávy nebo máte někde IP stack nastavený tak, aby nepřijímal packety z různých ethernetových adres nebo máte příliš přísný reverse path filter.

    Když odchází ICMP response z A, odchází na jakou ethernetovou adresu? Adresu B nebou adresu routeru?

    19.2.2012 13:51 vasek
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti
    ICMP response jde přímo na mac adresu serveru_b. Položku rp_filter mám nastavenou na 2, ale zkoušel jsem i 0 a chovalo se to stejně. Ještě jsem zapomněl zmínit poměrně zásadní věc: server_a má několik ip adres (ve stejném subnetu) a problém je jen s první z nich.
    19.2.2012 14:46 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti
    Takže odchází na ethernetovou adresu B, ale B žádný takový rámec nepřijme? Pak se vám něco ztrácí po cestě. Nemáte moc chytrý switch? Nebo rozbitou síťovou kartu (nebo její ovladač), která se pokouší doplňovat adresy (off-load)?
    19.2.2012 16:36 lixter
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti
    Síťové karty jsou prakticky všude různé. Jediné společné je ten switch. Je to starší managovatelný 3com. Všechny uvedené stroje jsou v jedné VLAN. Pokud by chtěl server_b komunikovat se serverem_a, pak by to mělo správně fungovat takto:
    server_a -(gateway)-> switch -(gateway)-> router -> switch -> server_b
    
    Jenže problém bude určitě v tom, že ty stroje na sebe vidí přímo a nějaký chytrý algoritmus se asi snaží zkracovat cesty paketům. Vyloučil bych ale z toho STP (zapojeni switchů to neumožňuje a na serverech je vyplé).
    19.2.2012 16:37 vasek
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti
    (vasek=lixter)
    19.2.2012 17:35 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti
    Jenže problém bude určitě v tom, že ty stroje na sebe vidí přímo a nějaký chytrý algoritmus se asi snaží zkracovat cesty paketům.

    Někdo ten problém vidí jako vlastnost. Ostatně je to výchozí nastavení Linuxu.

    Předpokládejme, že všechny stroje Linux ve výchozím nastavení, že switch jen skutečně prostá L2 krabička a všchny stroje mají prázdnou směrovací a ARP keš. Pak packety by měly proudit takto:

    A                      GW                      B
    |→ ARP request for GW  →|
    |← ARP response for GW ←|
    |→ Echo request 1      →|
    |← Redirect to B       ←|
                            |→ ARP request for B  →|
                            |← ARP response for B ←|
                            |→ Echo request 1     →|
                            |← Echo response 1    ←|
                            |→ Redirect to A      →|
    |← Echo response 1     ←|
    

    Teď A i B vědí, že se na druhý stroj mají obracet přímo a pravidlo si zanesly do směrovací keše (ip route show cache).

    Pokud A pošle další echo request pro B, tak už se vůbec nebude s GW bavit:

    A                      B
    |→ ARP request for B  →|
    |← ARP response for B →|
    |→ Echo request 2     →|
    |← Echo response 2    ←|
    

    B už ARP dotaz na A neposílá, protože jeho ethernetovu adresu zná z ARP dotazu od A na B. V ARP keši na obou strojích by nyní měly být záznamy jak pro GW, tak i pro opačnou stanici (ip ne show).

    Vyloučil bych ale z toho STP (zapojeni switchů to neumožňuje a na serverech je vyplé).

    STP jsem vůbec neuvažoval. Stejně rámce chodí stejnými cestami. Spíše jsem myslel, že první adresu (s kterou máte problém) dostane stanice třeba přes DHCP, a pak chytré switche tohle sledují, a pak mohou podle toho nasadit „bezpečností“ filtry.

    Pokud nechcete, aby stanice komunikovali napřímo, je možné v proc nebo přes sysctl vypnout na stancích accept_redirects a na routeru send_redirects.

    19.2.2012 19:03 vasek
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti
    Mě se icmp redirecty také líbí, když fungují tak jak mají. Možná to s tím ale vůbec nesouvisí. Vrtá mi ale hlavou, proč po restartu firewall pravidel (service shorewall restart) nefunguje ping (icmp echo), začne fungovat vždy po nějakém jiném navázání spojení (http, ...). Adresy jsou statické, žádné dhcp. Tento switch "žádné" bezpečnostní politiky neumí. Mimochodem, jak rychle se projeví změna hodnoty rp_filter?
    19.2.2012 19:46 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti

    rp_filter by měl zafungovat hned. Každopádně se tcpdumpem podívejte, jestli vám packet odeslaný z druhého stroje dorazí. Tcpdump ho uvidí ještě před rp­_filterem nebo netfilterem.

    Nemám tušení, co vám nastavuje shorewall. Zřejmě nějaké packety zablokuje, čímž se stroj nedozví potřebnou ethernetovou adresu nebo žádost o přesměrování. Teprve až s odchozím spojením se inkriminovaný nebo úplně jiný packet jakožto související se spojením dostane dovnitř, čímž se stroj potřebný údaj dozví. Jak jsem psal, porovnejte si směrovací a ARP keš. Taky když jste si vybral shorewall, mohl byste si za trest přečíst firewellová pravidla, která stvořil. A ještě porovnejte výstup ze sysctl --all (je možné, že do toho shorewall také šahá).

    19.2.2012 21:32 vasek
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti
    Shorewall je v pohodě. Pravidla jsou OK, po restartování shorewallu se při pingování inkrementovalo počítadlo pro icmp ACCEPT, nic jiného, přes iptables vše prošlo. Zjistil jsem ale, že shorewall restartuje i route cache tabulku. Tu tabulku jsem sledoval a dokud tam byla jen routa přes router, tak ping neprošel, ale potom se tam objevilo <redirected> na server_b a potom ping začal fungovat. Tcpdump mi potvrdil to, co wireshark - paket odejde, cíl odpoví a už nedorazí zpátky. Příkaz "ip ne show" ukazuje před i po restartovní shorewallu to samé, takže v arp tabulce problém asi nebude.
    19.2.2012 22:29 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti

    Nepochopil jsem, co jste pozoroval na kterém stroji.

    Tu tabulku jsem sledoval a dokud tam byla jen routa přes router, tak ping neprošel, ale potom se tam objevilo <redirected> na server_b

    A pravidlo pro přesměrování se tam objeví, až když stroj přijme ICMP redirect. Takže hledejte, kde se vám ztrácí redirect.

    Navíc i tak by to fungovat mělo, jen by požadavek šel přes router. Pořád má pocit, že vám něco někde blokuje redirect packety. Už jsem viděl „switche“ od Cisca, které pouštěli ICMP a ARP packety jen jednou za několik sekund, protože to považovali za bezpečnostní opatření.

    paket odejde, cíl odpoví a už nedorazí zpátky

    Pokud odpověď cíle B směřuje na ethernetovou adresu stroje A, ale tcpdump na stroji A tuto odpověď nevidí, tak vám straší v kabelech.

    19.2.2012 23:40 vasek
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti
    Na serveru_a jsem pozoroval tu tabulku. Dokonce i pokud iptables pravidla vypnu (shorewall restart a pak stop na serveru_a) a nastavím všude implicitní ACCEPT, tak se to chová stejně, což mě utvrdilo v tom, že netfilter v tom nehraje roli, ale vadí tam to, že shorewall maže route cache, která se z nějakého důvodu nedokáže normálně sestavit.
    pavlix avatar 19.2.2012 23:47 pavlix | skóre: 53 | blog: pavlix
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti
    Na správné fungování rp_filteru bych nespoléhal. Bez rp a iptables to musí na 100% jet, jinak je problém jinde. Pak se dají iptables vyladit podle představ a testovt buď logováním nebo sledováním počítadel iptables. Plus si občas pustit tcpdump.

    Žádná černá magie, jde to všechno postupně odladit :).
    20.2.2012 01:54 vasek
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti
    iptables vypnuté, rp_filter na 0, stejné problémy.
    pavlix avatar 20.2.2012 10:35 pavlix | skóre: 53 | blog: pavlix
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti
    Někde jsem slyšel, že se rp_filter chová podivně. Nechce se mi to hledat, třeba mě tu někdo opraví, ale měl by být vypnutý od začátku, protože ta hodnota nefunguje tak úplně runtume (a při mých testech před časem teda nefungovala).

    Ale pokud ti to nepůjde ani když si 100% pohlídáš vyputé iptables rp_filter, tak máš problém někde jinde. Ale je to dost zvláštní, takže spíš bych to viděl na problém v té konfiguraci.

    Ještě bych na tvém místě zkontroloval „iptables -L“ a „iptables -t nat -L“, jestli je to opravdu, jak píšeš.
    20.2.2012 15:36 vasek
    Rozbalit Rozbalit vše Re: Náhodné výpadky komunikace mezi subnety v místní síti
    Jak filter, tak nat iptables tabulky jsou prázdné. Zkusím vypnout ten rp_filter. Co se dá použít místo něho, aby nedocházelo k falšování zdrojových adres? Mimochodem má rp_filter smysl na koncovém serveru, který není router (podle manuálů snad jen s číslem 2, ale nevím)?

    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.