NetworkManager 1.14.0

Dva a půl měsíce po vydání verze 1.12.0 byla vydána nová verze 1.14.0 sady nástrojů pro správu síťových připojení NetworkManager. Přehled novinek v souboru NEWS. Zdůraznit lze například podporu IEEE 802.15.4 a 6LowPAN zařízení, konfiguraci LLMNR nebo detekci rozhraní VPN WireGuard.

15.9.2018 10:55 | Ladislav Hagara | Nová verze

Komentáře

[Petr Ježek]

Konečně nekdo vzal na vědomí, že existuje a funguje wireguard...

[Petr Ježek]

Mimochodem, podpora wireguard přímo v jádře se plánuje pro verzi 4.20/5.0, což je pouze logickým pokračováním Linosova zájmu o trochu jiný a mnohem bezpečnější VPN. Otázkou zůstává, zda je pro NM bezpečnostně akceptovatelné nadále používat VPN na něčem jiném než na Zincu.

[Michal Kubeček]

podpora wireguard přímo v jádře se plánuje pro verzi 4.20/5.0

Upřímně řečeno, s ohledem na aktuální stav a to, že jsme těsně před RC4, bych přítomnost wireguardu v příštím merge window považoval za příznak toho, že je s procesy něco těžce v nepořádku.

pokračováním Linosova zájmu

Zrovna tu Linusovu intervenci ve stylu "mně se to líbí, tak doufám, že nebudete dělat problémy" bych označil za jeden z nejvíc WtF momentů podlední doby (vůči tomu, co se děje ve stable už jsem trochu otupěl).

o trochu jiný a mnohem bezpečnější VPN

Mnohem bezpečnější než co?

[little.owl]

+1

[Harvie.CZ]

Myslim, ze NM do toho jaky kryptograficky API pouziva ktera VPN nic neni. To je vec uzivatele. Stejne jako kdyz budes pouzivat NM na spojeni na Wifi s WEP. Je to tvuj problem.

[Roman]

Taky uspesne pouzivam, pekna vec a snadno nastavitelna :)

[magor]

http://www.abclinuxu.cz/software/system/site/networkmanager Nejsou v tom odkaze hodně zastaralé informace? Proč se tam tedy odkazuje?

[Nic]

Protože Hagara

[Andrej]

No to znám, tuhle "podporu". Ta spočívá v tom, že se přidá do nmcli a všech možných grafických frontendů položka v menu, ale žádná fungující implementace za ní nestojí.

Takhle přibyla někdy kolem roku 2009 podpora pro EAP-TLS. První úspěšná připojení NetworkManagerem k WiFi s EAP-TLS nebo k ethernetu s 802.1x a EAP-TLS se datují do roku 2014, ale ještě to tenkrát dost pokulhávalo.

Položky kolem IPSec jsou tam už taky snad pět let, ale nefunguje nic z toho, StrongSwan se samozřejmě připojuje bez problémů, zatímco NetworkManager zase jenom potichu selže, aktivita žádná, debuggovací hlášky žádné, jen to prostě tradičně nefunguje.

No, máme rok 2018, takže na funkce "podporované" ve verzi 1.14 se můžeme těšit kolem roku 2023. Do té doby se můžeme toužebně dívat na ty položky v menu a nakonfigurovat si to jako sady systemd unit nebo něco podobného, protože NetworkManager to jednoduše nedá.

[benitto]

Tenhle komentar je podle me dost zavadejici

No to znám, tuhle "podporu". Ta spočívá v tom, že se přidá do nmcli a všech možných grafických frontendů položka v menu, ale žádná fungující implementace za ní nestojí.

co konkretne? bridge, bond, team, vlan, tuntap, ethernet, wifi, macsec, dbus interface, nmclient, nmcli, nmtui, nm-connection-editor, nebo jinde? Velka cast veci je aktivne pouzivana a tudiz opravovana ci doplnovana o nove funkce. Vyvoj vetsiny softwaru je inkrementalni. Na tom neni nic divneho.

