Dotaz: Systemd, NetworkManager, Debian - konfigurace sítě

[rovny_banan]

Mám Debian Stretch na notebooku. Notebook má drátové a bezdrátové připojení k síti.

Mám dual-stack síť. IPv4 chci nastavovat síť pomocí DHCP. IPv6 pomocí autokonfigurace.

Jak nakonfigurovat síť na notebooku, abych dosáhl stavu, že dostanu vždy stejnou IP adresu pro IPv4 i IPv6 na drátovém i bezdrátovém připojení?

Můžu konfigurovat po debianovsku /etc/network/interfaces. Můžu konfigurovat NetworkManager. A taky můžu konfigurovat Systemd v /etc/systemd/network/....

Pokusil jsem se nakonfigurovat Systemd, aby mi na bezdrátovém interfacu změnil MAC adresu, že to tím celé bude vyřešeno. MAC adresa se změní a zůstane nastavena do té doby, než odpojím kabel. Jakmile ho odpojím, skočí po tom NetworkManager a překonfiguruje to zpátky. Dobře, nastavím na NetworkManageru klonovanou MAC adresu. Takže mám konečně správnou MAC a tím i IPv4 adresu.

No jo, ale IPv6 adresa je úplně špatně. Vzhledem, k tomu, že se má odvozovat od MAC adresy, která je teď už konečně stejná, jako na drátovém interfacu, tak bych očekával, že budou obě stejné. Ale nejsou. Drátový interface má IPv6 adresu odvozenou od MAC adresy. Ale ten bezdrátový má nějakou náhodnou, která se té na drátovém interfacu vůbec nepodobá. A nepodobá se ani hardwarové MAC adrese na bezdrátu.

Pokusy nastavit to pomocí systemd a IPv6Token skončily neúspěchem.

Dál nevím.

Dá se to nastavit?

---

---

Odpovědi

[Andrej]

Příloha:

• networkmanager.png (76795 bytů)

Jsou vypnuté privacy extensions (jako v příloze)?

Nemůže se náhodou stát, že by byl ten počítač připojený na okamžik zároveň k WiFi a k ethernetu? Pak je docela možné, že různé konfigurátory sítě prostě nedovolí, aby měl na dvou rozhraních stejnou IP adresu. (IPv4 z roku 1975 to možná dovolí, ale umím si přdstavit, že ve slušně vychovaném IPv6 to asi nejde.)

Otázka taky je, jaký je důvod mít stejnou IP adresu na obou rozhraních. Pokud vím, TCP spojení se při přechodu z jednoho připojení na druhé nezachovají ani při stejné IP adrese, pokud to bude jiné fyzické rozhraní. Jestli je motivací zachování TCP spojení, pak je asi potřeba nastavit si VPN (tedy ideálně IPSec s notebookem v roli road warrior) a získat tím další vrstvu navíc, která zachování TCP spojení (a některých dalších kontextů) zajistí. Použitelnější řešení ale většinou spočívá v tom, že se takové věci řeší na aplikační vrstvě podle potřeb dané aplikace. (Třeba Google Hangouts na mobilu bez problémů ustojí přechod ze 4G na WiFi a zpátky během videohovoru. To je příklad situace, kterou řeší podle svých potřeb aplikační vrstva. Browser třeba ve většině případů zas až tak real-time být nepotřebuje.)

[rovny_banan]

Jsou vypnuté privacy extensions?

Nebyly, už jsou. Ale nemá to vůbec žádný vliv.

Nemůže se náhodou stát, že by byl ten počítač připojený na okamžik zároveň k WiFi a k ethernetu?

O to se nestarám. To je věc NetworkManageru. Ale nemůžu to vyloučit.

Když zapnu počítač a mám připojený kabel, dostanu na drátovém rozhraní zvolenou IPv4 adresu a autokonfigurací IPv6 adresu odvozenou od hardwarové MAC adresy drátového rozhraní.

Když zapnu počítač a mám odpojený kabel a na bezdrátovém rozhraní mám naklonovanou MAC adresu drátového rozhraní, dostanu na bezdrátovém rozhraní zvolenou IPv4 adresu a autokonfigurací IPv6 adresu odvozenou od něčeho, co nedokážu nalézt. Ta IPv6 adresa je pořád stejná. Když totéž provedu bez naklonované MAC adresy, je ta IPv6 adresa odvozená od hardwarové MAC adresy bezdrátového rozhraní.

Pokud vím, TCP spojení se při přechodu z jednoho připojení na druhé nezachovají ani při stejné IP adrese, pokud to bude jiné fyzické rozhraní.

Nevím jak na IPv6, ale na IPv4 mi to pro ssh funguje úplně v pohodě. NFS je také spokojen.

[Peter Golis]

Tak ono ti to funguje? Potom ovšem môžeme vec považovať za vybavenú.

Teda, ak to náhodou nefunguje len v práci na servri pomocou bondingu. To je ovšem iný prípad.

[rovny_banan]

Všechno funguje pro IPv4. Ale na IPv6 nejsem schopný dostat stejnou IP adresu.

O žádném bondingu jsem nemluvil a nikde ho nemám. Ale teď jsem rychlým googlením našel nějaký popis, kde je bonding na notebooku použit pro přesně stejný cíl, kterého se snažím dosáhnout.

[Peter Golis]

Pretože na takéto veci sa obvykle používa bonding. Ten nezblbne napríklad v prípade že by boli obidve sieťovky naraz aktívne.

[rovny_banan]

Přílohy:

• Ethernet.png (17272 bytů)
• Wifi-hardw.png (17484 bytů)
• Wifi-klon.png (17462 bytů)

Jenom pro pořádek malý dodatek. V noci jsem na to už asi neviděl a překoukl jsem se v tom, jak se autokonfigurací přidělují IPv6 adresy.

Ve skutečnosti klonování MAC adresy nemělo vůbec vliv na IPv6 adresu.

Přehlédl jsem to asi proto, že na drátovém rozhraní jsou si všechny přidělené IPv6 adresy podobné v koncové části, zatímco na bezdrátovém rozhraní je každá jiná.

[míra]

Co znamená ta černá tečka v obrázku?

[Andrej]

Nevím.

[petr_p]

Je možné, že požadovaná konfigurace je v rozporu s nějakými pravidly (RFC 4291). Například:

IPv6 addresses of all types are assigned to interfaces, not nodes. An IPv6 unicast address refers to a single interface.

a

Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet prefix.

Pak je tam výjimka:

A unicast address or a set of unicast addresses may be assigned to multiple physical interfaces if the implementation treats the multiple physical interfaces as one interface when presenting it to the internet layer. This is useful for load-sharing over multiple physical interfaces.

To by možná vysvětlovalo, proč je nutné nejprve obě rozhraní dát do bridge/bondingu.

Osobně si myslím, že dávat 802.11 a 802.3 do bridge vytváří nefunkční paskvil. Jsou to nekompatibilní protokoly (přes 802.11 linku nelze přenášet rámce s cizími MAC adresami, takže nelze řetězit segmenty jako u 802.3) a to, co implementace dělají, je vždy nedokonalý podvod. Schválně si zkuste pingnout ff02::1 z jednoho rozhraní, jestli se vám ozvou i stroje na té druhé fyzické síti.

To, co chcete, se jmenuje mobilní IP, což je v podstatě automatická VPN, která umí přeposílat packety z domácí adresy na aktuální adresu mobilního klienta a zároveň zkracovat trasu vynecháním domácího agenta, když se ověří, že oba konce komunikace mobilní IP podporují.

[rovny_banan]

Díky. To je určitě ono.

Budu to buď muset zkusit s bondingem nebo to prostě nechat být.

[pavlix]

Měnit MAC v systemd není úplně dobře. Lepší bude nastavit to v NM, který matchuje rozhraní podle původní MAC, ale pro účely komunikace nastavuje zvolenou. I další věci se nastavujou v NM včetně třeba typu IPv6 adresy.

[rovny_banan]

NetworkManager si dělá, co chce a pro autokonfiguraci ipv6 používá bůhví co.

Ačkoliv jsem původně dosahoval na ethernetu ipv6 adresy odvozené od MAC adresy, teď už to nefunguje.

Ze zoufalství jsem vypnul na routeru ipv6 Router Advertisement, aby to neovlivňoval a aby to bylo jednodušší a zkoumám pouze link local adresy.

Na notebooku:

Když shodím rozhraní, odeberu driver pro rozhraní, vypnu NM, vymažu ručně NM všechny konfigurace (ethernet, wifi, prostě všechno) v /etc/NetworkManager/system-connections a vymažu soubory ve /var/lib/NetworkManager/, nastartuji NM, nahodím driver pro rozhraní, NM se vrhne do práce a zkonfiguruje síť, zkontroluji ipv6 adresu na ethernetu (link local), tak je tam ipv6 adresa nějaká nedefinovatelná.

Když shodím rozhraní, odeberu driver pro rozhraní, vypnu NM, nahodím driver pro rozhraní, zapnu ručně síť, zkontroluji ipv6 adresu na ethernetu, tak je tam link local ipv6 adresa odvozená od té MAC adresy.

Kdo se v tom má vyznat?

[rovny_banan]

Příloha:

• Snímek z 2016-04-03 11-33-34.png (18353 bytů)

V obrázku je sled příkazů. Nešel vložit jako text kvůli nedovoleným značkám.

[rovny_banan]

Tak sorry. NM nastavuje ipv6 adresu podle svého defaultního nastavení v módu addr-gen-mode = stable-privacy, zatímco já jsem očekával addr-gen-mode = eui64. V tom druhém módu to dělá přesně to, co jsem po tom chtěl. IPv6 adresa je odvozená od klonované MAC adresy.

[pavlix]

NetworkManager si dělá, co chce a pro autokonfiguraci ipv6 používá bůhví co.

Nikoliv, jen konečně dotáhl podporu novějších RFC a umožňuje nakonfigurovat několik různých režimů. Dotáhl tak například i funkcionalitu dhcpcd a pravděpodobně i jiných.

