Jak debugować sieć Linux: Adres jest już w użyciu

10

Mam pole linuksowe Slackware, w którym nie mogę uruchomić żadnej usługi, która nasłuchuje na jednym porcie na localhost. Za pomocą strace dowiedziałem się, że błąd występuje podczas bind()połączenia, a błąd jest następujący EADDRINUSE (Address already in use):

bind(3, {sa_family=AF_INET, sin_port=htons(874), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address already in use)

Dzieje się tak z każdym procesem, który próbuję rozpocząć nasłuchiwaniem na tym porcie, więc nie jest to związane z samym procesem. Powyższe dane wyjściowe strace pochodzą z polecenia strace -ff nc -l -p 874 -s 127.0.0.1.

Sugeruje to, że proces już nasłuchuje na porcie lokalnym hosta 874. Jednak nie mogę go znaleźć. Następujące polecenia nic nie zwracają:

netstat -aplunt | grep :874
netstat -na | grep :874
lsof -i :874
lsof -i tcp | grep 874
fuser 874/tcp
socklist | grep 874
iptables -t filter -S | grep 874
iptables -t nat -S | grep 874
iptables -t mangle -S | grep 874
conntrack -L | grep 874

Jeśli spróbuję nasłuchiwać 0.0.0.0:874, zakończy się niepowodzeniem z tym samym błędem. Słuchanie na jednym z adresów IP skonfigurowanych na nic działa OK, a słuchanie 127.0.0.2:874również działa OK. Słuchanie na innym porcie działa dobrze, również na 127.0.0.1lub 0.0.0.0.

Więc teraz jestem ciekawa. Jak mogę dowiedzieć się, dlaczego stos sieci zwraca EADDRINUSE tutaj? Na jakie inne rzeczy mogę patrzeć lub jakie inne polecenia mogę uruchomić, aby uzyskać więcej informacji?

Dodatkowe informacje:

  • Jądro 4.1.31.
  • Selinux nie jest tutaj używany.
  • Próba połączenia z 127.0.0.1 za pomocą usługi Telnet zwraca komunikat „Odmowa połączenia”
  • Uruchamiam polecenia jako root
networking linux-networking roelvanmeer
źródło
1
Czy port jest wymieniony gdziekolwiek w iptables -Sdanych wyjściowych?
hertitu
1
Czy możesz również wydrukować wyjście strace -ff nc -l 874 , Ten, którego użyłeś, próbuje nawiązać połączenie z 874 jako portem źródłowym. Dzięki!
Anirudh Malhotra
2
AFAIK Linux wymaga uprawnień roota podczas słuchania portu <1000. Może tutaj jest problem.
Koraktor,
2
Czy ten host jest klientem NFS? Może używać portu źródłowego 874 do montowania NFS. W każdym razie chciałbym spróbować netstat -na | grep 874w przypadku aktualne netstatflagi są zbyt restrykcyjne.
Tom Shaw,
1
@TomShaw Właśnie stworzyłeś mój dzień! W porządku był NFS . Nie jestem pewien, jak to dokładnie się stało, ale po odmontowaniu wszystkich podłączeń NFS i ponownym uruchomieniu usług RPC i NFS problem zniknął. Z tcpdump widziałem także pewien ruch z portu 874 do portu 111 (dlaczego wcześniej o tym nie pomyślałem), co to potwierdza. Czy możesz to opublikować jako odpowiedź?
roelvanmeer

Odpowiedzi:

4

Jeśli twój host jest klientem NFS, może on używać źródłowego portu 874 do podłączenia NFS. Podejrzewam, że ponieważ połączenie nie pochodzi z przestrzeni użytkownika, może nie być widoczne dla narzędzi, z których dotąd korzystałeś.

Rozważ jedno z poniższych:

  • Dostosuj sysctls sunrpc.min_resvporti sunrpc.max_resvport(domyślnie 665 i 1023), aby zmienić zakres portów źródłowych używanych przez klienta NFS
  • Użyj portu nasłuchiwania poza tym zakresem
  • Użyj noresvportopcji montowania NFS, aby użyć zakresu nieuprzywilejowanego (może to mieć wpływ na bezpieczeństwo)
Tom Shaw
źródło