Udostępnij za pośrednictwem

Rozwiązywanie problemów z łącznością z usługą Azure NAT Gateway

  • Artykuł

Ten artykuł zawiera wskazówki dotyczące rozwiązywania typowych problemów z łącznością wychodzącą z bramą translatora adresów sieciowych. Ten artykuł zawiera również najlepsze rozwiązania dotyczące wydajnego projektowania aplikacji do korzystania z połączeń wychodzących.

Spadek dostępności ścieżki danych w bramie translatora adresów sieciowych z błędami połączenia

Scenariusz

Obserwujesz spadek dostępności ścieżki danych bramy translatora adresów sieciowych, który zbiega się z błędami połączenia.

Możliwe przyczyny

  • Wyczerpanie portów translacji adresów sieciowych (SNAT).

  • Jednoczesne limity połączeń SNAT.

  • Przekroczenia limitu czasu połączenia.

Kroki rozwiązywania problemów

  • Oceń kondycję bramy translatora adresów sieciowych, sprawdzając metrykę dostępności ścieżki danych.

  • Sprawdź metryę Liczba połączeń SNAT i podziel stan połączenia, próbując podjąć próbę i niepowodzenie połączeń. Więcej niż zero nieudanych połączeń wskazuje wyczerpanie portów SNAT lub osiągnięcie limitu liczby połączeń SNAT bramy translatora adresów sieciowych.

  • Upewnij się, że metryka liczba połączeń znajduje się w granicach, sprawdzając metryki Łączna liczba połączeń SNAT. Brama translatora adresów sieciowych obsługuje 50 000 równoczesnych połączeń na adres IP do unikatowego miejsca docelowego i łącznie do 2 milionów połączeń. Aby uzyskać więcej informacji, zobacz Wydajność bramy translatora adresów sieciowych.

  • Sprawdź metryki porzuconych pakietów pod kątem porzucanych pakietów, które są zgodne z błędami połączenia lub dużym woluminem połączenia.

  • Dostosuj ustawienia czasomierza limitu czasu bezczynności protokołu Transmission Control Protocol (TCP) zgodnie z potrzebami. Czasomierz limitu czasu bezczynności ustawiony wyżej niż wartość domyślna (4 minuty) jest przechowywany w przepływach dłużej i może spowodować dodatkową presję na spis portów SNAT.

Możliwe rozwiązania dotyczące wyczerpania portów SNAT lub osiągnięcia równoczesnych limitów połączeń

  • Dodaj publiczne adresy IP do bramy translatora adresów sieciowych do łącznej liczby 16, aby skalować łączność wychodzącą. Każdy publiczny adres IP zapewnia 64 512 portów SNAT i obsługuje maksymalnie 50 000 jednoczesnych połączeń na unikatowy docelowy punkt końcowy bramy translatora adresów sieciowych.

  • Dystrybuuj środowisko aplikacji w wielu podsieciach i podaj zasób bramy translatora adresów sieciowych dla każdej podsieci.

  • Zwolnij spis portów SNAT, zmniejszając limit czasu bezczynności protokołu TCP do niższej wartości. Czasomierz limitu czasu bezczynności protokołu TCP nie może być ustawiony niż 4 minuty.

  • Rozważ asynchroniczne wzorce sondowania, aby zwolnić zasoby połączenia dla innych operacji.

  • Nawiązywanie połączeń z usługami PaaS platformy Azure za pośrednictwem sieci szkieletowej platformy Azure przy użyciu usługi Private Link. Usługa Private Link zwalnia porty SNAT dla połączeń wychodzących z Internetem.

  • Jeśli badanie jest niejednoznaczne, otwórz zgłoszenie do pomocy technicznej, aby kontynuować rozwiązywanie problemów.

Uwaga

