Udostępnij za pośrednictwem

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

Ten artykuł zawiera wskazówki dotyczące rozwiązywania i usuwania typowych problemów z łącznością wychodzącą z bramą NAT (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 przepustowości danych bramy NAT, co zbiega się z błędami połączenia.

Możliwe przyczyny

  • Wyczerpanie portów translacji adresów sieciowych źródłowych (SNAT).

  • Jednoczesne limity połączeń SNAT.

  • Przekroczenia limitu czasu połączenia.

  • Usuwanie publicznych adresów IP lub podsieci z bramy NAT.

Kroki rozwiązywania problemów

  • Oceń kondycję bramy NAT, sprawdzając metrykę dostępności ścieżki danych.

  • Sprawdź metrykę Liczba połączeń SNAT i podziel stan połączenia na połączenia próbne i nieudane. Więcej niż zero nieudanych połączeń wskazuje na wyczerpanie portów SNAT lub osiągnięcie limitu liczby połączeń bramy NAT.

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

  • Sprawdź metrę porzucanych pakietów pod kątem zdarzeń zgodnych z błędami połączenia lub dużym natężeniem połączeń.

  • 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) utrzymuje przepływy dłużej i może spowodować dodatkową presję na inwentarz portów SNAT.

  • Sprawdź konfiguracje publicznych adresów IP i podsieci bramy translatora adresów sieciowych oraz czy ostatnio usunięto z bramy translatora adresów sieciowych jakiekolwiek publiczne adresy IP lub podsieci.

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 NAT, do łącznej liczby 16, aby zwiększyć skalowalność łączności wychodzącej. Każdy publiczny adres IP zapewnia 64 512 portów SNAT i obsługuje maksymalnie 50 000 jednoczesnych połączeń do jednego unikalnego punktu końcowego dla bramy NAT.

  • Dystrybuuj środowisko aplikacji w wielu podsieciach i zapewnij zasób bramy NAT dla każdej podsieci.

  • Zwolnij zasoby portów SNAT, zmniejszając czasomierz czasu bezczynności protokołu TCP do niższej wartości. Limit czasu bezczynności protokołu TCP nie może być ustawiony na niższy 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 zasoby portów SNAT, dodanie większej liczby portów SNAT poprzez zwiększenie liczby adresów IP jedynie opóźni wystąpienie tego samego problemu wyczerpania zasobów, gdy aplikacja będzie się rozrastać. Możesz maskować inne nieefektywności i antywzorce. 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 keepalives protokołu TCP lub keepalives warstwy aplikacji, aby odświeżyć nieaktywne przepływy i zresetować timer bezczynności. Przykłady można znaleźć na stronie Przykłady platformy .NET.

Keepalive TCP muszą być włączone tylko po jednej stronie połączenia, aby utrzymać połączenie aktywne z obu stron. Po wysłaniu pakietu keepalive 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 wywołać niepotrzebne rzadkie niepowodzenia 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 funkcji podtrzymania aktywności UDP, jest ona aktywna tylko w jednym kierunku połączenia. Połączenie może nadal pozostawać nieaktywne, a po drugiej stronie może nastąpić jego zakończenie z powodu przekroczenia limitu czasu. Aby zapobiec przekroczeniu limitu czasu bezczynności połączenia UDP, należy włączyć mechanizm podtrzymywania połączenia UDP (UDP keepalives) w obu kierunkach przepływu połączenia.

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

Wpływ usuwania publicznych adresów IP lub podsieci z NAT Gateway

Wszystkie aktywne połączenia skojarzone z publicznym adresem IP zakończą się po usunięciu publicznego adresu IP z bramy translatora adresów sieciowych. Jeśli zasób bramy NAT ma wiele publicznych adresów IP, nowy ruch jest dystrybuowany między przypisanymi adresami IP. Jeśli z dowolnych podsieci zostanie usunięta brama NAT, ruch zostanie zakłócony. Rozważ zaktualizowanie konfiguracji bramy NAT w trakcie okien konserwacyjnych, aby zminimalizować wpływ na połączenia wychodzące.

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

Scenariusz

Dostępność ścieżki danych bramy NAT 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 wpływu na łączność wychodzącą, może to być spowodowane przez bramę NAT przechwytywaniem przejściowych zakłóceń w ścieżce danych.

Skonfiguruj alert dotyczący spadków dostępności ścieżki danych lub użyj usługi Azure Resource Health, aby otrzymywać alerty dotyczące kondycji NAT Gateway.

Brak połączeń wychodzących z Internetem

Scenariusz

Nie widzisz łączności wychodzącej na bramie NAT.

Możliwe przyczyny

  • Błędna konfiguracja bramy NAT.

  • Ruch internetowy jest przekierowywany z bramy translatora adresów sieciowych i przekierowywany w tunelu do urządzenia wirtualnego lub lokalnej lokalizacji docelowej za pomocą sieci VPN lub usługi ExpressRoute.

  • Reguły grupy zabezpieczeń sieciowych (NSG) zostały skonfigurowane tak, aby blokować ruch internetowy.

  • Dostępność ścieżki danych bramy NAT jest obniżona.

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

Kroki rozwiązywania problemów

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

  • Sprawdź tabelę routingu podsieci dołączonej do bramy NAT. Każdy ruch 0.0.0.0/0 tunelowany na siłę do Wirtualnego Urządzenia Sieciowego (WUS), usługi ExpressRoute lub bramy VPN będzie miał priorytet nad bramą NAT. Aby uzyskać więcej informacji, zobacz , jak platforma Azure wybiera trasę.

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

  • Sprawdź, czy dostępność ścieżki danych bramy translatora adresów sieciowych jest obniżona. 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 DNS nie rozwiązuje prawidłowo.

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

Publiczny adres IP bramy NAT nie jest używany do nawiązywania połączeń wychodzących

Scenariusz

Brama NAT jest wdrażana w sieci wirtualnej platformy Azure, ale używane są nieoczekiwane adresy IP dla połączeń wychodzących.

Możliwe przyczyny

  • Nieprawidłowa konfiguracja bramy NAT.

  • 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 lub domyślny dostęp wychodzący. 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 nawiązuje się połączenie.

  • Ruch internetowy jest przekierowywany z bramy NAT i użycie wymuszonego tunelowania do NVA lub zapory.

Jak rozwiązywać problemy

  • Sprawdź, czy brama NAT 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 równoważnik obciążenia, jest nadal aktywna po wdrożeniu bramy NAT.

  • 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.

  • Sprawdź, czy 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 NAT, który nie jest używany do połączeń wychodzących

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

  • Przetestuj i rozwiąż problemy z maszynami wirtualnymi, które posiadają publiczne adresy IP z innej metody łączności wychodzącej, w tym równoważnik obciążenia, publiczne adresy IP na poziomie instancji lub domyślny dostęp wychodzący 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 również można grupować.

    • Uruchom ponownie maszynę wirtualną (wykonaj zatrzymanie/uruchomienie) w podsieci skonfigurowanej do bramy NAT. Jeśli maszyna wirtualna zostanie ponownie uruchomiona, stan połączenia zostanie opróżniony. Po opróżnieniu stanu połączenia wszystkie nowe połączenia rozpoczynają używanie adresu IP lub adresów zasobu bramy NAT. Należy pamiętać, że jeśli maszyna wirtualna ma aktywne połączenia w momencie ponownego uruchomienia, te połączenia zostaną porzucone.

    • 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 NVA będą miały pierwszeństwo przed bramą NAT przy routingu ruchu do Internetu. Aby brama NAT kierowała ruch do Internetu zamiast urządzenia NVA, usuń trasę niestandardową dla ruchu 0.0.0.0/0 przechodzącego do urządzenia wirtualnego. Ruch 0.0.0.0/0 jest wznawiany przy użyciu domyślnej trasy do Internetu, a zamiast tego wykorzystywana jest brama NAT.

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 inne punkty końcowe używają prywatnych adresów IP wystąpień maszyn wirtualnych w Twojej sieci wirtualnej do łączenia się z usługami platformy Azure, zamiast użycia publicznego adresu IP bramy NAT. 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ą NAT.

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ą.

  • Zabezpieczenia przed atakami DDoS o dużej ilości ruchu 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 przy źródle i przy miejscu docelowym (jeśli są dostępne), aby ustalić, ile prób nawiązania połączenia zostało podjętych.

  • Sprawdź porzucone pakiety , aby zobaczyć, ile pakietów zostało porzuconych przez bramę NAT.

  • 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 NAT jest uwzględniony jako dozwolony w miejscach docelowych u 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 NAT jest wymieniony wśród dozwolonych w miejscu docelowym.

  • Jeśli tworzysz testy dużej liczby lub wysokiego natężenia transakcji, sprawdź, czy zmniejszenie częstotliwości zmniejsza liczbę przypadków 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 NAT z aktywnym lub pasywnym trybem FTP, na serwerze FTP występują błędy połączeń.

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 NAT nie jest zgodna z aktywnym trybem FTP. Aktywny protokół FTP używa polecenia PORT wysłanego przez klienta FTP, które informuje serwer FTP, z jakiego adresu IP i portu na kanale danych ma korzystać, aby połączyć się z powrotem 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 NAT 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.

Pasywny FTP wychodzący może nie działać w przypadku bramy NAT 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 ze swoich 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 NAT jest połączona z jednym, publicznym adresem IP zamiast z wieloma adresami IP lub prefiksem.

  2. Upewnij się, że zakres portów pasywnych z bramy NAT jest dozwolony do przejścia przez wszelkie zapory w punkcie docelowym.

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 NAT należy wziąć pod uwagę potrzeby łączności SNAT. Nie zaleca się zmiany ustawień serwera FTP w celu akceptowania ruchu w płaszczyźnie 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ą NAT na porcie 25 dla ruchu Simple Mail Transfer Protocol (SMTP).

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 w Azure lub z usługi aplikacji Azure. 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 zapisy sieciowe

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 pojedynczą maszynę wirtualną w podsieci skonfigurowanej do pracy z bramą NAT 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ównocześnie trasowanie na maszynie wirtualnej zaplecza oraz na testowej maszynie wirtualnej sieci wirtualnej, podczas gdy uruchamiasz narzędzie PsPing, a następnie zatrzymaj to trasowanie.

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. Gateway NAT jest preferowaną opcją do ustanawiania niezawodnej i odpornej łączności wychodzącej dla wdrożeń w Azure. Aby zoptymalizować wydajność połączenia aplikacji, zapoznaj się ze wskazówkami w dalszej części artykułu.

Użyj 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 ponowienia prób bez opóźnień i logiki wycofania powodują wystąpienie lub utrzymywanie się wyczerpania. 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żyj keepalive, aby zresetować limit czasu bezczynności połączeń wychodzących

Aby uzyskać więcej informacji o funkcjach keepalive, zobacz Limit czasu bezczynności 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ć doświadczenie naszych klientów. Jeśli napotkasz problemy z bramą translatora adresów sieciowych, które nie są rozwiązane w tym artykule, prześlij opinię na GitHubie, korzystając z odnośnika na dole tej strony.

Aby dowiedzieć się więcej o bramie NAT, zobacz: