Od soboty do úterý probíhá v Hamburku konference 39C3 (Chaos Communication Congress) věnovaná také počítačové bezpečnosti nebo hardwaru. Program (jiná verze) slibuje řadu zajímavých přednášek. Streamy a záznamy budou k dispozici na media.ccc.de.
Byl představen nový Xserver Phoenix, kompletně od nuly vyvíjený v programovacím jazyce Zig. Projekt Phoenix si klade za cíl být moderní alternativou k X.Org serveru.
XLibre Xserver byl 21. prosince vydán ve verzi 25.1.0, 'winter solstice release'. Od založení tohoto forku X.Org serveru se jedná o vůbec první novou minor verzi (inkrementovalo se to druhé číslo v číselném kódu verze).
Wayback byl vydán ve verzi 0.3. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána verze 4.0.0 programovacího jazyka Ruby (Wikipedie). S Ruby Box a ZJIT. Ruby lze vyzkoušet na webové stránce TryRuby. U příležitosti 30. narozenin, první veřejná verze Ruby 0.95 byla oznámena 21. prosince 1995, proběhl redesign webových stránek.
Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
Byla vydána nová verze 7.0 linuxové distribuce Parrot OS (Wikipedie). S kódovým názvem Echo. Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Vývojáři postmarketOS vydali verzi 25.12 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 0.41.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 5.5 (novinky) skriptovacího jazyka Lua (Wikipedie). Po pěti a půl letech od vydání verze 5.4.
inet 192.168.1.1/24 brd 192.168.1.255 scope global eth1. So sietovkou su cez switch pripojene 2 routre 192.168.1.3 a 192.168.1.4. Oba routre maju default gateway 192.168.1.1. Moj problem spociva v tom, ze stroje za jednym routrom nevidia tie za druhym. ip_forward je povoleny. Routovacia tabulka je:
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 172.18.64.0/24 via 192.168.1.3 dev eth1 192.168.101.0/24 via 192.168.1.4 dev eth1Cim by to mohlo byt?
default gw by mělo stačit.
Zkusil bych tcpdump, na tom stroji 192.168.1.1, abych zjistil jestli něco přijímá z těch dvou sítí co se nevidí. Smz takový adresát (192.168.1.1) musí existovat - nezapoměl náhodou nastavit adresu?
Který stav je závadějící?
Mně teda přijde chování linuxového IP stacku docela konzistentní. A jinak IP adresa je vlastností rozhraní (a nikoliv celého stacku) zejména kvůli routování - typická routa vede "via IP" (já vím, že jde nastavit routu "via dev" - ale říkejte to třeba takovému OSPF). Jestliže má daný stroj odeslat paket na danou cílovou IP adresu, potřebuje jednoznačně identifikovat rozhraní, kterým to má udělat.
Volba správné zdrojové adresy skutečně není tím hlavním důvodem.
To nemáte tak úplně pravdu. V Linuxu můžete klidně napsat
ip route add 10.11.12.0/24 dev eth1 ip route add 172.16.0.0/24 via 10.11.12.13
aniž byste měl na eth1 nastavenou jakoukoli adresu z rozsahu 10.11.12.0/24. A to, že to funguje, když místo prvního řádku napíšu
ip addr add 10.11.12.1/24 dev eth1
je koneckonců dáno především tím, že pak tu položku v routovací tabulce vytvoří jádro za mne.
Navíc to s přiřazením adresy rozhraní není tak jednoznačné i proto, že jednu adresu klidně mohu přiřadit více rozhraním a pořád to bude správně fungovat. Pravdou ovšem je, že když podobné věci vysvětluji ortodoxním ciscařům, mívají tendenci na mne cákat svěcenou vodu… :-)
TCP spojení snad používá pro odesílání paketů jako návratovou adresu tu adresu, na kterou ji přišel požadavek na connect, ne?
Když odpovídám, tak ano. Ale co když spojení navazuji?
ale ten IP stack, nebo cokoliv jiného se stejně podle toho přes které rozhraní packet odchází stejně nemůže pořídit, protože můžu mít na jedné sítovce dvě adresy. Musí se rozhodovat leda podle routy, do které to nacpe.
Tak dobře, upřesním to. Preferovaná zdrojová adresa (tj. ta, která se použije, není-li určena předem (např. lokální adresou socketu)) je dána parametrem src použité položky směrovací tabulky (přesněji cache). Neurčím-li ho explicitně, zvolí se:
secondarys.bind(("192.168.4.216", 9234)) ... When you make an outbound connection, it will come from that IP and that port. You can use 0 for the IP and 0 for the port, in which case the kernel picks one for you. Or you can skip the bind call entirely, which is the same as binding to ('', 0).Takže pokud bind ze sys/socket.h funguje podobně, bude nutné ošetřit právě ten případ nespecifikování adresy, kdy ji volí kernel. A tím se dostávám k
"Neurčím-li ho explicitně, zvolí se: 1) adresa, kterou mám na odchozím rozhraní."
Nemyslím si že odchozí rozhraní může být v TCP specifikováno. Myslím, že proces může jen nastavit adresu src a packet odejde rozhraním podle nastavení rout.
Nemyslím si že odchozí rozhraní může být v TCP specifikováno. Myslím, že proces může jen nastavit adresu src a packet odejde rozhraním podle nastavení rout.
Ano, správně. Ale to není v rozporu s tím, co jsem napsal. Netvrdil jsem přeci, že odchozí interface volí proces, ten volí jádro podle směrovací tabulky (tabulek).
ip route ale ip addr se mi už zdá taky správně. Ta adresa na rozhraní je opravdu snad "jen" k tomu aby bylo podle čeho vybrat adresu která bude v IP paketu jako zdroj a proto tedy je adresa spřažená se zařízením hned při přidávání.
Díky za diskuzi.
Pokud byste to chtěl mít úplně "čisté", měl byste mít (kromě výchozí brány) na routeru s adresou 192.168.1.3 nastavenu routu 192.168.101.0/24 via 192.168.1.4 a na routeru s adresou 192.168.1.4 analogicky 172.18.64.0/24 via 192.168.1.3. Protože to nastaveno nemáte, cesta paketu z jedné sítě do druhé vypadá tak, že projde routerem "své" sítě, je předán tomu routeru 192.168.1.1, a ten by jednak měl poslat ICMP Redirect a jednak by měl paket (stejným rozhraním) správně směrovat na druhý vnitřní router.
To vaše řešení bez nastavených rout na vnitřních routerech by samozřejmě fungovat mělo také, ale jednak zbytečně zatěžuje vnější router vnitrosíťovým provozem a druhák - z nějakého důvodu nefunguje
. (Napadá mě, explicitně se nezmiňujete, že stroj s adresou 192.168.1.1 je také router... I pokud by nebyl (je to třeba nějaký server), i na něm musíte mít povolen ip_forward, protože v důsledku chybějících rout na vnitřních routerech je také nucen (byť přes jedno rozhraní) routovat!)
No a pokud nic z toho nepomůže, je třeba vzít tcpdump či něco podobného a skutečně poslouchat na rozhraních všech tří routerů na síti 192.168.1.0/24 a zjistit, co se s paketem podě[la]lo. Až to zjistíte, určitě vás řešení napadne 
Ještě mne napadá možnost, že 192.168.1.1 neví, jak se dostat do některé z "krajních" sítí.
V každém případě souhlasím, že by bylo dobré zjistit, kde ty pakety skutečně mizejí - popis "počítač X nevidí na počítač Y" neříká skoro nic.
Tiskni
Sdílej: