Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: JanSt 22. 08. 2022, 17:28:39
-
Prosím o radu
Mám zařízení s pevnou IP adresou a minipc. Minipc (debian linux) má dva ethernet porty mezi kterými je bridge, tzn. funguje jako switch.
Potřebuji na eth0 mít adresu přidělenou z dhcp, to tak nyní funguje, a na eth1 komunikovat s druhým zařízením. Ip adresa druhého zařízení je z jiného rozsahu než přiděluje dhcp.
Druhé zařízení nepotřebuje komunikovat ven, pouze s minipc.
Lze vyřešit?
-
ifconfig bridgeRozhrani:2 IPzDRUHEHOrozsahuPROtohlePC up
(pripadne jeste netmask pridat)
-
To nedává moc smysl. Pokud mají být na obou rozhraních různé IP rozsahy, pak by neměly být v bridge. Takže rozpojit bridge, nastavit různé adresy na rozhraní a zapnout IP forwarding.
Nebo lépe popiš, o co se snažíš a proč tam máš bridge.
RDa: ifconfig prosím ne, to je dvacet let neudržovaná utilita, dnes jsme dávno v době ip
-
Začněte tím, že to popíšete tak, aby se v tom dalo vyznat. Píšete o „zařízení“, „minipc“, „druhé zařízení“ – druhé zařízení je to první zařízení s pevnou IP adresou, nebo je to třetí zařízení v síti? eth0 a eth1 jsou na tom minipc? Pokud ano, tak konfigurace, kdy máte dvě zařízení v bridge, a přitom je každé v jiné IP síti, je dost zvláštní. Bridge propojuje dvě fyzické sítě do jedné, takže pak nad tou jednou fyzickou sítí máte jednu IP síť.
Každopádně na konfiguraci v linuxu nepoužívejte ifconfig, který je v linuxu zastaralý už přes 20 let a nefunguje správně.
-
Zařízení 1 má pevnou IP adresu.
Zařízení 2 má eth0 a eth1 s následujícím nastavením:
iface eth0 inet manual
iface eth0 inet manual
iface br0 inet dhcp
bridge_ports eth0 eth1
To je výchozí nastavení.
Čeho chci dosáhnout: zařízení 2 komunikuje přes eth1 se zařízením 1, a současně na eth0 komunikuje ven do internetu, ip adresa je přidělena z dhcp.
Zkusil jsem vyřešit se zachováním výchozího nastavení (to není podmínka) takto:
ip route add 192.168.200.0/24 dev br0
Což sice funguje, ale hen do restartu. Když jsem zkusil zapsat do configu, už jsem se k zařízení 2 nemohl připojit.
-
Zrušte ten bridge, nedává tam žádný smysl. Pak už stačí jenom eth1 nastavit statickou IP adresu ze stejné sítě, jako má zařízení 1. Tu nenastavujte příkazem, ale v konfiguraci - tím se zajistí to, že ot bude fungovat i po restartu. Nastavte ji v /etc/network/interfaces, volba address.
-
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet static
address 192.168.200.1
netmask 255.255.255.0
Vše ostatní jsem smazal. Je to tak správně?
-
Zařízení 1 má pevnou IP adresu.
Zařízení 2 má eth0 a eth1 s následujícím nastavením:
iface eth0 inet manual
iface eth0 inet manual
iface br0 inet dhcp
bridge_ports eth0 eth1
To je výchozí nastavení.
Čeho chci dosáhnout: zařízení 2 komunikuje přes eth1 se zařízením 1, a současně na eth0 komunikuje ven do internetu, ip adresa je přidělena z dhcp.
Zkusil jsem vyřešit se zachováním výchozího nastavení (to není podmínka) takto:
ip route add 192.168.200.0/24 dev br0
Což sice funguje, ale hen do restartu. Když jsem zkusil zapsat do configu, už jsem se k zařízení 2 nemohl připojit.
Nevím jak u debianu, ale v Centosu se ti to manuální nastavení v souborech po restartu odněkud přepíše (googli), radši používám nmtui. Ty doby, kdy jsem se radoval, že Unix se dá konfigurovat čistě přes texťáky, jsou bohužel pryč.
Jo a nezapomeň na ten ipforwarding a aby přežil reboot.
-
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet static
address 192.168.200.1
netmask 255.255.255.0
Vše ostatní jsem smazal. Je to tak správně?
Na první pohled tam žádnou chybu nevidím. Pokud vám to bude fungovat, považoval bych to za správné :-)
-
Ty doby, kdy jsem se radoval, že Unix se dá konfigurovat čistě přes texťáky, jsou bohužel pryč.
Ale nejsou. Linuxové distribuce se stále konfigurují přes textové soubory, akorát musíte vědět, co se kde konfiguruje.
-
Nebo se dá do Debianu doinstalovat netplan, v jednoduchém YAML to nastavit a nechat vygenerovat.
-
Děkuji za pomoc. Funguje dle očekávání.
-
Ty doby, kdy jsem se radoval, že Unix se dá konfigurovat čistě přes texťáky, jsou bohužel pryč.
Ale nejsou. Linuxové distribuce se stále konfigurují přes textové soubory, akorát musíte vědět, co se kde konfiguruje.
A to já bych s dovolením věděl, pracuju s Unixem na 90% úvazek přes 30 let, akorát mě sere, když mi nějaký network manager přepíše flat files configuration.
Ale to je holt život a tam mířila má poznámka.
-
Děkuji za pomoc. Funguje dle očekávání.
A pokud bys stejně z nějakého důvodu chtěl bridge (já nevím, bylo by v síti těch zařízení víc) nebo neměl dvě síťovky a chtěl dát adresy z jiného rozsahu na jednu, tak to samozřejmě normálně jde. Ručně:
ip a a 192.168.200.1/24 dev br0V konfiguraci:
allow-hotplug eth0
iface eth0 inet dhcp
auto eth0:0
iface eth0:0 inet static
address 192.168.200.1/24
což kupodivu nevytvoří alias eth0:0, ale normálně to nastaví tu adresu a současně spustí dhclienta. A možná by to mohlo fungovat i bez toho :0, pro dvě statické adresy to funguje, ale pro kombinaci DHCP + statická jsem to nezkoušel.
Mimochodem jak máš v konfiguraci to "auto eth0", tak to pokud vím znamená, že se bude čekat při bootu než se adresa dostane - což může být nepříjemné když síť nefunguje a potřebuješ to opravit a čekáš a nejde to přerušit (zdravíme do systemd). Já auto typicky nedávám, jen allow-hotplug.
akorát mě sere, když mi nějaký network manager přepíše flat files configuration
Tak ty věci nepoužívej, ne? Já třeba žádný network manager nikde nemám (vyjma některých notebooků co dávám BFU kde si mají umět vyklikat novou wifi).
-
Pokud ano, tak konfigurace, kdy máte dvě zařízení v bridge, a přitom je každé v jiné IP síti, je dost zvláštní. Bridge propojuje dvě fyzické sítě do jedné, takže pak nad tou jednou fyzickou sítí máte jednu IP síť..
K tomu by mě zajímalo, i když se jedná o něco trochu jiného (bez bridgů), je možné "sdílet" L2 infrastrukturu (nebo její část) pro víc odlišných sítí ne, ničemu to nevadí? Otázka je, jak časté to je...
Prostě na jednom switchi budou zařízení se sítí 10.1.0.0/24 plus 192.168/24, jeden port ze switche povede do dalšího kde je stejná situace a třeba ještě z těchto dvou povede z každého port do dalších dvou switchů, které třeba už jsou jen 10.1/24 only sítě a 192.168/24 only sítě. (akorát už to překročilo nějaké to pravidlo 3-2-1), ale snad pro ilustraci to stačí, že třeba někde ve velkém baráku se může nacházet několik switchů, přes které může téct provoz deseti L3 sítí (když se zrovna nevyžije routing , že provoz ze zařízení z jedné sítě je schovaný pod méně než n MAC adres)
jako vadit to asi může, není to best practice, oddělení VLAN by taky asi přišlo vhod a hlavně to zapojení routerů, neboť tam bude hodně velký broadcast a přetížená CAM tabulka (ale záleží na rozsahu , na 3 sítě na privátu to není problém , ale zapojit takhle celou kolej je třaskavá směs)
-
K tomu by mě zajímalo, i když se jedná o něco trochu jiného (bez bridgů), je možné "sdílet" L2 infrastrukturu (nebo její část) pro víc odlišných sítí ne, ničemu to nevadí? Otázka je, jak časté to je...
Ano, je to možné a je to běžné. Když to použijete bez VLAN, je to víceméně na dobré slovo (když si někdo nastaví IP adresu z jiné sítě, normálně se do ní dostane), s VLAN a třeba kontrolou MAC adres už je to i docela bezpečné.
-
K tomu by mě zajímalo, i když se jedná o něco trochu jiného (bez bridgů), je možné "sdílet" L2 infrastrukturu (nebo její část) pro víc odlišných sítí ne, ničemu to nevadí? Otázka je, jak časté to je...
Prostě na jednom switchi budou zařízení se sítí 10.1.0.0/24 plus 192.168/24, jeden port ze switche povede do dalšího kde je stejná situace a třeba ještě z těchto dvou povede z každého port do dalších dvou switchů, které třeba už jsou jen 10.1/24 only sítě a 192.168/24 only sítě. (akorát už to překročilo nějaké to pravidlo 3-2-1), ale snad pro ilustraci to stačí, že třeba někde ve velkém baráku se může nacházet několik switchů, přes které může téct provoz deseti L3 sítí (když se zrovna nevyžije routing , že provoz ze zařízení z jedné sítě je schovaný pod méně než n MAC adres)
jako vadit to asi může, není to best practice, oddělení VLAN by taky asi přišlo vhod a hlavně to zapojení routerů, neboť tam bude hodně velký broadcast a přetížená CAM tabulka (ale záleží na rozsahu , na 3 sítě na privátu to není problém , ale zapojit takhle celou kolej je třaskavá směs)
Sice to jde, ale v praxi se na to používají VLANy, aby ty sítě byly skutečně oddělené. Dnes už to není jen o IPv4 unicast provozu, kde tohle "jen na oko" oddělení bude funkční. Stačí, aby na tu síť pak někdo strčil tiskárnu, NASku, televizi,... a každé tohle zařízení začne broadcastem a multicastem vysílat, že je na síti a všichni napříč těmi sítěmi to uvidí. Do toho nám přichází IPv6, kde se mnohem víc věci řeší "nějak automaticky a samo" a tam je opět základem L2 vrstva, která je "jen pro naší síť".
-
Pokud chce mít někdo v domácí síti switch podporující VLANy, ať to klidně má. Ale myslím, že ten, kdo chce mít doma (nebo i v malé firmě) oddělenou síť, třeba na pokusy nebo pro IoT zařízení, obejde se i bez VLANů. Ale také je pravda, že už se dají pořídit switche s podporou VLAN za méně než tisícovku.
-
Přesně tak, víc subnetů na jedné L2 síti je zcela legitimní konfigurace. Posouzení bezpečnosti je na zodpovědnosti pachatele takové konfigurace. Jak řekl pan Jirsák, na krátkodobé hraní takové věci používám zcela běžně. Jenom je potřeba dát si bacha, abych neměl v síti dva DHCP servery (nezkoordinované, tzn. každý za sebe autoritativní).
Konkrétně mít pevnou adresu a zároveň DHCP klienta může být zajímavé třeba u nějaké zapečené krabičky, kde chcete, aby měl BFU k dispozici pevnou well-known adresu, na kterou se vždycky dostane, přitom aby to fungovalo i v síti s DHCP, kde se na krabičku dostane zase jinak. Nemám to ze své hlavy, někde jsem to už potkal. Jako pravověrný síťař nad tím kroutím hlavou, ale BFUčkům to evidentně pomáhá.
Ohledně původního dotazu bych měl poznámku, že je kravinimum mít L2 rozhraní jako member v bridgi, a zároveň mu nastavit L3 adresu - toto mi hlava nebere. Z logiky věci, jakmile přiřadím L2 rozhraní do bridge, tak L3 adresu můžu dát leda virtuálnímu vnitřnímu rozhraní br0 (např.) které do toho soft-bridge kouká taky, a slouží právě pro přístup do takto softwarově spřažené L2 sítě.
Ohledně tiskáren, ano toho jsem si už někde všiml. Že letitý profi admin potřebuje v rámci LAN jednu jedinou oddělenou VLANu, a to pro tiskárny. Zjevně kvůli jejich užvaněnosti - jako nejjednodušší způsob, jak zabránit, aby jednotlivé desktopy viděly napřímo každou tiskárnu co se kde šustne. Desktopy klidně v defaultní VLANě. To jsou ty úplně definitivní konce Bonjour, uPnP apod :-D
-
Co prosím přesně na ifconfig nefunguje ?
Každopádně na konfiguraci v linuxu nepoužívejte ifconfig, který je v linuxu zastaralý už přes 20 let a nefunguje správně.
-
ifconfig stale normalne funguje, jen je 'pry' deprecated, bo se neudrzuje. Jinak mi to zatim fungovalo vsude
-
ifconfig stale normalne funguje, jen je 'pry' deprecated, bo se neudrzuje. Jinak mi to zatim fungovalo vsude
Pokud člověk přijde k čistému systému, ve kterém žádný nástroj nic nenastavoval, tak pak může ifconfig fungovat tak jak má. Avšak pokud někdo předtím použil třeba ip nebo nějaký network manager sáhnul na nastavení sítě, může např. ifconfig neukazovat IP adresu nebo ukázat jen jednu a ne všechny.
Také se dnes ip používá pro konfiguraci VLAN, bridge, bonding, pro správu routovacích tabuelk a dalších pokročilejších síťových konfigurací a nahrazuje to staré nástroje jako route, brctl, vconfig, ifenslave atd. Je tedy běžné, že v aktuálních distribucích je jen ip a všechny tyhle obsolete nástroje tam nejsou a i když si je člověk zase doinstaluje, nedokáže jimi nastavit žádnou složitější a modernější konfiguraci.
-
ifconfig stale normalne funguje, jen je 'pry' deprecated, bo se neudrzuje. Jinak mi to zatim fungovalo vsude
Ne, nefunguje. Například nedokáže zobrazit víc IPv4 adres na rozhraní, pokud nejsou nastavené speciálním způsobem, kterému ifconfig rozumí. Nebo si naopak ifconfig vymýšlí rozhraní, která v systému nejsou. Když pak někdo dá požadavek na shození tohoto rozhraní, ifconfig místo toho shodí jiné – a uživatel se pak hrozně diví (nejlepší je, když si takhle shodí rozhraní, přes které je připojen).
-
v tom pripade to nepouzivejte, je to deprecated a tim, ze budete pouzivat jak ifconfig tak treba ip, se to pose*e urcite vic, to je snad logicky :)
-
v tom pripade to nepouzivejte
Vždyť to jsem psal. To vy jste se podivoval nad tím, proč to nepoužívat.
-
nelzete, nepodivoval jsem se nad nicim. Jen jsem psal, ze (bohuzel) ifconfig je stale vsudypritomny a funkcni (pokud clovek nepouziva i dalsi konfiguracni veci)
a zase chapu, ze jsme na foru, tak se tu muzeme hadat x mesicu. Ja si svoje rekl. Ifconfig nepouzivat, ale stale funguje.
-
nelzete, nepodivoval jsem se nad nicim. Jen jsem psal, ze (bohuzel) ifconfig je stale vsudypritomny a funkcni (pokud clovek nepouziva i dalsi konfiguracni veci)
a zase chapu, ze jsme na foru, tak se tu muzeme hadat x mesicu. Ja si svoje rekl. Ifconfig nepouzivat, ale stale funguje.
Nefunguje. Výše jsem uváděl příklady.
Ta vaše teorie, že když nebudete používat nic jiného, bude ifconfig fungovat správně – to máte něčím podložené nebo je to jen dohad? A máte svůj systém tak perfektně zmáklý, že opravdu víte, že nikde žádný nástroj nebo utilita nemůže volat ip nebo nevolá přímo funkce jádra tak, že by to mohlo ifconfig zmást?
Spíš to bude tak, že jste si zatím nevšiml toho, že by zrovna vám na vašem počítači ifconfig dělal něco špatně. (Což například znamená, že nemáte 2 IP adresy na jednom rozhraní. A nebo jste si nevšiml, že to ifconfig zobrazuje špatně.) To mi ale nepřipadá jako dostatečný důvod, proč psát do fóra, že ifconfig na linuxu funguje a mást tím lidi.
-
Me ifconfig (a dalsi puvodni sitove nastroje) porad funguji. Vicero ip, vlany, bridge, vpn. Za poslednich 20 let v linuxove sitarine jsem nemel potrebu pouzit prikaz ip, jak jsem to nastavil, tak to bylo. Takze pro bezneho uzivatele, nebo provozovatele serveru to bude porad v pohode rozhrani.
Kde by ifconfig vs ip mohlo hrat roli je nejaka infrastrukturni sitarina, ale kolik useru potrebuje "ISP like" konfiguraci sve site na PC ? :)
Ja bych navrhl zdeprekovat radeji nastroj ip, protoze ho napsal rus :-) Jak muzete necemu takovemu verit? :P
-
Takze pro bezneho uzivatele, nebo provozovatele serveru to bude porad v pohode rozhrani.
Pokud běžnému uživateli nevadí, že se nemůže spolehnout na to, co ifconfig zobrazuje…
-
ano, máte pravdu a my všichni se pleteme. (snažím se držet se citátu pana Wericha: "Jestliže se člověk hádá s blbcem víc jak půl minuty, hádají se už dva blbci.“
-
Za poslednich 20 let v linuxove sitarine jsem nemel potrebu pouzit prikaz ip
Za posledních 20 let v linuxové síťařině jsem neměl potřebu naučit se pracovat s příkazem ifconfig. ;-)
-
Za poslednich 20 let v linuxove sitarine jsem nemel potrebu pouzit prikaz ip
Za posledních 20 let v linuxové síťařině jsem neměl potřebu naučit se pracovat s příkazem ifconfig. ;-)
to je, po pravde, ta fakt lepsi varianta ;P
-
ano, máte pravdu a my všichni se pleteme.
No, „my všichni“ jste dva, zatímco o nevhodnosti používání ifconfig na linuxu tu psali čtyři lidé. Byly tu uvedené příklady, kdy ifconfig funguje špatně, ty nikdo nerozporoval. Akorát tu pořád dokola opakujete, že při vašem způsobu použití si nejste vědom toho, že by vám to fungovalo špatně.
Že to používáte sám, to je váš problém. Co ale nechápu, proč to pořád nutíte ostatním. Víte, že ifconfig funguje špatně. Tvrdíte, že při vašem způsobu použití vám funguje, ale nedokážete přesně popsat podmínky, za kterých ifconfig může fungovat správně. Nebo-li vaše rady jsou ostatním úplně k ničemu, můžou jim nanejvýš uškodit. Proč to tedy ostatním pořád nutíte? Přitom byste se měl akorát tak stydět v koutě, že pořád používáte nástroj, který už dvacet let nefunguje.
-
Kde by ifconfig vs ip mohlo hrat roli je nejaka infrastrukturni sitarina, ale kolik useru potrebuje "ISP like" konfiguraci sve site na PC ? :)
Nechci ještě víc zbytečně přikládat do flamewar, ale k té "ISP like" konfiguraci si dovolím poznámku, že v dnešní době kontejnerů se tyhle složitější konfigurace už dostávají i na desktopy a na serverech jsou už zcela běžné, zvláště, když se ten setup provozuje na více hostech a chceme aby si kontejnery komunikovaly uvnitř své sítě mezi sebou nezávisle na tom, na kterém hostu běží.
Ano, tyhle složité konfigurace řeší nějaký framework nad kontejnery, avšak když už člověk musí sáhnout na ip, je to asi proto, že řeší nějaký problém a pak je fakt vhodný na to používat ty správný nástroje, které ukáží to co mají. Proto by mělo v každé diskusi, kde někdo zmíní ifconfig zaznívat, že je to špatný nástroj a má se používat ip.
-
Ano, tyhle složité konfigurace řeší nějaký framework nad kontejnery, avšak když už člověk musí sáhnout na ip, je to asi proto, že řeší nějaký problém a pak je fakt vhodný na to používat ty správný nástroje, které ukáží to co mají.
Ani nemusím na ip sám sahat. Úplně stačí, že ho používá ten framework nad kontejnery – fakt nechci zkoumat, jestli ten framework používá síťová rozhraní tak, že tomu bude nebo nebude ifconfig rozumět.
Proto by mělo v každé diskusi, kde někdo zmíní ifconfig zaznívat, že je to špatný nástroj a má se používat ip.
Jak je vidět v této diskusi, je potřeba ještě druhá věc – aby ti, kteří stále používají na linuxu ifconfig, se tím nechlubili a nezkoušeli přesvědčovat ostatní, že je to vlastně v pohodě. Pokud to někdo používá a nedělá mu to problém, ať si to klidně používá, ale ať netvrdí ostatním, že je to v pohodě, když to neví.
-
ano, máte pravdu.