Ważne jest, aby zrozumieć, dlaczego występuje wyczerpanie portów SNAT. Upewnij się, że używasz odpowiednich wzorców dla skalowalnych i niezawodnych scenariuszy. Dodanie kolejnych portów SNAT do scenariusza bez zrozumienia przyczyny zapotrzebowania powinno być ostatecznością. Jeśli nie rozumiesz, dlaczego twój scenariusz wywiera presję na spis portów SNAT, dodanie większej liczby portów SNAT przez dodanie większej liczby adresów IP spowoduje opóźnienie tylko tego samego błędu wyczerpania co skalowanie aplikacji. Możesz maskować inne nieefektywne i anty-wzorce. Aby uzyskać więcej informacji, zobacz najlepsze rozwiązania dotyczące efektywnego korzystania z połączeń wychodzących.

Możliwe rozwiązania dotyczące przekroczenia limitu czasu połączenia TCP

Użyj parametrów keepalives protokołu TCP lub utrzymywania warstwy aplikacji, aby odświeżyć przepływy bezczynności i zresetować czasomierz limitu czasu bezczynności. Przykłady można znaleźć na stronie Przykłady platformy .NET.

Elementy utrzymania tcp muszą być włączone tylko z jednej strony połączenia, aby zachować połączenie aktywne po obu stronach. Po wysłaniu utrzymywania aktywności TCP z jednej strony połączenia druga strona automatycznie wysyła pakiet potwierdzenia (ACK). Czasomierz limitu czasu bezczynności jest następnie resetowany po obu stronach połączenia.

Uwaga

Zwiększenie limitu czasu bezczynności protokołu TCP jest ostatecznością i może nie rozwiązać głównej przyczyny problemu. Długi limit czasu może spowodować opóźnienie i spowodować niepotrzebne błędy o niskim tempie po wygaśnięciu limitu czasu.

Możliwe rozwiązania dotyczące przekroczenia limitu czasu połączenia protokołu UDP (User Datagram Protocol)

Czasomierze limitu czasu bezczynności protokołu UDP są ustawione na 4 minuty i nie można ich konfigurować. Włącz elementy utrzymania protokołu UDP dla obu kierunków w przepływie połączenia, aby obsługiwać długie połączenia. Po włączeniu utrzymania protokołu UDP jest ono aktywne tylko dla jednego kierunku w połączeniu. Połączenie może nadal przechodzić bezczynnie i przekroczono limit czasu po drugiej stronie połączenia. Aby zapobiec przekroczeniu limitu czasu bezczynności połączenia UDP, należy włączyć dla obu kierunków w przepływie połączenia.

Stosy warstw aplikacji mogą również służyć do odświeżania przepływów bezczynności i resetowania limitu czasu bezczynności. Sprawdź stronę serwera, aby dowiedzieć się, jakie opcje istnieją dla określonych keepalives aplikacji.

Spadek dostępności ścieżki danych w bramie translatora adresów sieciowych, ale brak błędów połączenia

Scenariusz

Dostępność bramy translatora adresów sieciowych przez ścieżkę danych spada, ale nie zaobserwowano żadnych nieudanych połączeń.

Możliwa przyczyna

Przejściowy spadek dostępności ścieżki danych spowodowany szumem w ścieżce danych.

Kroki rozwiązywania problemów

Jeśli zauważysz spadek dostępności ścieżki danych bez żadnego wpływu na łączność wychodzącą, może to być spowodowane przez bramę translatora adresów sieciowych odbieranie przejściowych szumów w ścieżce danych.

Skonfiguruj alert dotyczący spadku dostępności ścieżki danych lub użyj usługi Azure Resource Health , aby otrzymywać alerty dotyczące zdarzeń kondycji bramy translatora adresów sieciowych.

Brak połączeń wychodzących z Internetem

Scenariusz

Nie obserwujesz łączności wychodzącej w bramie translatora adresów sieciowych.