Takhle přibyla někdy kolem roku 2009 podpora pro EAP-TLS. První úspěšná připojení NetworkManagerem k WiFi s EAP-TLS nebo k ethernetu s 802.1x a EAP-TLS se datují do roku 2014, ale ještě to tenkrát dost pokulhávalo.

Dobre, nevim jak v roce 2009, ale minimalne od verze 1.6 je 802-1x na ethernetu i wifi kazdodenne testovan v CI systemu jak unit tak integracnimim testy a je plne funkcni.

https://ci.centos.org/view/NetworkManager/

 

Položky kolem IPSec jsou tam už taky snad pět let, ale nefunguje nic z toho, StrongSwan se samozřejmě připojuje bez problémů, zatímco NetworkManager zase jenom potichu selže, aktivita žádná, debuggovací hlášky žádné, jen to prostě tradičně nefunguje.

Pouzivam NM s IPSec 8+ let (nejdrive NM-vpnc, pak NM-libreswan) a vse funguje ku spokojenosti, nic potichu neselhava, vse v pohode. Da se pouzivat i vice vpn pripojeni najednou. Testovano denne od verze 1.4. Strongswan sice testovan neni (odted mame v TODO), ale nepocitam ze by byl nejak zasadne jiny v logovani, debugovani atd.

tohle by melo pomoct pri logovani:

nmcli general logging level DEBUG domains ALL

pripadne:

nmcli general logging level DEBUG domains VPN

nmcli general logging level DEBUG domains VPN_PLUGIN

Byl by k dispozici nejaky bug report pokud neco nefunguje? Brblat v diskuzi je trosku nestastny pristup ve svete open-source

No, máme rok 2018, takže na funkce "podporované" ve verzi 1.14 se můžeme těšit kolem roku 2023. Do té doby se můžeme toužebně dívat na ty položky v menu a nakonfigurovat si to jako sady systemd unit nebo něco podobného, protože NetworkManager to jednoduše nedá.

Muzete byt konkretni? Zkousel jste neco co nefunguje, zahlasil jste bug report? Jak sem psal vyse, brblani nikomu a nicemu neprospiva. Diky.

p.s. https://github.com/NetworkManager/NetworkManager-ci/tree/master/nmcli/features myslim o pokryti testy napovi vice.

[PetrHL]

Možná je problém v tom, že aby fungovalo hromadu věcí, musí se doinstalovat zvlášť balíčky. Třeba na Fedoře jsem potřeboval VPN, musel jsem hledat, že musím nainstalovat nějaký NetworkManager-strongswan a NetworkManager-strongswan-gnome. Pak teprve ta správná VPN objevila v nabídce. Nevím jestli je to správná cesta. Možna z hlediska balíčkování ano, ale pro uživatele rozhodně ne. Potřebuju VPN a musím hledat jaké balíčky instalovat, místo toho, abych prostě vybral typ připojení ze seznamu.

Další věc, která se mi fakt nelíbila, bylo nutnost zkoumat logy abych zjistil, co se stalo. Informace o chybě mohla být rovnou v nějakém message boxu. Určitě uživatelsky příjemnější než nutnost zjišťovat chyby přes journalctl. Stávající chování je takové, že se VPN prostě nesestaví a hotovo. Ale proč, to nenapíše.

[benitto]

Možná je problém v tom, že aby fungovalo hromadu věcí, musí se doinstalovat zvlášť balíčky. Třeba na Fedoře jsem potřeboval VPN, musel jsem hledat, že musím nainstalovat nějaký NetworkManager-strongswan a NetworkManager-strongswan-gnome. Pak teprve ta správná VPN objevila v nabídce. Nevím jestli je to správná cesta. Možna z hlediska balíčkování ano, ale pro uživatele rozhodně ne. Potřebuju VPN a musím hledat jaké balíčky instalovat, místo toho, abych prostě vybral typ připojení ze seznamu.

