DuckDuckGo AI Chat umožňuje "pokecat si" s GPT-3.5 Turbo od OpenAI nebo Claude 1.2 Instant od Anthropic. Bez vytváření účtu. Všechny chaty jsou soukromé. DuckDuckGo je neukládá ani nepoužívá k trénování modelů umělé inteligence.
VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.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 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Řešení dotazu:
Popravde pokud ano, tak to absolutne nechapu... proc by se tak ten system mel chovat...
Spíš je na místě otázka, proč by neměl. IP adresa se sice formálně přiřazuje určitému rozhraní, ale fakticky adresuje ten stroj jako takový, takže není důvod, proč by se neměl znát ke své adrese. V mnoha situacích je to užitečné a ty případy, kdy to vadí, jsou spíše řídké (a snadno řešitelné např. pomocí net.ipv4.conf.*.arp_filter sysctl).
Je potřeba si uvědomit, že konfigurace, kdy je více rozhraní ve stejném ethernetovém segmentu, aniž by bylo použito něco jako bonding nebo teaming, je spíše výjimečná.
It breaks things. Connect your computer to two networks and let another one use colliding IP range. You will act as an ARP-poisoning host involuntarily!
Byl by k tomu nějaký konkrétní příklad, co je myšleno tím "ARP-poisoning host"?
Upřímně řečeno, jestli si takhle někdo nakonfiguruje síť, tak si za své problémy může sám.Protože určitě nikdo neprovozuje virtuály nebo VPNky na populárních RFC1918 adresách. Jinak osobně jsem na to přišel když BOFH matfyzácké koleje začal odpojovat spolužáky za to že si nastavili jinou IP adresu než jaká jim byla přidělena a zjistilo se že to jsou tímto způsobem leakující virtuály.
To bych na Linux opravdu nesvádělLinux za to může tím že má nečekané výchozí nastavení a obecně se o tom neví. Upřímně nechápu proč default není arp_ignore=1 nebo dokonce 2.
a už vůbec bych za tím nehledal konspirační teorie o "E.T. phone home"Zaměření stránky se trochu rozrostlo z původního volání domů na obecné věci které vedou k nečekanému narušení soukromí.
Protože určitě nikdo neprovozuje virtuály nebo VPNky na populárních RFC1918 adresách.
Ať si klidně provozuje - ale pokud je chce provozovat na stejném adresním rozsahu, jaký se používá v síti, do které je připojený host, tak by si měl dobře rozmyslet, co dělá a proč. To jsou právě ty speciální situace, kvůli kterým je možné defaultní chování změnit.
Jinak osobně jsem na to přišel když BOFH matfyzácké koleje začal odpojovat spolužáky za to že si nastavili jinou IP adresu než jaká jim byla přidělena
Za to ale zase nemůže Linux. Je-li správce sítě ignorant, dokáže vyrobit problém s jakýmkoli systémem. Chce-li někdo dvě oddělené sítě, má to tak nakonfigurovat; ne jen tak plácnout dva rozsahy na jeden fyzický segment, předstírat, že ten druhý neexistuje a spoléhat na to, že všichni budou tu hru hrát s ním a tvářit se, že ty ARP dotazy nevidí.
Linux za to může tím že má nečekané výchozí nastavení
Pro jistotu jsem si znovu přečetl příslušnou část RFC 826 a pořád tam nevidím nic, na základě čehož bych to chování považoval za nečekané - spíš naopak.
Ať si klidně provozuje - ale pokud je chce provozovat na stejném adresním rozsahu, jaký se používá v síti, do které je připojený host, tak by si měl dobře rozmyslet, co dělá a proč. To jsou právě ty speciální situace, kvůli kterým je možné defaultní chování změnit.To je zajímavá apologetika. Z čeho přesně usuzuješ, že správce místní sítě úmysně zvolil stejný rozsah jako správce VPN nebo naopak? Jaký je přesně běžný praktický účel takovéhoto výchozího chování? Dosavadní skóre této diskuze je takové, že to dělá problémy a přitom to k ničemu není.
Za to ale zase nemůže Linux. Je-li správce sítě ignorant, dokáže vyrobit problém s jakýmkoli systémem. Chce-li někdo dvě oddělené sítě, má to tak nakonfigurovat; ne jen tak plácnout dva rozsahy na jeden fyzický segment, předstírat, že ten druhý neexistuje a spoléhat na to, že všichni budou tu hru hrát s ním a tvářit se, že ty ARP dotazy nevidí.Pokud jde o více síťových prefixů na stejném segmentu, tak kde se v citovaném píše o dvou subnetech na jednom fyzickém segmentu a jak přesně to souvisí s uvedeným problémem? V čem přesně vadí mít na fyzickém segmentu adresy z různých rozsahů?
Z čeho přesně usuzuješ, že správce místní sítě úmysně zvolil stejný rozsah jako správce VPN nebo naopak?
Nic takového jem netvrdil. Tvrdím, že pokud někdo svůj počítač připojí dvěma rozhraními do dvou segmentů používajících stejný adresní rozsah, pak je to nestandardní situace, které je potřeba přizpůsobit konfiguraci.
Jaký je přesně běžný praktický účel takovéhoto výchozího chování?
Viz RFC 826: "Am I the target protocol address?" Ani slovo o tom, že bych měl zkoumat, na jakém rozhraní mám tu adresu nastavenou. Je to moje adresa, přišel dotaz, odpovím.
Pokud jde o více síťových prefixů na stejném segmentu, tak kde se v citovaném píše o dvou subnetech na jednom fyzickém segmentu a jak přesně to souvisí s uvedeným problémem?
Co třeba "Přípojím počítač do sítě kde se používají rozsahy 10.0.0.0/24 a 192.168.0.0/24 a dostanu povolení nastavit si IP 192.168.0.6/24." Tedy někdo používá dva různé rozsahy a z nějakého záhadného očekává, že se stanice budou chovat, jako by tam byl jen jeden a že budou ignorovat ARP dotazy na adresy z toho druhého. Pokud chce na jednom fyzickém ethernetu provozovat dvě virtuální sítě a jednu z nich zpřístupnit jen někomu, má k dispozici prostředky, jak to docílit.
Viz RFC 826: "Am I the target protocol address?" Ani slovo o tom, že bych měl zkoumat, na jakém rozhraní mám tu adresu nastavenou. Je to moje adresa, přišel dotaz, odpovím.OK, takže bug není v Linuxu, ale přímo v tom RFC.
a že budou ignorovat ARP dotazy na adresy z toho druhéhoStejně jako očekávám, že stanice, které jsem dal IP 192.168.0.6 neodpoví na ARP dotaz na IP 192.168.0.7, tak očekávám, že neodpoví na ARP dotaz na 10.0.0.1.
Když jsme u toho vytahování RFCček, ve kterém RFC se píše že na fyzické síti mají mít všechny počítače adresy jenom z jednoho rozsahu?
V žádném - a já taky netvrdil, že to je nutné. Tvrdil jsem něco jiného: že je chyba používat dva rozsahy a spoléhat na to, že stanice budou pakety týkající se toho druhého ignorovat - že je budou ignorovat i v případě, že na ně zareagovat mají.
Stejně jako očekávám, že stanice, které jsem dal IP 192.168.0.6 neodpoví na ARP dotaz na IP 192.168.0.7, tak očekávám, že neodpoví na ARP dotaz na 10.0.0.1.
To je ale naprosto chybné očekávání (oboje). To, jestli má stanice nastavenou adresu 192.168.0.6, nemá naprosto žádný vliv na to, jak bude odpovídat na dotazy na 192.168.0.7 nebo 10.0.0.1. Pokud bude mít ta stanice nastavenou adresu 192.168.0.7, je naprosto v pořádku, že na příslušný ARP dotaz odpoví; totéž pro 10.0.0.1.
OK, takže bug není v Linuxu, ale přímo v tom RFC.
Je-li v něčem "bug", tak především v současné zvrácené koncepci lokálních sítí s (ne moc) náhodně přidělenými privátními rozsahy, které se chaoticky propojují dohromady a občas pochopitelně kolidují. A pak každou chvíli přijde nějaký rozumbrada, který nám vysvětlí, že takhle to přece funguje úplně skvěle, všichni jsou happy a IPv6 je výmysl pomatených akademiků.
Takže místo sdělení jakou dostal adresu mám uživatelům rozesílat ještě informace o tom jaké další subnety provozuju?
Pokud chci a potřebuji, aby se k těmto rozsahům chovali nějakým zvláštním způsobem (např. je nepoužívali), tak bych v zájmu všech zúčastněných měl.
A když zjistí, že jsou v konfliktu, tak jim nezbývá než se odpojit, protože jinak porušují RFC. Ach jo.
Nemusejí se odpojit, stačí když upraví svou konfiguraci tak, aby s tím problém nebyl (třeba tím sysctl, které právě pro takové případy existuje). Právě proto bych jim měl říct, že se v tom segmentu daný rozsah používá (pokud je nechci nebo nemůžu od něj izolovat), aby se podle toho mohli zařídit.
že je budou ignorovat i v případě, že na ně zareagovat majíPro mě bylo překvapivé zjištění že stroj má podle RFC odpovídat i když mu přijde ARP požadavek na jiný interface než na kterém ta adresa je (osobně si myslím že v roce 1982 něco takového prostě nečekali a dnes by to autor napsal jinak).
To je ale naprosto chybné očekávání (oboje). To, jestli má stanice nastavenou adresu 192.168.0.6, nemá naprosto žádný vliv na to, jak bude odpovídat na dotazy na 192.168.0.7 nebo 10.0.0.1.Ach jo, samozřejmě jsem tím myslel že jí z toho rozsahu 192.168.0.0/24 přidělím pouze adresu 192.168.0.6.
Je-li v něčem "bug", tak především v současné zvrácené koncepci lokálních sítí s (ne moc) náhodně přidělenými privátními rozsahy, které se chaoticky propojují dohromady a občas pochopitelně kolidují.I v případě že bude mít každý unikátní rozsah tam bude problém s tím narušením anonymity.
Nemusejí se odpojit, stačí když upraví svou konfiguraci tak, aby s tím problém nebylAle pak budou porušovat RFC :). Proč to sysctl není ve většině distribucí default nastavené na 1 nebo dokonce 2?
osobně si myslím že v roce 1982 něco takového prostě nečekali
A jsme u toho: situace, o které se bavíme, je natolik nestandardní, že jde svým způsobem proti samé podstatě TCP/IP (I jako internet … inter/net). Je dobře, že máme nástroje, jak ji řešit, ale není to něco, podle čeho by se měly nastavovat defaulty.
Proč to sysctl není ve většině distribucí default nastavené na 1 nebo dokonce 2?
Protože je to nestandardní nastavení pro nestandardní konfigurace. Konfigurace, kdy se používají adresy ze stejného rozsahu na dvou různých segmentech, do kterých jsem připojen dvěma různými rozhraními (aniž bych tam měl třeba bridge nebo ARP proxy), je sice možná, ale je nestandardní. Mně ke "štěstí" bohatě stačí, že většina distribucí defaultně zapíná RP filter, nestojím o to, aby měnily ještě defaultní chování ARP.
Námět k zamyšlení: Linux standardně přijímá jako příchozí pakety, které mají jako cílovou adresu kteroukoli z jeho adres, bez ohledu na to, jestli je nastavena na příchozím rozhraní nebo na kterémkoli jiném. Samozřejmě se toto chování dá potlačit, ale defaultně se tak (nejen) Linux chová. Proč by se tedy neměl defaultně v rámci ARP protokolu hlásit k adrese, pro kterou (na daném rozhraní) přijímá příchozí pakety? Nebylo by takové chování nekonzistentní?
situace, o které se bavímeTak zapomeň na to že by někdo mohl považovat za problém „přišel jsem do cizí sítě a nastavil jsem si vlastní IP adresu z vlastního rozsahu“ a věnuj se tomu „zajímá mě, jestli se támhle Franta připojuje do VPNky konkurence“.
Linux standardně přijímá jako příchozí pakety, které mají jako cílovou adresu kteroukoli z jeho adres, bez ohledu na to, jestli je nastavena na příchozím rozhraní nebo na kterémkoli jiném.Hmm, to taky nevím, jestli je úplně šťastné.
a věnuj se tomu „zajímá mě, jestli se támhle Franta připojuje do VPNky konkurence“.
Tady mi trochu uniká souvislost. Jak z toho, že mi stroj odpoví na ARP dotaz na adresu třeba 10.0.1.113 (a tedy ji nejspíš má nastavenou na některém rozhraní), poznám, že se připojuje zrovna do VPN konkurence? Jak jako firemní admin budu vědět, že konkurence používá zrovna tyhle adresy? A i kdyby ano, jak budu vědět, že to není kterákoli z tisíců dalších, kde je používají (třeba jeho síť doma)?
Linux standardně přijímá jako příchozí pakety, které mají jako cílovou adresu kteroukoli z jeho adres, bez ohledu na to, jestli je nastavena na příchozím rozhraní nebo na kterémkoli jiném.Hmm, to taky nevím, jestli je úplně šťastné.
To je ale pořád to, co jsem psal hned na začátku: IP adresa je adresa hosta, ne konkrétního rozhraní.
RFC 1122, sekce 3.2.1.3:
… An incoming datagram is destined for the host if the datagram's destination address field is:
(1) (one of) the host's IP address(es); or
…
(Je tam host, netýká se to tedy jen routerů.) Možná to bylo v některém novějším RFC změněno, ale v tom případě je na tobě, abys ho našel. :-)
Ne, určitě nespletl. Je to reakce na první větu:
Já to taky vidím tak, že má být IP adresa především adresa rozhraní a že by stroj, který není router, vůbec nemusel přijímat pakety určené pro adresu na jiném rozhraní, než na které přišly.
RFC 1122 říká pravý opak: paket je určen pro daný host, pokud se jeho cílová adresa shoduje s některou z adres toho hosta - ani slovo o tom, že by adresa byla vázána na konkrétní rozhraní a že by se mělo zohlednit, jestli paket přišel právě na toto rozhraní.
To sice není, ale ta věta tvrdí něco, co je v rozporu s jedním ze základních RFC, takže je relevantní na to upozornit.
Nepopírám, že kdyby "otcové zakladatelé" tehdy věděli to, co víme dnes, navrhli by ledacos jinak (přičemž si ale nejsem vůbec jistý, že by se to týkalo i toho, o čem se tu bavíme). Na druhou stranu si ale myslím, že by si člověk měl dobře rozmyslet, jestli si uvědomuje celý kontext a jestli se příliš nesoustředí na svůj specifický use case, než prohlásí, že je něco navrženo špatně.
Tohle mi připadá jako nutné a samozřejmé. Pingat na router mohu uvedením jakékoli adresy nějakého jeho rozhraní. A muselo by to takto dopadnout i v interpretaci, kdy router paket přijme, prožene přes routovací tabulku to výstupního rozhraní, na výstupním rozhraní zjistí, že paket fakticky patří jemu a pak ho samozřejmě musí přijmout. A úplně stejně by odesílal zpětně v této interpretaci odpověď tedy nejdříve začít na rozhraní do cizí sítě, tam zjistit že na cílovou adresu platí routovací pravidla, přeroutovat paket na odpovídající rozhraní a poslat k cíli. Fakticky to dopadne úplně stejně jako když paket přijme hned a bude hned odpovídat.Linux standardně přijímá jako příchozí pakety, které mají jako cílovou adresu kteroukoli z jeho adres, bez ohledu na to, jestli je nastavena na příchozím rozhraní nebo na kterémkoli jiném.Hmm, to taky nevím, jestli je úplně šťastné.
Je pravda, že by to konceptuálně šlo brát jako formu forwardingu a navázat to na příslušný sysctl.
To by asi šlo (kdyby se to tak udělalo od začátku, teď už samozřejmě ne), ale jediné, co by to přineslo, by byly komplikace a horší výkon.
Horší je, že interně v linuxu tyhle věci zjevně fungují zcela odlišně.
Proč "horší"?
Přečtěte si, prosím, celou diskusi. Už včera jsem sem dával odkaz na RFC, kde je to řečeno dost jednoznačně. Ještě jednou: IP adresa je adresa hosta a ne adresa konkrétního rozhraní, takže o tom, zda je paket určen pro mne (z hlediska IPv4 adresace), rozhoduje to, zda jeho cílová adresa je některá z mých adres; to, na které přišel rozhraní, v tom nehraje roli (viz též příslušná citace z RFC 1122).
U IPv6 už to samozřejmě může být jinak, protože tam máme adresy a routy s definovaným scope, takže má smysl, abych se třeba k link local adrese hlásil jen na rozhraní, na kterém je nastavena.
Samozřejmě že je.Na tohle už jsem trochu starý. Kdybych chtěl vést diskuzi tohoto typu, udělám si exkurzi do mateřské školy. Znovu kroutím hlavou nad tím, jak tě mohl Martin minule obhajovat. Vzhledem k tomu, že nemám náladu na to, abys mi zase psal měsíc uražené příspěvky v nesouvisejících diskuzích, bude asi lepší té diskuze zanechat. Omlouvám se za mírně osobní a nepříjemný tón příspěvku, ale obávám se, že si za něj můžeš i trochu sám.
Ptal ses, jestli takový důvod existuje, já jsem takový důvod napsal.Obávám se, že se nejsme schopni shodnout ani na tom.
ale to opravdu není můj problém.Ovšem, že ne. Je to můj problém a proto ho taky řeším. Tyhle komentáře píšu už jen proto, že by mi přišlo nefér neobjasnit, jak jsem k tomu došel.
Vzhledem k tomu, že nemám náladu na to, abys mi zase psal měsíc uražené příspěvky v nesouvisejících diskuzíchTak toho jsem si nevšiml a to tady slackuju víc než je zdrávo.
No to je teda naprostá hovadina.
Opravdu si myslíte, že takhle svým tvrzením dodáte větší váhu?
Na úrovni IP taky automaticky nepřijde odpověd z druhého interfacu (dokud není nastaveno routování nebo bridge), tak naprosto nedává smysl, aby ARP tohle dělalo.
A který má být ten druhý interface? To, jestli host přijme paket s určitou cílovou adresou, ani to, přes které rozhraní bude odesílat odpověď na něj, vůbec nezávisí na tom, na kterém rozhraní je ta adresa formálně nastavená.
No to je teda naprostá hovadina.Opravdu si myslíte, že takhle svým tvrzením dodáte větší váhu?
Sluší se nazvat věci pravým jménem. A to co tady kdákáte, hovadina beze sporu je.
Na úrovni IP taky automaticky nepřijde odpověd z druhého interfacu (dokud není nastaveno routování nebo bridge), tak naprosto nedává smysl, aby ARP tohle dělalo.A který má být ten druhý interface? To, jestli host přijme paket s určitou cílovou adresou, ani to, přes které rozhraní bude odesílat odpověď na něj, vůbec nezávisí na tom, na kterém rozhraní je ta adresa formálně nastavená.
Ale pochopitelně, že v běžných konfiguracích závisí.
Takže hovadina, dokonce "beze sporu"? Tak si to vyzkoušíme. Mám dva stroje, 11sp3 a 12sp0, jejich eth1 jsou ve stejném segmentu, "12sp0" má navíc eth2, který je zapojený jinam.
12sp0:~ # cat /proc/sys/net/ipv4/ip_forward 0 12sp0:~ # ip link set eth1 up 12sp0:~ # ip addr add 172.17.1.120/24 brd + dev eth1 12sp0:~ # ip link set eth2 up 12sp0:~ # ip addr add 172.17.2.120/24 brd + dev eth2 12sp0:~ # tcpdump -nepi eth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 11sp3:~ # ip link set eth1 up 11sp3:~ # ip addr add 172.17.1.113/24 brd + dev eth1 11sp3:~ # ip route add 172.17.2.120 dev eth1 11sp3:~ # ping -nc 3 172.17.2.120 PING 172.17.2.120 (172.17.2.120) 56(84) bytes of data. 64 bytes from 172.17.2.120: icmp_seq=1 ttl=64 time=4.77 ms 64 bytes from 172.17.2.120: icmp_seq=2 ttl=64 time=0.463 ms 64 bytes from 172.17.2.120: icmp_seq=3 ttl=64 time=0.671 ms --- 172.17.2.120 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.463/1.970/4.777/1.986 ms
A na 12sp0 vidím
08:31:04.221152 00:0c:29:3e:51:eb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.17.2.120 tell 172.17.1.113, length 46 08:31:04.221243 00:0c:29:67:d5:a7 > 00:0c:29:3e:51:eb, ethertype ARP (0x0806), length 42: Reply 172.17.2.120 is-at 00:0c:29:67:d5:a7, length 28 08:31:04.221853 00:0c:29:3e:51:eb > 00:0c:29:67:d5:a7, ethertype IPv4 (0x0800), length 98: 172.17.1.113 > 172.17.2.120: ICMP echo request, id 10255, seq 1, length 64 08:31:04.221973 00:0c:29:67:d5:a7 > 00:0c:29:3e:51:eb, ethertype IPv4 (0x0800), length 98: 172.17.2.120 > 172.17.1.113: ICMP echo reply, id 10255, seq 1, length 64 08:31:05.218998 00:0c:29:3e:51:eb > 00:0c:29:67:d5:a7, ethertype IPv4 (0x0800), length 98: 172.17.1.113 > 172.17.2.120: ICMP echo request, id 10255, seq 2, length 64 08:31:05.219051 00:0c:29:67:d5:a7 > 00:0c:29:3e:51:eb, ethertype IPv4 (0x0800), length 98: 172.17.2.120 > 172.17.1.113: ICMP echo reply, id 10255, seq 2, length 64 08:31:06.217983 00:0c:29:3e:51:eb > 00:0c:29:67:d5:a7, ethertype IPv4 (0x0800), length 98: 172.17.1.113 > 172.17.2.120: ICMP echo request, id 10255, seq 3, length 64 08:31:06.218293 00:0c:29:67:d5:a7 > 00:0c:29:3e:51:eb, ethertype IPv4 (0x0800), length 98: 172.17.2.120 > 172.17.1.113: ICMP echo reply, id 10255, seq 3, length 64 08:31:09.230179 00:0c:29:67:d5:a7 > 00:0c:29:3e:51:eb, ethertype ARP (0x0806), length 42: Request who-has 172.17.1.113 tell 172.17.1.120, length 28 08:31:09.230899 00:0c:29:3e:51:eb > 00:0c:29:67:d5:a7, ethertype ARP (0x0806), length 60: Reply 172.17.1.113 is-at 00:0c:29:3e:51:eb, length 46
Takže přestože je adresa 172.17.2.120 formálně nastavena na eth2, stroj přijímá pakety s touto cílovou adresou i na eth1 a pokud to tak vychází na základě routovací tabulky, přes eth1 na ně i odpovídá.
Tak jak je to s tím "kdákáním hovadin"?
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
21.8.2015 13:49
21.8.2015 22:00
22.8.2015 09:26
23.8.2015 15:25
netstat -r tak ji pošle podle ní, a pokud rozhodnout není možné pošle ICMP "destination unreacheble"filter netfilteru se vyhodnocují až po routing decision, ne před ním) při zapnutém IP forwardingu. Pro zdejší diskusi je ale podstatné spíš to, že Linux přijme paket s cílovou adresou e.f.g.h jako příchozí i když přijde na eth0, a to i při vypnutém IP forwardingu. Důvodem je skutečnost, že tohle není žádný forwarding, ten paket je vyhodnocen jako příchozí podle příslušné routy v tabulce local (zjednodušeně řečeno proto, že se jeho cílová adresa shoduje s některou z adres toho stroje); teprve kdyby routing rozhodl, že je to paket pro někoho jiného (např. všechny ostatní adresy z e.f.g.0/24 coby cílové), šlo by o forwarding a hrálo by roli nastavení IP forwardingu (ale to pak zase i v případě, že by odchozím rozhraním bylo opět eth0 - což také může být na první pohled trochu matoucí). Ze stejného důvodu bude ten paket netfilterem testován v řetězci INPUT a ne FORWARD (to je mimochodem důvod, proč se vyhodnocují až po routing decision - jinak bychom nevěděli, který řetězec se má testovat).
Námět k zamyšlení: Linux standardně přijímá jako příchozí pakety, které mají jako cílovou adresu kteroukoli z jeho adres, bez ohledu na to, jestli je nastavena na příchozím rozhraní nebo na kterémkoli jiném.To je ovšem vcelku praktické, zvláště když ten linuxový stroj pakety směruje.
Proč by se tedy neměl defaultně v rámci ARP protokolu hlásit k adrese, pro kterou (na daném rozhraní) přijímá příchozí pakety?Protože tím dělá bordel na síti, která s danou IP adresou nemá nic společného.
Nebylo by takové chování nekonzistentní?To si nemyslím.
Tvrdím, že pokud někdo svůj počítač připojí dvěma rozhraními do dvou segmentů používajících stejný adresní rozsah, pak je to nestandardní situace, které je potřeba přizpůsobit konfiguraci.Takže místo sdělení jakou dostal adresu mám uživatelům rozesílat ještě informace o tom jaké další subnety provozuju? A když zjistí, že jsou v konfliktu, tak jim nezbývá než se odpojit, protože jinak porušují RFC. Ach jo.
Tiskni
Sdílej:
