Debian netplan IPv4 static default gateway
... / Debian netplan IPv4 stati...
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Question

Debian netplan IPv4 static default gateway

by
TTY
Contributor
Created on 2024-05-01 10:11:10 (edited on 2024-09-04 11:44:42) in Serveurs dédiés

Bonjour,
- Je souhaite configurer netplan sans DHCP.
- IPv4 seulement, IPv6 ne m’intéresse pas tant que que le routage FO ne sera pas supporté par OVH

La configuration d'origine est :

network:
version: 2
ethernets:
eno1:
accept-ra: false
addresses:
- 2001:41d0:700:1f6d::/64
dhcp4: true
gateway6: 2001:41d0:700:1fff:ff:ff:ff:ff
match:
macaddress: a4:bf:01:41:83:a5
nameservers:
addresses:
- 2001:41d0:3:163::1
routes:
- to: 2001:41d0:700:1fff:ff:ff:ff:ff/128
via: '::'
set-name: eno1

De ce que j'en comprends IPv6 est en static et IPv4 en DHCP

ip route
default via 51.75.146.254 dev eno1 proto dhcp src 51.75.146.109 metric 100
51.75.146.0/24 dev eno1 proto kernel scope link src 51.75.146.109 metric 100
51.75.146.254 dev eno1 proto dhcp scope link src 51.75.146.109 metric 100
213.186.33.99 via 51.75.146.254 dev eno1 proto dhcp src 51.75.146.109 metric 100

Je modifie la conf :

network:
version: 2
ethernets:
eno1:
accept-ra: false
addresses:
- 51.75.146.109/32
dhcp4: false
match:
macaddress: a4:bf:01:41:83:a5
nameservers:
addresses:
- 8.8.8.8
- 1.1.1.1
routes:
- to: default
via: 51.75.146.254
set-name: eno1

>ping 51.75.146.254
ping: connect: Network is unreachable

ip route ne renvoi rien
> ip route

Quand je met l'IP publique du serveur en GW ça marche :

network:
version: 2
ethernets:
eno1:
accept-ra: false
addresses:
- 51.75.146.109/32
dhcp4: false
match:
macaddress: a4:bf:01:41:83:a5
nameservers:
addresses:
- 8.8.8.8
- 1.1.1.1
routes:
- to: default
via: 51.75.146.109
set-name: eno1

>ip route
default via 51.75.146.109 dev eno1 proto static

>PING google.fr (142.250.186.131) 56(84) bytes of data.
64 bytes from fra24s07-in-f3.1e100.net (142.250.186.131): icmp_seq=1 ttl=113 time=2.56 ms

J'ai juste des bases en réseaux et je reste perplexe sur ce comportement et me dis que je fais une connerie quelque part.


12 Replies ( Latest reply on 2024-05-02 13:02:55 by
TTY
)

Bonjour,

Il manque un bout (on-link) dans ton fichier, il devrait plutôt être :
[code]
network:
version: 2
ethernets:
eno1:
accept-ra: false
addresses:
- 51.75.146.109/32
dhcp4: false
match:
macaddress: a4:bf:01:41:83:a5
nameservers:
addresses:
- 8.8.8.8
- 1.1.1.1
routes:
- to: default
via: 51.75.146.254
on-link: true
set-name: eno1
[/code]

Cordialement, janus57

Merci @janus57. Mais cela ne résous pas le pb.

network:
version: 2
ethernets:
eno1:
accept-ra: false
addresses:
- 51.75.146.109/32
dhcp4: false
match:
macaddress: a4:bf:01:41:83:a5
nameservers:
addresses:
- 8.8.8.8
- 1.1.1.1
routes:
- to: default
via: 51.75.146.254
on-link: true
set-name: eno1


>netplan try --timeout 10

est ok

>netplan apply

> ping 51.75.146.254
> ping: connect: Network is unreachable

"ip route" ne renvoi rien

ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eno1: mtu 1500 qdisc mq state UP group default qlen 1000
link/ether a4:bf:01:41:83:a5 brd ff:ff:ff:ff:ff:ff
altname enp2s0
inet 51.75.146.109/32 scope global eno1
valid_lft forever preferred_lft forever
inet6 fe80::a6bf:1ff:fe41:83a5/64 scope link
valid_lft forever preferred_lft forever
3: eno2: mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether a4:bf:01:41:83:a6 brd ff:ff:ff:ff:ff:ff
altname enp3s0

Bonjour,


netplan try --timeout 10

est ok


netplan apply
ping 51.75.146.254
ping: connect: Network is unreachable


"ip route" ne renvoi rien

il y a un truc pas logique là, comment le try peut être OK si tu perd ta route vers la gateway ?
A ce stade tu devrait perdre la connexion et netplan fait un rollback.

Si tu lance le "try" en KVM/IPMI est-ce que tu perd la connexion SSH ?

Cordialement, janus57

Je fais tout en KVM.

> il y a un truc pas logique là, comment le try peut être OK si tu perd ta route vers la gateway ?

Et pourtant :