Pokud si u kazde normalni distribuce nainstalujete Desktop ci Workstation tak tam budete mit vetsinu dulezitych pluginu predinstalovanych, od wifi, bluetooth, gsm,  po vetsinu vpn pluginu. NM to modularni aby se neinstalovaly zbytecnosti treba na server (treba wifi, bluetooth ci wwan moduly). Pokud jste to nemel v zakladu je to rozhodne na bug report na distribuci. Tak jsem se koukal do F28 a mate pravdu, strongswan tam v zakladu neni, je tam openconnect, pptp, libreswan, vpnc, openvpn. Zrejme strongswan nepovazuji release inzenyri za dostatecne rozsireny aby bylo nutno jej instalovat v zakladu. Jak jsem psal vyse, ale to neni chyba NM, ale distribuce. Modularnost navrhu taky nelze povazovat za chybu.

Další věc, která se mi fakt nelíbila, bylo nutnost zkoumat logy abych zjistil, co se stalo. Informace o chybě mohla být rovnou v nějakém message boxu. Určitě uživatelsky příjemnější než nutnost zjišťovat chyby přes journalctl. Stávající chování je takové, že se VPN prostě nesestaví a hotovo. Ale proč, to nenapíše.

Tady je to zase trochu jinak. V GNOME se o pripojeni stara Gnome Shell. Takze pokud neukazuje chyby, tak je to problem GS a ne NM. Pokud pouzijete nmcli, nebo nmtui (zase ve zvlastnim modulu) tak tam velice pravdepodobne uvidite chybu popsanou. GNOME ma na to aplikaci Logs, kde by to melo byt videt. Nekdy je ovsem nutno zvysit level loggingu aby byla chyba dobre videt. Mit vsude debug (ci dokonce trace) level je zase z vykonostniho hlediska problem. Takze je to otazka balance. Tezko rict jestli se nekdy error reporting NM v GS resil. Ja o tom nevim.

[PetrHL]

Pokud si u kazde normalni distribuce nainstalujete Desktop ci Workstation tak tam budete mit vetsinu dulezitych pluginu predinstalovanych, od wifi, bluetooth, gsm,  po vetsinu vpn pluginu. NM to modularni aby se neinstalovaly zbytecnosti treba na server (treba wifi, bluetooth ci wwan moduly). Pokud jste to nemel v zakladu je to rozhodne na bug report na distribuci. Tak jsem se koukal do F28 a mate pravdu, strongswan tam v zakladu neni, je tam openconnect, pptp, libreswan, vpnc, openvpn. Zrejme strongswan nepovazuji release inzenyri za dostatecne rozsireny aby bylo nutno jej instalovat v zakladu. Jak jsem psal vyse, ale to neni chyba NM, ale distribuce. Modularnost navrhu taky nelze povazovat za chybu.

Rozumím, modulárnost návrhu za chybu nepovažuji. U verze Desktop by v NM těch pluginů asi mělo být nainstalováno co nejvíce, protože tvůrce distribuce nemůže vědět, co kdo používá. Když pak chcete VPN a musíte googlit, proč vlastně tento typ nemáte v nabídce, není to ideální.

Tady je to zase trochu jinak. V GNOME se o pripojeni stara Gnome Shell. Takze pokud neukazuje chyby, tak je to problem GS a ne NM. Pokud pouzijete nmcli, nebo nmtui (zase ve zvlastnim modulu) tak tam velice pravdepodobne uvidite chybu popsanou. GNOME ma na to aplikaci Logs, kde by to melo byt videt. Nekdy je ovsem nutno zvysit level loggingu aby byla chyba dobre videt. Mit vsude debug (ci dokonce trace) level je zase z vykonostniho hlediska problem. Takze je to otazka balance. Tezko rict jestli se nekdy error reporting NM v GS resil. Ja o tom nevim.

Aha, to jsem netušil. V mém případě, myslím, stačilo základní logování. Dostal jsem špatný secret key. Rád bych pomohl s implementací error reportingu do GS, bohužel mé znalosti na takový úkol rozhodně nestačí .

[Andrej]

Ve chvíli, kdy se nedá připojit k síti, jsou bug reporty "opravdu, ale opravdu" asi to poslední, na co člověk myslí, že ano.

Mimochodem, ten NetworkManager průjem už zase nefunguje. Nebo pořád? Zase tady mám praobyčejnou EAP-TLS WiFi síť. Obyčejný dual stack, ath10k_pci na klientovi, nic zajímavého, všechny mobily s Androidem se připojí ve vteřině a wpa_supplicant s tímto nastavením se připojí v méně než vteřině:

network={
        ssid="Net3"
        scan_ssid=1
        key_mgmt=WPA-EAP
        eap=TLS
        identity="andrej"
        pairwise=CCMP
        group=CCMP
        ca_cert="/var/ca/ca-cert.pem"
        client_cert="/etc/crypto/Net3.cli.crt"
        private_key="/etc/crypto/Net3.cli.key"
}

Taky dhcpcd všechno nastaví, než mrknu, IPv6 i IPv4.

Jenže kdepak NetworkMananger — ten je i na tuhle trivialitu krátký. Nepřipojí se, pokud je WiFi karta ath10k_pci. Kupodivu s WiFi od Intelu to jde. Na ath10k_pci řekne "No suitable device found for this connection." Následuje rychlé hledání, zákaz náhodných MAC adres pro scany, zákaz asi 5 dalších nesmyslů, které podporuje asi tak jeden WiFi driver, ale NetworkManager je očekává od všech driverů … a zase hovno, nepřipojí se, stejná chyba. V logu samozřejmě nic, protože v tom novém ideálním světě NetworkManagera přece není potřeba nic logovat, že ano.

Takže, než začnu znova debuggovat, proč ten odporný NetworkManager průjem není schopen navázat jednoduché IPSec spojení, které StrongSwan nakopne okamžitě, budu muset napřed přijít na to, proč se NetworkManager neumí připojit k obyčejné WiFi síti. Protože bez té obyčejné WiFi sítě se těžko hlásí bugy nebo testuje IPSec. A upřímně řečeno, nemám vůbec chuť takový polorozpadlý projekt jako NetworkManager podporovat nějakým debuggováním. Nefunční položky v konfiguraci mě už stály příliš mnoho času.

Kdyby autoři na férovku řekli "WiFi funguje jedině to nejjednodušší 'personal', 'enterprise' v podstatě nefunguje", případně "IPSec tunnel mode přes IPv6 neumíme, protože NetworkManager přestal teprve včera ignorovat IPv6", přišlo by mi to v pohodě. Prostě bych zkusil využít, co to umí, a některé experimentální novinky bych třeba vyzkoušel — s tím, že jde o experiment, že to asi s největší pravděpodobností nebude fungovat a že asi budu muset hlásit nějaké otravné bugy. Místo toho jsem už asi podesáté v situaci, kdy ten nesmysl něco slibuje, ale nefunguje to. To je pak obrovská ztráta času, kdy uživatel celé hodiny hledá chybu u sebe, jenom aby zjistil, že wpa_supplicant, dhcpcd a StrongSwan se připojí bez problémů a okamžitě.

Dnes zase, zrovna teď:

# nmcli con up 'Net3'
Chyba: Selhala aktivace připojení: No suitable device found for this connection (device wls1 not available because device is not available).

Omlouvám se předem za výrazivo, ale tuhle^^^ sračku se mám snažit nějak debuggovat a zprovoznit? To jako fakt vážně? Jak? Proč? To si raději manuálně spustím wpa_supplicant, který ve vteřině okamžitě funguje. Taky poslední dobou rád používám systemd-networkd.

Let that sink in: (device wls1 not available because device is not available) Tohle je použitelný software? Asi ne tak úplně.

[little.owl]

Pouzivam NM s IPSec asi sest let bez problemu.

[Andrej]

Aha. Používám NM asi 7 let, ale bez IPSec. Protože když se NM nezmůže ani na ty vrstvy pod IPSec, nemá smysl snít o IPSec.