Możliwe przyczyny

  • Błędna konfiguracja bramy translatora adresów sieciowych.

  • Ruch internetowy jest przekierowywany z bramy translatora adresów sieciowych i wymuszany tunelowany do urządzenia wirtualnego lub do miejsca docelowego lokalnego z siecią VPN lub usługą ExpressRoute.

  • Reguły sieciowej grupy zabezpieczeń (NSG) są skonfigurowane, które blokują ruch internetowy.

  • Dostępność ścieżki danych bramy translatora adresów sieciowych jest obniżona.

  • Błędna konfiguracja systemu nazw domen (DNS).

Kroki rozwiązywania problemów

  • Sprawdź, czy brama translatora adresów sieciowych jest skonfigurowana z co najmniej jednym publicznym adresem IP lub prefiksem i dołączona do podsieci. Usługa NAT Gateway nie działa, dopóki nie zostaną dołączone publiczny adres IP i podsieć. Aby uzyskać więcej informacji, zobacz Podstawowe informacje o konfiguracji usługi NAT Gateway.

  • Sprawdź tabelę routingu podsieci dołączonej do bramy translatora adresów sieciowych. Każdy ruch 0.0.0.0/0 wymuszony na wirtualnym urządzeniu sieciowym (WUS), usłudze ExpressRoute lub bramie sieci VPN będzie mieć priorytet nad bramą translatora adresów sieciowych. Aby uzyskać więcej informacji, zobacz , jak platforma Azure wybiera trasę.

  • Sprawdź, czy na maszynie wirtualnej skonfigurowano jakiekolwiek reguły sieciowej grupy zabezpieczeń, które blokują dostęp do Internetu.

  • Sprawdź, czy dostępność ścieżki danych bramy translatora adresów sieciowych jest w stanie obniżonej wydajności. Zapoznaj się ze wskazówkami dotyczącymi rozwiązywania problemów z błędami połączenia, jeśli brama translatora adresów sieciowych jest w stanie obniżonej wydajności.

  • Sprawdź ustawienia DNS, jeśli system DNS nie jest prawidłowo rozpoznawany.

Możliwe rozwiązania dotyczące utraty łączności wychodzącej

Publiczny adres IP bramy translatora adresów sieciowych nie jest używany do nawiązywania połączenia wychodzącego

Scenariusz

Brama translatora adresów sieciowych jest wdrażana w sieci wirtualnej platformy Azure, ale nieoczekiwane adresy IP są używane na potrzeby połączeń wychodzących.

Możliwe przyczyny

  • Błędna konfiguracja bramy translatora adresów sieciowych.

  • Aktywne połączenie z inną metodą łączności wychodzącej platformy Azure, taką jak usługa Azure Load Balancer lub publiczne adresy IP na poziomie wystąpienia na maszynach wirtualnych. Aktywne przepływy połączeń nadal używają poprzedniego publicznego adresu IP przypisanego podczas nawiązywania połączenia. Po wdrożeniu bramy translatora adresów sieciowych nowe połączenia zaczynają od razu korzystać z bramy translatora adresów sieciowych.

  • Prywatne adresy IP są używane do łączenia się z usługami platformy Azure za pomocą punktów końcowych usługi lub usługi Private Link.

  • Połączenia z kontami magazynu pochodzą z tego samego regionu co maszyna wirtualna, z której jest nawiązane połączenie.

  • Ruch internetowy jest przekierowywany z bramy translatora adresów sieciowych i wymuszany tunelowany do urządzenia WUS lub zapory.

Jak rozwiązywać problemy

  • Sprawdź, czy brama translatora adresów sieciowych ma co najmniej jeden publiczny adres IP lub prefiks skojarzony i co najmniej jedną podsieć.

  • Sprawdź, czy jakakolwiek poprzednia metoda łączności wychodzącej, taka jak publiczny moduł równoważenia obciążenia, jest nadal aktywna po wdrożeniu bramy translatora adresów sieciowych.

  • Sprawdź, czy połączenia z innymi usługami platformy Azure pochodzą z prywatnego adresu IP w sieci wirtualnej platformy Azure.

  • Sprawdź, czy masz włączoną usługę Private Link lub punkty końcowe usługi na potrzeby nawiązywania połączenia z innymi usługami platformy Azure.

  • Upewnij się, że maszyna wirtualna znajduje się w tym samym regionie co usługa Azure Storage podczas nawiązywania połączenia magazynu.

  • Sprawdź, czy publiczny adres IP używany na potrzeby połączeń pochodzi z innej usługi platformy Azure w sieci wirtualnej platformy Azure, takiej jak wirtualne urządzenie sieciowe (WUS).

Możliwe rozwiązania dla publicznego adresu IP bramy translatora adresów sieciowych, które nie są używane do nawiązywania połączenia wychodzącego

  • Dołącz publiczny adres IP lub prefiks do bramy translatora adresów sieciowych. Upewnij się, że brama translatora adresów sieciowych jest dołączona do podsieci z tej samej sieci wirtualnej. Sprawdź, czy brama translatora adresów sieciowych może nawiązać połączenie wychodzące.

  • Przetestuj i rozwiąż problemy z maszynami wirtualnymi trzymającymi stare adresy IP SNAT z innej metody łączności wychodzącej przez:

    • Upewnij się, że nawiązano nowe połączenie i że istniejące połączenia nie są ponownie używane w systemie operacyjnym lub że przeglądarka buforuje połączenia. Na przykład w przypadku korzystania z narzędzia curl w programie PowerShell upewnij się, że określono parametr -DisableKeepalive, aby wymusić nowe połączenie. Jeśli używasz przeglądarki, połączenia mogą być również w puli.

    • Nie jest konieczne ponowne uruchomienie maszyny wirtualnej w podsieci skonfigurowanej do bramy translatora adresów sieciowych. Jeśli jednak maszyna wirtualna zostanie ponownie uruchomiona, stan połączenia zostanie opróżniony. Po opróżnieniu stanu połączenia wszystkie połączenia zaczynają korzystać z adresu IP lub adresów zasobu bramy translatora adresów sieciowych. To zachowanie jest efektem ubocznym ponownego uruchomienia maszyny wirtualnej, a nie wskaźnikiem, że wymagany jest ponowny rozruch.

    • Jeśli badanie jest niejednoznaczne, otwórz zgłoszenie do pomocy technicznej, aby kontynuować rozwiązywanie problemów.

  • Trasy niestandardowe kierujące ruch 0.0.0.0/0 do urządzenia WUS będą miały pierwszeństwo przed bramą translatora adresów sieciowych na potrzeby routingu ruchu do Internetu. Aby brama translatora adresów sieciowych kierowała ruch do Internetu zamiast urządzenia WUS, usuń trasę niestandardową dla ruchu 0.0.0.0/0 przechodzącego do urządzenia wirtualnego. Ruch 0.0.0.0.0/0 jest wznawiany przy użyciu domyślnej trasy do Internetu i bramy translatora adresów sieciowych.

Ważne

Przed wprowadzeniem jakichkolwiek zmian w sposobie kierowania ruchu należy dokładnie rozważyć wymagania dotyczące routingu architektury chmury.

  • Usługi wdrożone w tym samym regionie co konto usługi Azure Storage używają prywatnych adresów IP platformy Azure do komunikacji. Nie można ograniczyć dostępu do określonych usług platformy Azure na podstawie ich publicznego zakresu wychodzących adresów IP. Aby uzyskać więcej informacji, zobacz ograniczenia dotyczące reguł sieci ip.
  • Punkty końcowe usługi Private Link i usługi używają prywatnych adresów IP wystąpień maszyn wirtualnych w sieci wirtualnej do łączenia się z usługami platformy Azure zamiast publicznego adresu IP bramy translatora adresów sieciowych. Użyj usługi Private Link, aby nawiązać połączenie z innymi usługami platformy Azure za pośrednictwem sieci szkieletowej platformy Azure zamiast przez Internet z bramą translatora adresów sieciowych.

Uwaga

Usługa Private Link jest zalecaną opcją dla punktów końcowych usługi w celu uzyskania prywatnego dostępu do usług hostowanych na platformie Azure.

Błędy połączeń w publicznym miejscu docelowym Internetu

Scenariusz

Połączenia bramy translatora adresów sieciowych z miejscami docelowymi w Internecie kończą się niepowodzeniem lub przekroczeniem limitu czasu.

Możliwe przyczyny

  • Zapora lub inne składniki zarządzania ruchem w miejscu docelowym.

  • Ograniczanie szybkości interfejsu API nałożone przez stronę docelową.

  • Ograniczanie ryzyka ataków DDoS woluminu lub kształtowanie ruchu w warstwie transportowej.

  • Docelowy punkt końcowy odpowiada za pomocą pofragmentowanych pakietów.

Jak rozwiązywać problemy

  • Zweryfikuj łączność z punktem końcowym w tym samym regionie lub w innym miejscu na potrzeby porównania.

  • Przeprowadź przechwytywanie pakietów ze stron źródłowych i docelowych.

  • Sprawdź liczbę pakietów w źródle i miejscu docelowym (jeśli jest dostępny), aby określić liczbę prób nawiązania połączenia.

  • Przyjrzyj się porzuconym pakietom , aby zobaczyć liczbę pakietów porzuconych przez bramę translatora adresów sieciowych.

  • Analizowanie pakietów. Pakiety TCP z pofragmentowanych pakietów protokołu IP wskazują na fragmentację adresów IP. Brama translatora adresów sieciowych nie obsługuje fragmentacji adresów IP i dlatego połączenia z pofragmentowanych pakietów kończą się niepowodzeniem.

  • Upewnij się, że publiczny adres IP bramy translatora adresów sieciowych jest wyświetlany jako dozwolony w miejscach docelowych partnerów z zaporami lub innymi składnikami zarządzania ruchem.

Możliwe rozwiązania błędów połączeń w miejscu docelowym internetu

  • Sprawdź, czy publiczny adres IP bramy translatora adresów sieciowych jest wyświetlany jako dozwolony w miejscu docelowym.

  • Jeśli tworzysz testy szybkości dużych ilości lub transakcji, sprawdź, czy zmniejszenie szybkości zmniejsza liczbę wystąpień awarii.

  • Jeśli zmniejszenie szybkości połączeń zmniejsza liczbę wystąpień awarii, sprawdź, czy miejsce docelowe osiągnęło limity szybkości interfejsu API lub inne ograniczenia.

Błędy połączeń na serwerze FTP dla trybu aktywnego lub pasywnego

Scenariusz

Podczas korzystania z bramy translatora adresów sieciowych z aktywnym lub pasywnym trybem FTP są wyświetlane błędy połączeń na serwerze FTP.

Możliwe przyczyny

  • Włączony jest aktywny tryb FTP.

  • Pasywny tryb FTP jest włączony, a brama translatora adresów sieciowych używa więcej niż jednego publicznego adresu IP.

Możliwe rozwiązanie dla trybu Aktywnego FTP

Protokół FTP używa dwóch oddzielnych kanałów między klientem a serwerem, poleceniem i kanałami danych. Każdy kanał komunikuje się na osobnych połączeniach TCP, jeden do wysyłania poleceń, a drugi do przesyłania danych.

W trybie aktywnym FTP klient ustanawia kanał poleceń, a serwer ustanawia kanał danych.

Brama translatora adresów sieciowych nie jest zgodna z aktywnym trybem FTP. Aktywny protokół FTP używa polecenia PORT z klienta FTP, który informuje serwer FTP, jakiego adresu IP i portu serwera używać w kanale danych, aby nawiązać połączenie z klientem. Polecenie PORT używa prywatnego adresu klienta, którego nie można zmienić. Ruch po stronie klienta jest SNATed przez bramę translatora adresów sieciowych dla komunikacji internetowej, więc polecenie PORT jest postrzegane jako nieprawidłowe przez serwer FTP.

Alternatywnym rozwiązaniem do aktywnego trybu FTP jest zamiast tego użycie pasywnego trybu FTP. Jednak aby można było używać bramy translatora adresów sieciowych w trybie pasywnym FTP, należy wziąć pod uwagę pewne kwestie .

Możliwe rozwiązanie dla pasywnego trybu FTP

W trybie pasywnym FTP klient nawiązuje połączenia zarówno na kanałach poleceń, jak i danych. Klient żąda odpowiedzi serwera na porcie zamiast próby nawiązania połączenia z klientem.

Wychodzący pasywny protokół FTP nie działa w przypadku bramy translatora adresów sieciowych z wieloma publicznymi adresami IP w zależności od konfiguracji serwera FTP. Gdy brama translatora adresów sieciowych z wieloma publicznymi adresami IP wysyła ruch wychodzący, losowo wybiera jeden z jego publicznych adresów IP dla źródłowego adresu IP. Ftp kończy się niepowodzeniem, gdy dane i kanały sterowania używają różnych źródłowych adresów IP w zależności od konfiguracji serwera FTP.

Aby zapobiec ewentualnym niepowodzeniom pasywnego połączenia FTP, wykonaj następujące czynności:

  1. Sprawdź, czy brama translatora adresów sieciowych jest dołączona do jednego publicznego adresu IP, a nie wielu adresów IP lub prefiksu.

  2. Upewnij się, że zakres portów pasywnych z bramy translatora adresów sieciowych może przekazywać wszystkie zapory w docelowym punkcie końcowym.

Uwaga

Zmniejszenie ilości publicznych adresów IP w bramie translatora adresów sieciowych zmniejsza spis portów SNAT dostępnych do nawiązywania połączeń wychodzących i może zwiększyć ryzyko wyczerpania portów SNAT. Przed usunięciem publicznych adresów IP z bramy translatora adresów sieciowych należy wziąć pod uwagę potrzeby łączności SNAT. Nie zaleca się zmiany ustawień serwera FTP w celu akceptowania ruchu płaszczyzny danych i sterowania z różnych źródłowych adresów IP.

Połączenia wychodzące na porcie 25 są blokowane

Scenariusz

Nie można nawiązać połączenia wychodzącego z bramą translatora adresów sieciowych na porcie 25 dla ruchu protokołu SMTP (Simple Mail Transfer Protocol).

Przyczyna

Platforma Azure blokuje wychodzące połączenia SMTP na porcie TCP 25 dla wdrożonych maszyn wirtualnych. Celem tej blokady jest poprawa zabezpieczeń partnerów i klientów firmy Microsoft, ochrona platformy Azure firmy Microsoft oraz zapewnienie zgodności ze standardami branżowymi.

Użyj uwierzytelnionej usługi przekazywania SMTP, aby wysyłać wiadomości e-mail z maszyn wirtualnych platformy Azure lub z usługi aplikacja systemu Azure Service. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z łącznością wychodzącą SMTP.

Więcej wskazówek dotyczących rozwiązywania problemów

Dodatkowe przechwytywanie sieci

Jeśli badanie jest niejednoznaczne, otwórz zgłoszenie do pomocy technicznej w celu dalszego rozwiązywania problemów i zbierz poniższe informacje w celu przyspieszenia rozwiązania. Wybierz jedną maszynę wirtualną w skonfigurowanej podsieci translatora adresów sieciowych i wykonaj następujące testy:

  • Przetestuj odpowiedź portu sondy przy użyciu ps ping jednej z maszyn wirtualnych zaplecza w sieci wirtualnej i zarejestruj wyniki (na przykład: ps ping 10.0.0.4:3389).

  • Jeśli w tych testach ping nie zostanie odebrana żadna odpowiedź, uruchom równoczesny netsh ślad na maszynie wirtualnej zaplecza i testową maszynę wirtualną sieci wirtualnej podczas uruchamiania narzędzia PsPing, a następnie zatrzymaj netsh śledzenie.

