Alex Ellis upozornil 15. března, že firma Docker se chystala zrušit bezplatný hosting open-source projektů na Docker Hubu. Po vlně odporu se představitelé firmy omluvili a posléze byl původní záměr odvolán.
Ve věku 94 let zemřel Gordon Moore, mj. spoluzakladatel společnosti Intel a autor Moorova zákona.
Mercurial (Wikipedie), software pro SCM (Source Code Management), byl vydán ve verzi 6.4. Přehled novinek v poznámkách k vydání. Ve dnech 5. až 7. dubna proběhne konference Mercurial Paris.
Byly rozdány Ceny Velkého bratra (Big Brother Awards) za rok 2022 pro největší slídily pořádané nevládní organizací Iuridicum Remedium. Dlouhodobý slídil: Microsoft. Firemní slídil: Seznam. Úřední slídil: Nejvyšší správní soud. Výrok Velkého bratra: Marian Jurečka. Pozitivní cena: NoLog.
Byla představena online vzdělávací platforma Ada Computer Science pro učitele, studenty a kohokoli, kdo se zajímá o informatiku. Stojí za ní Raspberry Pi Foundation a Univerzita v Cambridgi.
GitHub má nový RSA SSH klíč. Předchozí soukromý klíč byl krátce vystaven na GitHubu.
Společnost Framework Computer představila (YouTube) nové modulární notebooky: Laptop 13 s Intel Core nebo AMD Ryzen a Laptop 16 (YouTube).
Bylo vydáno Ubuntu 20.04.6 LTS, tj. šesté opravné vydání Ubuntu 20.04 LTS s kódovým názvem Focal Fossa. Přehled novinek v poznámkách k vydání a v přehledu změn.
Připojit neznámý USB flash disk do počítače může být nebezpečné. Dokonce může jít i o život. Někdo rozeslal ekvádorským novinářům USB flash disky, které po připojení do počítače explodují [BBC, Twitter].
Byla vydána nová verze 7.4 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu.
|-router | |-server_a - 1. subnet |-server_b - 2. subnet |-server_c - 2. subnetMezi 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?
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?
server_a -(gateway)-> switch -(gateway)-> router -> switch -> server_bJenž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é).
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.
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á).
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.
Tiskni
Sdílej: