Connexion ethernet verrouillée sur Debian Buster

Support Debian
Tags: #<Tag:0x00007f63e5a3ec38>
#1

Bonjour,

Suite à une réinstallation de Windows 10 + mise à jour à la version 1909, ma Debian 10 installée en dual-boot n’a pas accès à internet. La carte réseau est bien détectée, la connexion ethernet bien établie et active, mais aucun trafic n’est possible. L’icône dans la barre des tâches semble indiquer qu’elle est verrouillée : image

Après quelques fouilles sur les forums, il me semble que Windows est le grand suspect, en particulier sa fonction Wake On Lan (WOL) qui fermerait le port ethernet lors de l’extinction de l’ordinateur, le rendant inaccessible à Debian : https://superuser.com/questions/546441/no-internet-in-linux-after-rebooting-from-windows

J’ai essayé de désactiver toutes les fonctions liées au Wake On Lan dans Windows, j’ai essayé de toutes les activer, sans effet sur le résultat : la connexion reste verrouillée dans Debian.

Quelqu’un aurait-il une idée des pistes à explorer svp ?

#2

Comment vois-tu cela ?

Quelle icône ? Je ne vois rien qui ressemble à une icône réseau.

#3

Il s’agit de la première icône dans la barre des tâches, dans l’image que j’ai copiée ci-dessus. C’est bien l’icone qui me donne accès aux réglages de ma connexion ethernet. Je n’avais jamais vu cette icône auparavant, et je n’ai aucune autre information quand je clique dessus : simplement un accès à l’activation / désactivation de la connexion et aux réglages… mais rien d’anormal. Cf images en PJ

img1 img2

Voici mon matériel réseau :
$ lspci -nnd ::0200
22:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)

Et voici ce que renvoie la commande ip a :

1: lo: <LOOPBACK,UP,LOWER_UP> 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
    valid_lft forever preferred_lft forever
2: enp34s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:d8:61:4e:71:de brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.54/24 brd 192.168.1.255 scope global dynamic noprefixroute enp34s0
       valid_lft 85373sec preferred_lft 85373sec
    inet6 fe80::5b6d:6ef:4922:cbbd/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:8d:52:7d:25 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever`
#4

et pour compléter :

$ systemctl status networking.service 
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mon 2020-02-03 16:37:04 CET; 1h 1min ago
     Docs: man:interfaces(5)
  Process: 740 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=0/SUCCESS)
 Main PID: 740 (code=exited, status=0/SUCCESS)

$ systemctl status network.target 
● network.target - Network
   Loaded: loaded (/lib/systemd/system/network.target; static; vendor preset: enabled)
   Active: active since Mon 2020-02-03 16:37:04 CET; 1h 1min ago
     Docs: man:systemd.special(7)
           https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget
#5

Cette icône ressemble plus à celle d’un logiciel de sécurité qu’à un gestionnaire de réseau. Elle était différente avant ?

D’après ip a, l’interface ethernet a une adresse IPv4 marquée comme dynamique, donc a priori configurée par un client DHCP, ce qui qui indique que la communication avec un serveur DHCP est possible.

#6

Merci pour cette remarque. En effet, j’ai réinitialisé manuellement mon VPN et la connexion est rétablie. J’ai l’impression que la dernière connexion au VPN s’est mal terminée (j’ai probablement éteint l’ordinateur sans déconnecter le VPN), et que c’est ça qui empêchait la connexion normale.

Merci beaucoup pour ton aide, et mes excuses auprès de Windows (pour cette fois) pour la fausse accusation