Najlepsze rozwiązania dotyczące łączności wychodzącej

Platforma Azure monitoruje i obsługuje swoją infrastrukturę z wielką starannością. Jednak przejściowe błędy mogą nadal występować z wdrożonych aplikacji i nie ma gwarancji transmisji bez strat. Brama translatora adresów sieciowych jest preferowaną opcją ustanawiania wysoce niezawodnej i odpornej łączności wychodzącej z wdrożeń platformy Azure. Aby zoptymalizować wydajność połączenia aplikacji, zapoznaj się ze wskazówkami w dalszej części artykułu.

Użycie buforowania połączeń

Podczas tworzenia puli połączeń należy unikać otwierania nowych połączeń sieciowych dla wywołań do tego samego adresu i portu. Można zaimplementować schemat buforowania połączeń w aplikacji, w którym żądania są wewnętrznie dystrybuowane w stałym zestawie połączeń i ponownie używane, gdy jest to możliwe. Ta konfiguracja ogranicza liczbę używanych portów SNAT i tworzy przewidywalne środowisko. Buforowanie połączeń pomaga zmniejszyć opóźnienia i wykorzystanie zasobów, a ostatecznie poprawić wydajność aplikacji.

Aby dowiedzieć się więcej na temat buforowania połączeń HTTP, zobacz Pool HTTP connections with HttpClientFactory (Buforowanie połączeń HTTP za pomocą elementu HttpClientFactory).

Ponowne używanie połączeń

Zamiast generować pojedyncze, niepodzielne połączenia TCP dla każdego żądania, skonfiguruj aplikację do ponownego użycia połączeń. Ponowne użycie połączenia powoduje bardziej wydajne transakcje TCP i jest szczególnie istotne w przypadku protokołów, takich jak HTTP/1.1, gdzie ponowne użycie połączenia jest domyślne. To ponowne użycie dotyczy innych protokołów, które używają protokołu HTTP jako transportu, takiego jak REST.

Używanie mniej agresywnej logiki ponawiania prób

Gdy porty SNAT są wyczerpane lub występują błędy aplikacji, agresywne lub brutalne próby siłowe bez opóźnień i wycofywania logiki powodują wyczerpanie lub trwałość. Możesz zmniejszyć zapotrzebowanie na porty SNAT przy użyciu mniej agresywnej logiki ponawiania prób.

W zależności od skonfigurowanego limitu czasu bezczynności, jeśli ponowne próby są zbyt agresywne, połączenia nie mają wystarczająco dużo czasu, aby zamknąć i zwolnić porty SNAT do ponownego użycia.

Aby uzyskać dodatkowe wskazówki i przykłady, zobacz Wzorzec ponawiania prób.

Używanie elementów utrzymywania aktywności w celu resetowania limitu czasu bezczynności połączeń wychodzących

Aby uzyskać więcej informacji o elementach keepalives, zobacz Limit czasu bezczynności protokołu TCP.

Jeśli to możliwe, usługa Private Link powinna służyć do łączenia się bezpośrednio z sieci wirtualnych z usługami platformy Azure w celu zmniejszenia zapotrzebowania na porty SNAT. Zmniejszenie zapotrzebowania na porty SNAT może pomóc zmniejszyć ryzyko wyczerpania portów SNAT.

Aby utworzyć usługę Private Link, zobacz następujące przewodniki Szybki start, aby rozpocząć pracę:

Następne kroki

Zawsze staramy się ulepszać środowisko naszych klientów. Jeśli napotkasz problemy z bramą translatora adresów sieciowych, które nie są rozwiązane lub rozwiązane w tym artykule, prześlij opinię za pośrednictwem usługi GitHub w dolnej części tej strony.

Aby dowiedzieć się więcej o bramie translatora adresów sieciowych, zobacz: