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 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 działa na porcie 445, protokół HTTPS na porcie 443, protokół HTTP na porcie 80, a protokół RPC na porcie 135. Aplikacje niestandardowe będą również miały własne zdefiniowane numery portów.
Po nawiązaniu połączenia 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 nawiązywania połączenia https://www.microsoft.com
z portem 443.
W scenariuszu, w którym ta sama przeglądarka tworzy wiele połączeń z wieloma witrynami sieci Web, w przypadku każdego nowego połączenia, które próbuje przeglądarka, jest używany port efemeryczny. Po pewnym czasie zauważysz, że połączenia zaczną się wieść, a jedną z wysokich możliwości dla tego błędu byłoby 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 używane są wszystkie porty na maszynie, określamy je jako wyczerpanie 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 dynamiczny zakres portów klienta dla połączeń wychodzących. Nowy domyślny port startowy to 49152, a nowy domyślny port końcowy to 65535. Ten wzrost jest zmianą 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 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, aby zezwolić na ruch między serwerami w zakresie portów dynamicznych od 49152 do 65535. Ten zakres jest dodatkiem do dobrze znanych portów, które są używane przez usługi i aplikacje. Można też zmodyfikować zakres portów używany przez serwery na każdym serwerze. Ten zakres można dostosować przy użyciu 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 łączna 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 na początek na porcie 10000 i na końcu na porcie 10999 (1000 portów). Minimalny zakres portów, jaki można ustawić, to 255. Minimalny port startowy, 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 1025 jako portu początkowego, a następnie użyj 3976 jako zakresu zarówno tcp, jak 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łączenia przychodzące nie będą wymagały portu efemerycznego do akceptowania połączeń.
Ponieważ połączenia wychodzące zaczynają prowadzić do awarii, zobaczysz wiele wystąpień poniższych zachowań:
Nie można zalogować się do maszyny przy użyciu poświadczeń domeny, jednak działa logowanie przy użyciu konta lokalnego. Logowanie do domeny wymaga skontaktowania się z kontrolerem domeny w celu uwierzytelnienia, co jest ponownie połączeniem wychodzącym. Jeśli ustawiono poświadczenia pamięci podręcznej, logowanie do domeny może nadal działać.
Niepowodzenia aktualizacji zasad grupy:
Udziały plików są niedostępne:
Błąd protokołu RDP z serwera, którego dotyczy problem:
Każda inna aplikacja uruchomiona na maszynie zacznie rozdać błędy
Ponowne uruchomienie serwera spowoduje tymczasowe rozwiązanie problemu, ale wszystkie objawy zostaną przywrócone po upływie czasu.
Jeśli podejrzewasz, że maszyna jest w stanie wyczerpania portów:
Spróbuj nawiązać połączenie wychodzące. Z serwera/maszyny uzyskaj dostęp do udziału zdalnego lub spróbuj użyć protokołu RDP na innym serwerze lub telnet na serwerze na porcie. Jeśli połączenie wychodzące zakończy się niepowodzeniem dla wszystkich tych opcji, przejdź do następnego kroku.
Otwórz podgląd zdarzeń i w dziennikach systemowych wyszukaj zdarzenia, które wyraźnie wskazują bieżący stan:
Identyfikator zdarzenia 4227
Identyfikator zdarzenia 4231
netstat -anob
Zbierz dane wyjściowe z serwera. Dane wyjściowe netstat pokażą ogromną liczbę wpisów dla stanu TIME_WAIT dla pojedynczego identyfikatora PID.Po bezproblemowym zamknięciu lub nagłemu 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 połączenie TCP będzie mieć stan TIME_WAIT. W sytuacji, w której podejrzewasz wyczerpanie portów, aplikacja lub proces nie będzie mógł zwolnić wszystkich używanych portów i pozostanie w stanie TIME_WAIT.
W tych samych danych wyjściowych mogą być również widoczne połączenia stanu CLOSE_WAIT; jednak stan CLOSE_WAIT jest stanem, gdy jedna strona elementu równorzędnego TCP nie ma więcej danych do wysłania (wysłane fin), ale może odbierać dane z drugiego końca. Ten stan nie musi wskazywać na wyczerpanie portów.
Uwaga 16.
Posiadanie ogromnych połączeń w stanie TIME_WAIT nie zawsze oznacza, że serwer jest obecnie poza portami, chyba że dwa pierwsze punkty zostaną zweryfikowane. Duża liczba połączeń TIME_WAIT wskazuje, że proces tworzy wiele połączeń TCP i może ostatecznie prowadzić do wyczerpania portów.
Funkcja Netstat została zaktualizowana w systemie Windows 10 z dodatkiem przełącznika
-Q
w celu wyświetlania portów, które przekroczyły czas oczekiwania, jak w stanie BOUND. Wydano aktualizację dla systemu Windows 8.1 i Windows Server 2012 R2, która zawiera tę funkcję. Polecenie cmdletGet-NetTCPConnection
programu PowerShell w systemie Windows 10 pokazuje również te porty BOUND.Do października 2016 r. dane polecenia netstat były niedokładne. Poprawki dla netstat, back-ported do 2012 R2, dozwolone Netstat.exe i
Get-NetTcpConnection
poprawne raportowanie użycia portów TCP lub UDP w systemie Windows Server 2012 R2. Zobacz Windows Server 2012 R2: poprawki portów efemerycznych, aby dowiedzieć się więcej.Otwórz wiersz polecenia w trybie administratora i uruchom poniższe polecenie.
Netsh trace start scenario=netconnection capture=yes tracefile=c:\Server.etl
Otwórz plik server.etl z monitorem sieci i w sekcji filtru zastosuj filtr
Wscore_MicrosoftWindowsWinsockAFD.AFD_EVENT_BIND.Status.LENTStatus.Code == 0x209
. Powinny zostać wyświetlone wpisy, które mówią STATUS_TOO_MANY_ADDRESSES. Jeśli nie znajdziesz żadnych wpisów, serwer nadal nie znajduje się poza portami. Jeśli je znajdziesz, możesz potwierdzić, że serwer jest w stanie wyczerpania portów.
Rozwiązywanie problemów z wyczerpaniem portów
Kluczem jest zidentyfikowanie, który proces lub która aplikacja zużywa wszystkie porty. Poniżej przedstawiono niektóre narzędzia, których można użyć do wyizolowania tego jednego procesu
Metoda 1
Zacznij od przejrzenia danych wyjściowych polecenia netstat. Jeśli używasz systemu Windows 10 lub Windows Server 2016, możesz uruchomić polecenie netstat -anobq
i sprawdzić identyfikator procesu, który ma maksymalne wpisy jako BOUND. 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ść wycieków portów jest powodowana przez procesy w trybie użytkownika, które nie zamykają poprawnie portów po napotkaniu błędu. Na poziomie trybu użytkownika porty (faktycznie gniazda) są obsługiwane. Zarówno TaskManager , jak i ProcessExplorer mogą wyświetlać liczby 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, aby uwzględnić powyższe polecenie cmdlet.
Metoda 2
Jeśli metoda 1 nie pomaga zidentyfikować procesu (przed systemami Windows 10 i Windows Server 2012 R2), zapoznaj się z Menedżerem zadań:
Dodaj kolumnę o nazwie "handles" w obszarze szczegółów/procesów.
Posortuj uchwyty w kolumnie, aby zidentyfikować proces z największą liczbą uchwytów. Zazwyczaj proces z uchwytami większymi niż 3000 może być winowajcą z wyjątkiem procesów takich jak System, lsass.exe, store.exe, sqlsvr.exe.
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 sprawdzić, czy się powiedzie.
Metoda 3
Jeśli Menedżer zadań nie pomógł zidentyfikować procesu, użyj Eksploratora procesów, aby zbadać problem.
Procedura korzystania z Eksploratora procesów:
Pobierz Eksploratora procesów i uruchom go z podwyższonym poziomem uprawnień.
Alt + wybierz nagłówek kolumny, wybierz pozycję Wybierz kolumny, a następnie na karcie Wydajność procesu dodaj liczbę dojść.
Wybierz pozycję Widok Pokaż>dolne okienko.
Wybierz pozycję Wyświetl>dolne uchwyty widoku>okienka.
Wybierz kolumnę Handles (Dojścia), aby sortować według tej wartości.
Sprawdź procesy z większą liczbą uchwytów niż pozostałe (jeśli nie możesz nawiązać połączeń wychodzących, prawdopodobnie będzie ona przekraczać 10 000).
Kliknij, aby wyróżnić jeden z procesów z dużą liczbą uchwytów.
W dolnym okienku uchwyty wymienione jak poniżej są gniazdami. (Gniazda są z technicznego punktu widzenia uchwytami plików).
Plik \Device\AFD
Niektóre są normalne, ale duża ich liczba nie jest (setki do tysięcy). Zamknij ten proces. Jeśli spowoduje to przywrócenie łączności wychodzącej, dodatkowo sprawdzono, że aplikacja jest przyczyną. Skontaktuj się z dostawcą tej aplikacji.
Jeśli powyższe metody nie pomogły wyizolować procesu, sugerujemy zebranie pełnego zrzutu pamięci maszyny w stanie problemu. Zrzut pokaże, który proces ma największą liczbę uchwytów.
Aby obejść ten problem, ponowne uruchomienie komputera spowoduje powrót do normalnego stanu i pomoże ci rozwiązać ten problem przez pewien czas. Jeśli jednak ponowne uruchomienie jest niepraktyczne, 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 spowoduje ustawienie zakresu portów dynamicznych na początek na porcie 10000 i na końcu na porcie 10999 (1000 portów). Minimalny zakres portów, jaki można ustawić, to 255. Minimalny port startowy, który można ustawić, to 1025. Maksymalny port końcowy (na podstawie skonfigurowanego zakresu) nie może przekraczać 65535.
Uwaga 16.
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ązywać problemy z punktu widzenia tego procesu, dlaczego zużywa tak dużą liczbę portów.
W przypadku systemów Windows 7 i Windows Server 2008 R2 można użyć poniższego skryptu, aby zebrać dane wyjściowe netstat ze zdefiniowaną częstotliwością. W danych wyjściowych widać 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 portów efemerycznych: ten artykuł zawiera skrypt, który będzie uruchamiany w pętli w celu raportowania stanu portu. (Dotyczy systemów Windows 2012 R2, Windows 8, Windows 10 i Windows 11)