root@rescue:/etc/netplan# netplan try --timeout 10
Do you want to keep these settings?


Press ENTER before the timeout to accept the new configuration


Changes will revert in 1 seconds
Reverting.

avec :

root@rescue:/etc/netplan# cat 50-cloud-init.yaml
---
network:
version: 2
ethernets:
eno1:
accept-ra: false
addresses:
- 51.75.146.109/32
dhcp4: false
match:
macaddress: a4:bf:01:41:83:a5
nameservers:
addresses:
- 8.8.8.8
- 1.1.1.1
routes:
- to: default
via: 51.75.146.254
set-name: eno1

A ce moment là c'est toujours la conf d'origine qui joue :

root@rescue:/etc/netplan# ip route
default via 51.75.146.254 dev eno1 proto dhcp src 51.75.146.109 metric 100
51.75.146.0/24 dev eno1 proto kernel scope link src 51.75.146.109 metric 100
51.75.146.254 dev eno1 proto dhcp scope link src 51.75.146.109 metric 100
213.186.33.99 via 51.75.146.254 dev eno1 proto dhcp src 51.75.146.109 metric 100

Puis :

root@rescue:/etc/netplan# netplan apply
root@rescue:/etc/netplan#

root@rescue:/etc/netplan# ip route
root@rescue:/etc/netplan# ping 51.75.146.254
ping: connect: Network is unreachable
root@rescue:/etc/netplan#

Bonjour,

il faudrait une session KVM + SSH pour vérifier en live depuis internet.

Normalement pendant le try c'est là ou on fait les tests réseau puis seulement on applique si tout est OK.
De plus je vois que dans le dernier fichier posté le on-link à de nouveau disparu, il n'y aurait pas encore cloud-init de présent qui te joue des mauvais tours ?

**EDIT :**
Je vais tester avec mon KS1 car cela me semble bizarre..

Cordialement, janus57

Si tu veux (je veux pas t’embêter) envoi moi en MP ta clé RSA pub et je te met à dispo la machine.
Je vais lancer une fresh install (car j'ai désactivé IPV6 dessus).
J'ai le même phénomène avec un VPS.

Bonjour,


J'ai le même phénomène avec un VPS.

ça c'est d'autant plus bizarre que je l'avais testé, validé et documenté sur un VPS (Cf : https://community.ovhcloud.com/community/fr/rEsolu-sous-debian-12-passer-la-configuration-reseau-dhcp-a-static?id=community_question&sys_id=6a43d09ce596c6d02d4c0165b3e76632?u=janus57) et que je viens de le reproduire avec succès sur le même VPS réinstallé.

Cordialement, janus57

Ou j'ai lu plusieurs fois toutes tes interventions très utiles sur netplan.
Plus ça va plus je me dis que mes pb viennent du fait que je ne veuille pas de l'IPv6.


Si tu veux (je veux pas t’embêter) envoi moi en MP ta clé RSA pub et je te met à dispo la machine

Tu serais bcp plus confort sur une vrai console SSH SOL que sur un KS (j'ai pas de VPS "moderne" et le KVM est quasi inutilisable)

Bonjour,


Plus ça va plus je me dis que mes pb viennent du fait que je ne veuille pas de l'IPv6.

je viens de test premier coup => zéro problème

Je te fait un MP pour te montrer mes fichiers au complet.

Cordialement, janus57

ça marche... avec reboot et tout le toutim.
Énorme merci @janus57.

---
network:
version: 2
ethernets:
eno1:
accept-ra: false
addresses:
- 51.75.146.109/32
dhcp4: false
match:
macaddress: a4:bf:01:41:83:a5
nameservers:
addresses:
- 1.1.1.1
- 8.8.8.8
routes:
- to: default
via: 51.75.146.254
on-link: true
set-name: eno1

Je réinstaller complètement avec mes commandes post config rzo car j'ai toujours pas compris où était mon erreur :

apt install -y yamllint openvswitch-switch
chmod 600 /etc/netplan/50-cloud-init.yaml
apt purge cloud-init && apt autoclean && apt autoremove && apt autopurge
echo "net.ipv6.conf.all.disable_ipv6 = 1" > /etc/sysctl.d/70-disable-ipv6.conf
sysctl -p -f /etc/sysctl.d/70-disable-ipv6.conf

Hello, j'arrive un peu tard mais il me semble que parfois j'ai carrément dû redémarrer `systemd-networkd.service` (et peut-être jouer avec `networkctl reconfigure `) car `netplan try` ne nettoyait pas tout.
Il faut savoir que netplan n'est qu'une fine surcouche de `systemd-networkd` et il crée des fichiers dans `/run/systemd/network/` qui sont interprétés par ce dernier.
Si jamais, https://superuser.com/a/1234599 voilà comment activer le debug du service.


Hello, j'arrive un peu tard

Bah en même temps un 1er mai y-a que les indép (et @janus57) qui bossent hein :)

Merci beaucoup pour ton retour et ton suivi hautement apprécié. La piste est très intéressante car au final je n'ai toujours pas compris ce qui déconnait.