Forum Linux.général Netstat : port occupé mais pas de PID

Posté par . Licence CC By‐SA.
Étiquettes :
1
14
nov.
2024

Bonjour à tous,

En voulant jouer avec iodine, je vois que le port udp 53 est occupé sur mon serveur.

En cherchant à savoir par quelle application (car pas de serveur DNS), la commande :
netstat -tulpn me renvoie bien les ports avec les PID sauf pour le port 53 !

netstat -tulpn (extrait)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:4443 0.0.0.0:* LISTEN 830/apache2
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 831/vsftpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 638/sshd: /usr/sbin
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 947/mariadbd
tcp6 0 0 :::22 :::* LISTEN 638/sshd: /usr/sbin
udp 0 0 0.0.0.0:53 0.0.0.0:* -

Finalement je me rappelle que j'utilise wireguard sur le port 53, mais pour ma curiosité, pourquoi ne puis je pas savoir quel processus utilise ce port ?

Question subsidiaire, quelqu'un a t-il déjà implémenté une règle dans sslh pour rediriger un flux vers Wiregard ?

Merci pour vos idées / remarques :) !

  • # Root

    Posté par (site web personnel) . Évalué à 10. Dernière modification le 14 novembre 2024 à 11:36. 

    $ netstat -tulpn
(...)
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN - 
udp 0 0 127.0.0.53:53 0.0.0.0:* - 
(...)
$ sudo netstat -tulpn
(...)
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 1381/systemd-resolv 
udp 0 0 127.0.0.53:53 0.0.0.0:* 1381/systemd-resolv 
(...)

    Et en version plus moderne :

    $ ss -atulnp
(...)
udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* 
tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* 
(...)
# ss -atulnp
(...)
udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=1381,fd=13)) 
tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=1381,fd=14)) 
(...)

    • [^] # Re: Root

      Posté par . Évalué à 1.

      Bonjour, merci pour la commande ss, cependant en root ça ne change rien, je n'ai pas plus d'info.

  • # Kernel space

    Posté par . Évalué à 4.

    Je pense que c'est parce que la partie de Wireguard qui écoute est en kernel-space et non user-land, et donc n'est pas un processus.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.