Rozwiązywanie problemów z wyczerpaniem portów

Dotyczy: system Windows 10

Protokoły TCP i UDP działają na podstawie numerów portów używanych do nawiązywania połączenia. Każda aplikacja lub usługa, która musi ustanowić połączenie TCP/UDP, będzie wymagać portu po jego stronie.

Istnieją dwa typy portów:

  • Porty efemeryczne, które są portami dynamicznymi, to zestaw portów, które domyślnie każda maszyna będzie musiała nawiązać połączenie wychodzące.
  • Dobrze znane porty to zdefiniowane porty dla określonej aplikacji lub usługi. Na przykład usługa serwera plików znajduje się na porcie 445, https to 443, HTTP 80, a RPC 135. Aplikacje niestandardowe będą również mieć własne zdefiniowane numery portów.

Gdy nawiązywane jest połączenie z aplikacją lub usługą, urządzenia klienckie używają portu efemerycznego z urządzenia w celu nawiązania połączenia z dobrze znanym portem zdefiniowanym dla tej aplikacji lub usługi. Przeglądarka na komputerze klienckim będzie używać portu efemerycznego do https://www.microsoft.com nawiązywania połączenia z portem 443.

W scenariuszu, w którym ta sama przeglądarka tworzy wiele połączeń z wieloma witrynami internetowymi, dla każdego nowego połączenia, które próbuje przeglądarka, używany jest port efemeryczny. Po pewnym czasie zauważysz, że połączenia zaczną kończyć się niepowodzeniem, a jedną z dużych możliwości tego błędu będzie to, że przeglądarka użyła wszystkich dostępnych portów do nawiązywania połączeń na zewnątrz, a każda nowa próba nawiązania połączenia zakończy się niepowodzeniem, ponieważ nie ma więcej dostępnych portów. Gdy są używane wszystkie porty na maszynie, nazywamy to wyczerpaniem portów.

Domyślny zakres portów dynamicznych dla protokołu TCP/IP

Aby zapewnić zgodność z zaleceniami urzędu IANA (Internet Assigned Numbers Authority), firma Microsoft zwiększyła zakres dynamicznych portów klienta dla połączeń wychodzących. Nowy domyślny port początkowy to 49152, a nowy domyślny port końcowy to 65535. Ten wzrost jest zmianą w stosunku do konfiguracji wcześniejszych wersji systemu Windows, które używały domyślnego zakresu portów od 1025 do 5000.

Zakres portów dynamicznych można wyświetlić na komputerze przy użyciu następujących netsh poleceń:

  • netsh int ipv4 show dynamicport tcp
    
  • netsh int ipv4 show dynamicport udp
    
  • netsh int ipv6 show dynamicport tcp
    
  • netsh int ipv6 show dynamicport udp
    

Zakres jest ustawiany oddzielnie dla każdego transportu (TCP lub UDP). Zakres portów jest teraz zakresem, który ma punkt początkowy i punkt końcowy. Klienci firmy Microsoft, którzy wdrażają serwery z systemem Windows Server, mogą mieć problemy wpływające na komunikację RPC między serwerami, jeśli zapory są używane w sieci wewnętrznej. W takich sytuacjach zalecamy ponowne skonfigurowanie zapór w celu zezwolenia na ruch między serwerami w zakresie portów dynamicznych od 49152 do 65535. Ten zakres jest dodatkiem do dobrze znanych portów używanych przez usługi i aplikacje. Można również zmodyfikować zakres portów używany przez serwery na każdym serwerze. Ten zakres można dostosować za pomocą polecenia netsh w następujący sposób. Powyższe polecenie ustawia zakres portów dynamicznych dla protokołu TCP.

netsh int <ipv4|ipv6> set dynamic <tcp|udp> start=number num=range

Port początkowy to liczba, a całkowita liczba portów to zakres. Poniżej przedstawiono przykładowe polecenia:

  • netsh int ipv4 set dynamicport tcp start=10000 num=1000
    
  • netsh int ipv4 set dynamicport udp start=10000 num=1000
    
  • netsh int ipv6 set dynamicport tcp start=10000 num=1000
    
  • netsh int ipv6 set dynamicport udp start=10000 num=1000
    

Te przykładowe polecenia ustawiają zakres portów dynamicznych tak, aby rozpoczynał się od portu 10000 i kończył się na porcie 10999 (1000 portów). Minimalny zakres portów, które można ustawić, wynosi 255. Minimalny port początkowy, który można ustawić, to 1025. Maksymalny port końcowy (na podstawie skonfigurowanego zakresu) nie może przekraczać 65535. Aby zduplikować domyślne zachowanie systemu Windows Server 2003, użyj portu 1025 jako portu początkowego, a następnie użyj wartości 3976 jako zakresu dla protokołu TCP i UDP. Ten wzorzec użycia powoduje uruchomienie portu 1025 i portu końcowego 5000.

W szczególności informacje o połączeniach wychodzących jako połączeniach przychodzących nie będą wymagały portu efemerycznego do akceptowania połączeń.

Ponieważ połączenia wychodzące zaczynają kończyć się niepowodzeniem, zobaczysz wiele wystąpień poniższych zachowań:

  • Nie można zalogować się do komputera przy użyciu poświadczeń domeny, ale logowanie przy użyciu konta lokalnego działa. Logowanie do domeny wymaga skontaktowania się z kontrolerem domeny w celu uwierzytelnienia, które jest ponownie połączeniem wychodzącym. Jeśli masz ustawione poświadczenia pamięci podręcznej, logowanie do domeny może nadal działać.

    Zrzut ekranu przedstawiający błąd netlogonu w Podgląd zdarzeń.

  • błędy aktualizacji zasady grupy:

    Zrzut ekranu przedstawiający właściwości zdarzenia w przypadku niepowodzenia zasady grupy.

  • Udziały plików są niedostępne:

    Zrzut ekranu przedstawiający komunikat o błędzie Nie można uzyskać dostępu do systemu Windows.

  • Protokół RDP z serwera, którego dotyczy problem, kończy się niepowodzeniem:

    Zrzut ekranu przedstawiający błąd, gdy pulpit zdalny nie może nawiązać połączenia.

  • Każda inna aplikacja uruchomiona na maszynie zacznie dawać błędy

Ponowne uruchomienie serwera spowoduje tymczasowe rozwiązanie problemu, ale wszystkie objawy wrócą po upływie określonego czasu.

Jeśli podejrzewasz, że maszyna jest w stanie wyczerpania portów:

  1. Spróbuj nawiązać połączenie wychodzące. Z serwera/maszyny uzyskaj dostęp do udziału zdalnego lub spróbuj nawiązać połączenie RDP z innym serwerem lub telnetem do serwera na porcie. Jeśli połączenie wychodzące nie powiedzie się dla wszystkich tych opcji, przejdź do następnego kroku.

  2. Otwórz przeglądarkę zdarzeń i w dziennikach systemowych poszukaj zdarzeń, które wyraźnie wskazują bieżący stan:

    1. Identyfikator zdarzenia 4227

      Zrzut ekranu przedstawiający identyfikator zdarzenia 4227 w Podgląd zdarzeń.

    2. Identyfikator zdarzenia 4231

      Zrzut ekranu przedstawiający identyfikator zdarzenia 4231 w Podgląd zdarzeń.

  3. Zbierz dane wyjściowe netstat -anob z serwera. Dane wyjściowe netstat pokażą ogromną liczbę wpisów dla stanu TIME_WAIT dla pojedynczego identyfikatora PID.

    Zrzut ekranu przedstawiający dane wyjściowe polecenia netstate.

    Po bezproblemowym zamknięciu lub nagłym zamknięciu sesji po upływie 4 minut (domyślnie) port używany przez proces lub aplikację zostanie zwolniony z powrotem do dostępnej puli. W ciągu tych 4 minut stan połączenia TCP będzie TIME_WAIT. W sytuacji, gdy podejrzewasz wyczerpanie portów, aplikacja lub proces nie będzie mógł zwolnić wszystkich portów, które zostały użyte i pozostaną w stanie TIME_WAIT.

    Połączenia CLOSE_WAIT stanu mogą być również widoczne w tych samych danych wyjściowych. jednak stan CLOSE_WAIT jest stanem, gdy jedna strona elementu równorzędnego TCP nie ma więcej danych do wysłania (wysłane przez fin), ale może odbierać dane z drugiego końca. Ten stan nie musi wskazywać wyczerpania portów.

    Uwaga

    Posiadanie ogromnych połączeń w stanie TIME_WAIT nie zawsze wskazuje, że serwer jest obecnie poza portami, chyba że zostaną zweryfikowane pierwsze dwa punkty. Posiadanie wielu połączeń TIME_WAIT wskazuje, że proces tworzy wiele połączeń TCP i może ostatecznie prowadzić do wyczerpania portów.

    Usługa Netstat została zaktualizowana w Windows 10 z dodatkiem -Q przełącznika, aby wyświetlić porty, które przesunęły się poza czas oczekiwania, jak w stanie BOUND. Wydano aktualizację dla Windows 8.1 i Windows Server 2012 R2, która zawiera tę funkcję. Polecenie cmdlet Get-NetTCPConnection programu PowerShell w Windows 10 również pokazuje te porty BOUND.

    Do 10/2016 r. netstat był niedokładny. Poprawki dla parametru netstat z powrotem do wersji 2012 R2, dozwolone Netstat.exe i Get-NetTcpConnection prawidłowego raportowania użycia portów TCP lub UDP w Windows Server 2012 R2. Zobacz Windows Server 2012 R2: Poprawki portów efemeryczne, aby dowiedzieć się więcej.

  4. Otwórz wiersz polecenia w trybie administratora i uruchom poniższe polecenie.

    Netsh trace start scenario=netconnection capture=yes tracefile=c:\Server.etl
    
  5. Otwórz plik server.etl przy użyciu monitora sieci i w sekcji filtru zastosuj filtr Wscore_MicrosoftWindowsWinsockAFD.AFD_EVENT_BIND.Status.LENTStatus.Code == 0x209. Powinny zostać wyświetlone wpisy z STATUS_TOO_MANY_ADDRESSES. Jeśli nie znajdziesz żadnych wpisów, serwer nadal nie jest poza portami. Jeśli je znajdziesz, możesz potwierdzić, że serwer znajduje się w wyczerpaniu portów.

Rozwiązywanie problemów z wyczerpaniem portów

Kluczem jest określenie, który proces lub aplikacja używa wszystkich portów. Poniżej przedstawiono niektóre narzędzia, których można użyć do izolowania jednego procesu

Metoda 1

Zacznij od przyjrzenia się danym wyjściowym netstat. Jeśli używasz Windows 10 lub Windows Server 2016, możesz uruchomić polecenie netstat -anobq i sprawdzić identyfikator procesu, który ma maksymalną liczbę wpisów jako POWIĄZANIE. Alternatywnie możesz również uruchomić poniższe polecenie programu PowerShell, aby zidentyfikować proces:

Get-NetTCPConnection | Group-Object -Property State, OwningProcess | Select -Property Count, Name, @{Name="ProcessName";Expression={(Get-Process -PID ($_.Name.Split(',')[-1].Trim(' '))).Name}}, Group | Sort Count -Descending 

Większość przecieków portów jest spowodowana tym, że procesy trybu użytkownika nie zamykają poprawnie portów po wystąpieniu błędu. Na poziomie trybu użytkownika porty (w rzeczywistości gniazda) są dojściami. Zarówno TaskManager , jak i ProcessExplorer mogą wyświetlać liczbę dojść, co pozwala określić, który proces zużywa wszystkie porty.

W systemach Windows 7 i Windows Server 2008 R2 można zaktualizować wersję programu PowerShell w celu uwzględnienia powyższego polecenia cmdlet.

Metoda 2

Jeśli metoda 1 nie ułatwia zidentyfikowania procesu (przed Windows 10 i Windows Server 2012 R2), zapoznaj się z Menedżerem zadań:

  1. Dodaj kolumnę o nazwie "handles" w obszarze szczegóły/procesy.

  2. Posortuj uchwyty kolumn, aby zidentyfikować proces z największą liczbą dojść. Zazwyczaj proces z uchwytami większymi niż 3000 może być przyczyną, z wyjątkiem procesów takich jak System, lsass.exe, store.exe, sqlsvr.exe.

    Zrzut ekranu przedstawiający kolumnę uchwytów w Menedżerze zadań systemu Windows.

  3. Jeśli jakikolwiek inny proces niż te procesy ma większą liczbę, zatrzymaj ten proces, a następnie spróbuj zalogować się przy użyciu poświadczeń domeny i sprawdź, czy się powiedzie.

Metoda 3

Jeśli Menedżer zadań nie pomoże Ci zidentyfikować procesu, użyj Eksploratora procesów, aby zbadać problem.

Kroki korzystania z Eksploratora procesów:

  1. Pobierz Eksploratora procesów i uruchom go z podwyższonym poziomem uprawnień.

  2. Alt + wybierz nagłówek kolumny, wybierz pozycję Wybierz kolumny, a następnie na karcie Wydajność procesu dodaj pozycję Liczba dojść.

  3. Wybierz pozycję Wyświetl>pokaż dolne okienko.

  4. Wybierz pozycję Wyświetl>dojścia widoku>dolnego okienka.

  5. Wybierz kolumnę Uchwyty, aby posortować według tej wartości.

  6. Sprawdź procesy z większą liczbą dojść niż pozostałe (prawdopodobnie będzie to ponad 10 000, jeśli nie możesz nawiązać połączeń wychodzących).

  7. Kliknij, aby wyróżnić jeden z procesów z wysoką liczbą dojść.

  8. W dolnym okienku uchwyty wymienione poniżej są gniazdami. (Gniazda są technicznie dojściami do plików).

    Plik \Urządzenie\AFD

    Zrzut ekranu Eksploratora procesów z procesami posortowanymi według dojść.

  9. Niektóre z nich są normalne, ale duża ich liczba nie jest (setki do tysięcy). Zamknij dany proces. Jeśli spowoduje to przywrócenie łączności wychodzącej, zostanie jeszcze bardziej udowodnione, że przyczyną jest aplikacja. Skontaktuj się z dostawcą tej aplikacji.

Na koniec, jeśli powyższe metody nie ułatwią wyizolowania procesu, sugerujemy zebranie kompletnego zrzutu pamięci maszyny w stanie problemu. Zrzut informuje o tym, który proces ma maksymalną liczbę dojść.

Aby obejść ten problem, ponowne uruchomienie komputera spowoduje przywrócenie go w normalnym stanie i pomoże rozwiązać problem na razie. Jeśli jednak ponowny rozruch jest niepraktyczny, można również rozważyć zwiększenie liczby portów na maszynie przy użyciu poniższych poleceń:

netsh int ipv4 set dynamicport tcp start=10000 num=1000

To polecenie ustawi zakres portów dynamicznych tak, aby rozpoczynał się od portu 10000 i kończył się na porcie 10999 (1000 portów). Minimalny zakres portów, które można ustawić, wynosi 255. Minimalny port początkowy, który można ustawić, to 1025. Maksymalny port końcowy (na podstawie skonfigurowanego zakresu) nie może przekraczać 65535.

Uwaga

Należy pamiętać, że zwiększenie zakresu portów dynamicznych nie jest trwałym rozwiązaniem, ale tylko tymczasowym. Należy śledzić, które procesy/procesory zużywają maksymalną liczbę portów, i rozwiązać problemy z tego punktu widzenia procesu, dlaczego zużywają tak dużą liczbę portów.

W systemach Windows 7 i Windows Server 2008 R2 można użyć poniższego skryptu, aby zebrać dane wyjściowe netstat z zdefiniowaną częstotliwością. W danych wyjściowych można zobaczyć trend użycia portów.

@ECHO ON
set v=%1
:loop
set /a v+=1
ECHO %date% %time% >> netstat.txt
netstat -ano >> netstat.txt
 
PING 1.1.1.1 -n 1 -w 60000 >NUL
 
goto loop

Więcej informacji

  • Wyczerpanie portów i Ty! - ten artykuł zawiera szczegółowe informacje na temat stanów netstat i sposobu użycia danych wyjściowych netstat w celu określenia stanu portu
  • Wykrywanie wyczerpania efemerycznego portu: ten artykuł zawiera skrypt, który będzie uruchamiany w pętli w celu raportowania stanu portu. (Dotyczy systemu Windows 2012 R2, Windows 8, Windows 10 i Windows 11)