înregistrare Logare
Puncte:2
avatar Ubuntu

Comandarea configurației interfeței cu systemd-networkd

drapel pl
Ralph Bolton

Folosesc Ubuntu 20.04, cu systemd-networkd și Netplan. Am două interfețe fizice (ens3 și ens4) care sunt configurate prin DHCP (cu rezervări, deci primesc mereu aceleași adrese).

În plus, am două dispozitive tunel. Acestea sunt în afara controlului Netplan/networkd (sunt create de Strongswan, dar pentru toate intențiile și scopurile sunt create manual, rulând ceva de genul tunelul IP adauga...). Aceste dispozitive tunel au un ruta ip adăugat pentru a le trimite trafic. Când au fost create inițial, acestea funcționează bine, dar systemd-networkd va elimina în cele din urmă rutele.

Pentru a contracara acest lucru, am configurat cu succes dispozitivele tunel în systemd-networkd, dar ruta nu reușește să fie creată deoarece a fost încercată înainte ens3/ens4 sunt configurate (văd tunnel1: Nu s-a putut seta ruta: Adresă prefsrc nevalidă. Argument invalid în syslog). Am confirmat comanda prin pornire jurnal de depanare.

Pot adăuga ruta manual:

IP route add 10.0.32.0/20 dev tunnel1 scope link src 10.0.16.170 metric 100

...care funcționează bine, dar va fi eliminat mai târziu de systemd-networkd.

The documentație spune „Toate fișierele de configurare sunt sortate și procesate colectiv în ordine lexicală, indiferent de directoarele în care locuiesc.”, așa că am căutat alte fișiere de configurare și le-am găsit în /run/systemd/network:

10-netplan-ens3.link
10-netplan-ens3.network
10-netplan-ens4.link
10-netplan-ens4.network

Am încercat să-mi denumesc netdev și reţea fişiere ca 99-tunnel1.netdev sau zzzz-tunnel1.netdev etc, și chiar încercat cu 00- etc de asemenea. Indiferent ce fac, se pare mereu că ens3 și ens4 sunt configurate după interfețele tunelului și astfel ruta nu reușește întotdeauna să se adauge.

De asemenea, am încercat să-mi configurez dispozitivele în Netplan. Face unele lucruri dificile, dar în cele din urmă are aceeași problemă. Chiar dacă creează fișiere precum 10-netplan-tunnel1.network (care sunt lexical după fișierele ens3/ens4), acestea sunt încă aplicate în ordine greșită de către networked.

Sunt sigur că îmi lipsește ceva aici, dar nu văd ce. Vreo idee?

Ale mele tunnel1.netdev arata asa:

[NetDev]
Nume=tunnel1
Kind=vti
MTUBytes=1419

[Tunel]
La distanță=1.2.3.4
Local=2.3.4.5
Cheie=100

...si .reţea arata asa:

[Meci]
Nume=tunnel1

[Legătură]
RequiredForOnline=nu
MTUBytes=1419

[Abordare]
Adresa=169.254.102.162/30
Peer=169.254.102.161/30

[Traseu]
Destinație=10.0.32.0/20
PreferredSource=10.0.16.170
Metric=100
Scope=link
434
0 + 0
drapel us
slangasek
Se așteaptă ca rețeaua să nu atingă configurația, inclusiv rutele, pe dispozitivele pe care nu i s-a spus. Dar mă întreb dacă nucleul este cel care șterge automat ruta pentru tine? Observ că ruta în cauză are un „src” specificat care nu este un IP listat ca fiind asociat cu interfața. (Și, prin urmare, nu m-aș aștepta ca această rută să funcționeze de fapt așa cum a fost definit.) Care este comportamentul pe care îl așteptați de la aceasta, având în vedere că 10.0.16.170 nu este o adresă IP pe interfață?
0
Răspunde
drapel pl
Ralph Bolton
Sunt de acord că rețeaua nu ar trebui să se încurce cu lucruri pentru care nu este configurat. Totuși, da, ruta include un src care se află pe o interfață gestionată în rețea, așa că ruta ar trebui să iasă când interfața este „încărcată” (dar în caz contrar, ruta este necesară și funcționează bine). Lucrul curios este că atunci când configurează dispozitivele `ens` și `tunnel` (vti), networkd insistă să facă mai întâi tunelurile - ceea ce nu îmi pot imagina că ar fi vreodată corect, mai ales dacă este configurat să le facă ultima - și nu Se pare că nu pot schimba acel comportament.
0
Răspunde
Nate T avatar
drapel it
Nate T
ați putea scrie un script shell pe care să îl configurați într-un stil manual și apoi să configurați un job cron pentru a verifica o rută. Dacă nu este localizată nicio rută, atunci nu ar putea rula scriptul? sau reconfigurați în orice mod alegeți? Folosesc administratorul de rețea prin nmcli pentru reconf. , dar al meu este neregulat și așa m-am descurcat.
0
Răspunde
drapel pl
Ralph Bolton
Mulțumesc pentru gând, dar nu sunt un fan al soluției de script cron - dacă ruta este eliminată imediat după rularea scriptului, atunci va exista un minut de nefuncționare până când scriptul rulează din nou. Nu spuneți nimic despre rularea inutilă a scriptului de mii de ori. Este soluția de ultimă instanță și aș crede că scoaterea Systemd va fi înainte.
0
Răspunde
Puncte:1
Lukas Maerdian avatar Ubuntu
drapel cn
Lukas Maerdian

Cred că avem două probleme aici:

1/ Eliminarea rutei dvs. src s-ar putea datora pierderii intermitente a transportatorului pe interfața ens3/4. Când interfața scade (chiar dacă doar pentru scurt timp) ea șterge adresa IP și, de asemenea, rutele src legate de această adresă IP. Apoi reconfigurează IP-ul prin DHCP, dar a pierdut ruta src pe care ați adăugat-o manual. Încercați să creați un drop-in de înlocuire a configurației, de exemplu: /etc/systemd/network/10-netplan-ens3.network.d/override.conf:

[Reţea]
ConfigureWithoutCarrier=true
IgnoreCarrierLoss=true

2/ systemd-networkd procesează fișierele .network în ordine lexicală, dar adresa IP furnizată de DHCP este primită asincron numai după primirea închirierii DHCP. networkd nu blochează configurația celorlalte interfețe (adică interfața tunelului) pe acest răspuns DHCP, prin urmare ruta nu poate fi adăugată, deoarece acel src IP nu există încă în acel moment.

Spuneți că aveți o configurație care vă oferă întotdeauna aceeași adresă IP prin DHCP. De ce nu specificați această adresă IP în mod static (de ex. adrese: [10.0.16.170/30] în netplan â sau orice ar fi masca de rețea)? În acest fel, în rețea ar trebui să poată adăuga dvs PreferredSource= adresa fără probleme și reconfigurează-l după pierderea transportatorului.

0 + 0
drapel pl
Ralph Bolton
Pierderea purtătorului sună ca o cauză foarte plauzibilă a problemei - nu m-am gândit la asta și, într-adevăr, ar cauza toate problemele pe care le menționezi. Natura neblocantă a rețelei pare într-adevăr a fi problema mea - presupun că nu există nicio modalitate de a spune „așteptați până când este configurat” sau „nu faceți asta până când X se termină”, dar aș putea folosi într-adevăr un IP fix - asta aproape sigur ar rezolva problema (deși ridică altele, și anume rezoluția DNS - dar și asta se poate rezolva destul de ușor în mediul meu). Mulțumesc foarte mult pentru idei - foarte utile (din punct de vedere tehnic și pentru sănătatea mea!)
1
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.