Ačkoliv jsem původně dosahoval na ethernetu ipv6 adresy odvozené od MAC adresy, teď už to nefunguje.

To je zcela korektní výchozí chování, které je možné podle potřeby přenastavit. Kluci si dali docela dost práce s dokumentací a konkrétně s generováním manuálových stránek. Takže je šoda toho nevyužít.

nm-settings(5)

Ze zoufalství jsem vypnul na routeru ipv6 Router Advertisement, aby to neovlivňoval a aby to bylo jednodušší a zkoumám pouze link local adresy.

Tedy děláte na síti náhodné nesmyslné změny namísto čtení dokumentace a konfigurace systému dle vašich požadavků.

tak je tam ipv6 adresa nějaká nedefinovatelná.

Nejspíše to budou stabilní privátní adresy, což je takový hybrid mezi DUID/MAC based adresami a privacy extensions.

Když shodím rozhraní, odeberu driver pro rozhraní, vypnu NM, nahodím driver pro rozhraní, zapnu ručně síť, zkontroluji ipv6 adresu na ethernetu, tak je tam link local ipv6 adresa odvozená od té MAC adresy.

To bude tím, že existují lidé, kteří si myslí, že je skvělý nápad mít autokonfiguraci přímo v kernelu, stejně jako třeba DHCP. Bohužel měl někdo ještě blbější nápad, že se to bude zapínat samo od sebe. Ta implementace je chybová a nedostatečná a nástroje, které chtějí dělat IPv6 konfiguraci správně, ji musejí vypnout.

Proto ten zmatek. Jiná věc je samozřejmě hodnocení těch standardů samotných a jejich interpretace, ale to nemá cenu tady vůbec diskutovat.

[rovny_banan]

Dík za odpověď. nm-settings jsem fakt přehlédl. Ale naštěstí jsem našel patrně to samé na internetu (ref-settings).

[pavlix]

Jo, já jsem měl taky naučené ref-settings online, ale ještě po očku sleduju vývoj a zaregistroval jsem, když začali generovat tu manstránku.

[jbohac]

Ačkoliv jsem původně dosahoval na ethernetu ipv6 adresy odvozené od MAC adresy, teď už to nefunguje.

To je zcela korektní výchozí chování, které je možné podle potřeby přenastavit. Kluci si dali docela dost práce s dokumentací a konkrétně s generováním manuálových stránek. Takže je šoda toho nevyužít.

A dá se to nějak vypout globálně, pro všechny connections? Z manuálu jsem pochopil že ne, ale nějak tomu nemohu uvěřit. Velmi by se mi to hodilo. Nastavovat to znovu pro každou connection co vyrobím se mi nechce.

[Migi]

A co to řešit tam, kde se to řešit má, na dhcp serveru daneho AP? O.o

[rovny_banan]

Tam to vyřešit umím. Prostě jsem to chtěl udělat takhle.

A kromě toho, jestli jste si nevšiml, tak celý problém byl s IPv6, které konfiguruji autokonfigurací. Takže tam je DHCP server dost na nic.

[rovny_banan]

Takže se správným nastavením NetworkManageru jsem dosáhl stejné IPv4 i IPv6 adresy na drátovém a bezdrátovém rozhraní (vždy samozřejmě jen na jednom z nich). A nemusel jsem kvůli tomu nakonfigurovat bonding. S tím to ale také ještě vyzkouším.

A to TCP spojení přežije přepojení z bezdrátu na drát i naopak jak na IPv4 tak i na IPv6.

[pavlix]

Co takhle to trochu rozepsat, tedy konfiguraci na všech stranách? Lépe na blog než sem. Mohli bychom prodiskutovat i výhody/nevýhody konkrétního přístupu.

[Josef Kufner]

Mělo by to fungovat ve výchozí konfiguraci.

Co neuvedeš v /etc/network/interfaces, to si veme na starost Network Manager. Defaultně je v interfaces jen loopback, takže si to Network Manager pohlídá všechno.

Je nešikovné mít stejnou MAC na obou síťovkách, ale je šikovné na obou mít stejnou IP adresu. Jen je potřeba na LAN vypnout ochranu proti ARP spoofingu, neboť to pak je žádoucí chování.

[Josef Kufner]

Jinak té stejné IP jsem dosáhl pomocí konfigurace DHCP serveru, kde oběma MAC je přiřazena tatáž IP a je na notebooku, aby neměl nahozené obě síťovky najednou.

[rovny_banan]

To ano. Na IPv4 bez problémů. Ale já nemám na IPv6 DHCP server. Tak jsem to zkoušel tímto způsobem. A jak už jsem psal, funguje to.

DHCPv6 zkusím taky. Předpokládám, že to na OpenWRT půjde.

[pavlix]

Podle mě pokud chce člověk řídit IPv4 a IPv6 adresy na klientech, tak nemá smysl nadávat na nuance v autokonfiguraci a rovnou to řešit přes DHCP, které je k tomu odjakživa určené a nezměnilo se to ani pro IPv6.