Share via

Řešení potíží s připojením ke službě Azure NAT Gateway

  • Článek

Tento článek obsahuje pokyny k řešení běžných problémů s odchozím připojením ke službě NAT Gateway a jejich řešení. Tento článek obsahuje také osvědčené postupy pro efektivní navrhování aplikací tak, aby používaly odchozí připojení.

Pokles dostupnosti cesty k datům ve službě NAT Gateway s chybami připojení

Scénář

Sledujete pokles dostupnosti cesty k datům služby NAT Gateway, která se shoduje se selháním připojení.

Možné příčiny

  • Vyčerpání portů překladu zdrojových síťových adres (SNAT)

  • Limity souběžných připojení SNAT.

  • časové limity Připojení.

Řešení potíží s kroky

  • Zkontrolujte metriku dostupnosti cesty k datům a vyhodnoťte stav služby NAT Gateway.

  • Zkontrolujte metriku počtu Připojení ionů SNAT a rozdělte stav připojení pokusem a neúspěšnými připojeními. Více než nula neúspěšných připojení značí vyčerpání portů SNAT nebo dosažení limitu počtu připojení SNAT brány NAT.

  • Ujistěte se, že metrika počtu připojení je v mezích, a to ověřením metriky celkového počtu Připojení nat. NaT Gateway podporuje 50 000 souběžných připojení na IP adresu k jedinečnému cíli a celkem až 2 miliony připojení. Další informace najdete v tématu Výkon služby NAT Gateway.

  • Zkontrolujte metriku vynechaných paketů u všech zahozených paketů, které odpovídají selháním připojení nebo velkému objemu připojení.

  • Podle potřeby upravte nastavení časovače časového limitu nečinnosti protokolu TCP (Transmission Control Protocol). Časovač časového limitu nečinnosti nastavený na delší dobu než výchozí (4 minuty) je u toků delší a může způsobit dodatečný tlak na inventář portů SNAT.

Možná řešení vyčerpání portů SNAT nebo dosažení limitů souběžných připojení

  • Přidejte veřejné IP adresy do služby NAT Gateway až do celkového počtu 16, abyste mohli škálovat odchozí připojení. Každá veřejná IP adresa poskytuje 64 512 portů SNAT a podporuje až 50 000 souběžných připojení na jedinečný cílový koncový bod pro službu NAT Gateway.

  • Distribuujte prostředí aplikace napříč několika podsítěmi a pro každou podsíť zadejte prostředek služby NAT Gateway.

  • Uvolněte inventář portů SNAT snížením časového limitu nečinnosti protokolu TCP na nižší hodnotu. Časovač časového limitu nečinnosti protokolu TCP nemůže být nastavený méně než 4 minuty.

  • Zvažte asynchronní vzory dotazování, abyste uvolnili prostředky připojení pro jiné operace.

  • Připojení ke službám Azure PaaS přes páteřní síť Azure pomocí služby Private Link Private Link uvolní porty SNAT pro odchozí připojení k internetu.

  • Pokud je vaše šetření neprůkazné, otevřete případ podpory pro další řešení potíží.

Poznámka:

Je důležité pochopit, proč dochází k vyčerpání portů SNAT. Ujistěte se, že používáte správné vzory pro škálovatelné a spolehlivé scénáře. Přidání dalších portů SNAT do scénáře bez porozumění příčině poptávky by mělo být poslední možností. Pokud nerozumíte tomu, proč váš scénář používá tlak na inventář portů SNAT, přidání dalších portů SNAT přidáním dalších IP adres zpozdí stejné selhání vyčerpání jako škálování vaší aplikace. Možná maskujete jiné neektivosti a anti-vzory. Další informace najdete v osvědčených postupech pro efektivní použití odchozích připojení.

Možná řešení vypršení časových limitů připojení TCP

K aktualizaci nečinných toků a resetování časovače časového limitu nečinnosti použijte protokol TCP keepalives nebo aplikační vrstvu. Příklady najdete v příkladech .NET.

Protokol TCP keepalives musí být povolen pouze z jedné strany připojení, aby bylo připojení aktivní z obou stran. Když je protokol TCP keepalive odeslán z jedné strany připojení, druhá strana automaticky odešle potvrzený paket (ACK). Časovač časového limitu nečinnosti se pak resetuje na obou stranách připojení.

Poznámka:

Zvýšení časového limitu nečinnosti protokolu TCP je poslední možností a nemusí vyřešit původní příčinu problému. Dlouhý časový limit může způsobit zpoždění a způsobit zbytečné chyby s nízkou mírou, když vyprší časový limit.

Možná řešení vypršení časových limitů připojení UDP (User Datagram Protocol)

Časovače časového limitu nečinnosti UDP jsou nastavené na 4 minuty a nedají se konfigurovat. Pro oba směry v toku připojení povolte udržování dlouhých připojení pomocí protokolu UDP. Pokud je zapnutá funkce keepalive UDP, je aktivní pouze pro jeden směr připojení. Připojení může být stále nečinné a vypršení časového limitu na druhé straně připojení. Aby se zabránilo vypršení časového limitu nečinnosti připojení UDP, měly by být v toku připojení povolené keepalives UDP pro oba směry.

K aktualizaci nečinných toků a resetování časového limitu nečinnosti je možné použít také keepalives aplikační vrstvy. Na straně serveru zkontrolujte, jaké možnosti existují pro konkrétní aplikace keepalives.

Pokles dostupnosti cesty k datům ve službě NAT Gateway, ale žádné chyby připojení

Scénář

Dostupnost cesty k datům brány NAT gateway klesne, ale nepovedlo se sledovat žádná neúspěšná připojení.

Možná příčina

Přechodné poklesy dostupnosti cesty k datům způsobené šumem v datové cestě

Postup při řešení potíží

Pokud si všimnete poklesu dostupnosti cesty k datům, aniž by to mělo vliv na odchozí připojení, může to být způsobeno tím, že brána NAT gateway vyzvedne přechodný šum v cestě k datům.

Nastavte upozornění na výpadky dostupnosti cesty k datům nebo použijte Azure Resource Health k upozorňování na události stavu služby NAT Gateway.

Žádné možnosti odchozího připojení k internetu

Scénář

Ve službě NAT Gateway se nedochází k žádnému odchozímu připojení.

Možné příčiny

  • Chybná konfigurace služby NAT Gateway

  • Internetový provoz se přesměruje mimo bránu NAT Gateway a vynutí tunelování na virtuální zařízení nebo do místního cíle pomocí sítě VPN nebo ExpressRoute.

  • Pravidla skupiny zabezpečení sítě (NSG) jsou nakonfigurovaná tak, aby blokovala internetový provoz.

  • Dostupnost cesty k datům služby NAT Gateway je degradovaná.

  • Chybná konfigurace systému DNS (Domain Name System).

Postup při řešení potíží

  • Zkontrolujte, jestli je služba NAT Gateway nakonfigurovaná alespoň s jednou veřejnou IP adresou nebo předponou a připojenou k podsíti. NaT Gateway není funkční, dokud se nepřipojuje veřejná IP adresa a podsíť. Další informace najdete v tématu Základy konfigurace služby NAT Gateway.

  • Zkontrolujte směrovací tabulku podsítě připojené ke službě NAT Gateway. Veškerý provoz 0.0.0.0/0, který je vynuceně tunelovaný na síťové virtuální zařízení (NVA), ExpressRoute nebo VPN Gateway, bude mít přednost před bránou NAT. Další informace najdete v tom , jak Azure vybere trasu.

  • Zkontrolujte, jestli na virtuálním počítači nejsou nakonfigurovaná nějaká pravidla NSG pro síťové rozhraní, která blokuje přístup k internetu.

  • Zkontrolujte, jestli je dostupnost cesty k datům služby NAT Gateway ve sníženém stavu. Pokud je služba NAT Gateway ve sníženém stavu, projděte si pokyny k řešení potíží s chybami připojení.

  • Zkontrolujte nastavení DNS, pokud se DNS nepřeloží správně.

Možná řešení pro ztrátu odchozího připojení

Veřejná IP adresa služby NAT Gateway se nepoužívá k připojení odchozích přenosů.

Scénář

Služba NAT Gateway je nasazená ve virtuální síti Azure, ale pro odchozí připojení se používají neočekávané IP adresy.

Možné příčiny

  • Chybná konfigurace služby NAT Gateway

  • Aktivní připojení s jinou metodou odchozího připojení Azure, jako je Azure Load Balancer nebo veřejné IP adresy na úrovni instance na virtuálních počítačích. Aktivní toky připojení nadále používají předchozí veřejnou IP adresu, která byla přiřazena při vytvoření připojení. Po nasazení služby NAT Gateway začnou nová připojení hned používat službu NAT Gateway.

  • Privátní IP adresy se používají k připojení ke službám Azure pomocí koncových bodů služeb nebo služby Private Link.

  • Připojení pro účty úložiště pocházejí ze stejné oblasti jako virtuální počítač, ze které vytváříte připojení.

  • Internetový provoz se přesměrovává mimo bránu NAT Gateway a vynucuje tunelování na síťové virtuální zařízení nebo bránu firewall.

Řešení potíží

  • Zkontrolujte, jestli má vaše brána NAT přiřazenou aspoň jednu veřejnou IP adresu nebo předponu a alespoň jednu podsíť.

  • Ověřte, jestli je po nasazení služby NAT Gateway stále aktivní nějaká předchozí metoda odchozího připojení, jako je veřejný nástroj pro vyrovnávání zatížení.

  • Zkontrolujte, jestli připojení k jiným službám Azure pocházejí z privátní IP adresy ve vaší virtuální síti Azure.

  • Zkontrolujte, jestli máte povolené privátní propojení nebo koncové body služby pro připojení k jiným službám Azure.

  • Při vytváření připojení k úložišti se ujistěte, že se váš virtuální počítač nachází ve stejné oblasti jako úložiště Azure.

  • Ověřte, jestli veřejná IP adresa používaná pro připojení pochází z jiné služby Azure ve vaší virtuální síti Azure, například síťového virtuálního zařízení (NVA).

Možná řešení pro veřejnou IP adresu služby NAT Gateway, která se nepoužívají k připojení odchozích přenosů

  • Připojte veřejnou IP adresu nebo předponu ke službě NAT Gateway. Ujistěte se, že je služba NAT Gateway připojená k podsítím ze stejné virtuální sítě. Ověřte, že se služba NAT Gateway může připojit odchozí.

  • Otestujte a vyřešte problémy s virtuálními počítači, které se drží na starých IP adresách SNAT z jiné metody odchozího připojení:

    • Ujistěte se, že vytvoříte nové připojení a že se stávající připojení nebudou znovu používat v operačním systému nebo že prohlížeč připojení ukládají do mezipaměti. Pokud například v PowerShellu používáte curl, nezapomeňte zadat parametr -DisableKeepalive, který vynutí nové připojení. Pokud používáte prohlížeč, můžete připojení také vytvořit ve fondu.

    • Není nutné restartovat virtuální počítač v podsíti nakonfigurované pro službu NAT Gateway. Pokud se ale virtuální počítač restartuje, stav připojení se vyprázdní. Když se stav připojení vyprázdní, všechna připojení začnou používat IP adresu nebo adresy prostředku služby NAT Gateway. Toto chování je vedlejším účinkem restartování virtuálního počítače, nikoli indikátorem, že se vyžaduje restartování.

    • Pokud stále máte potíže, otevřete případ podpory pro další řešení potíží.

  • Vlastní trasy směrující provoz 0.0.0.0/0 do síťového virtuálního zařízení budou mít přednost před službou NAT Gateway pro směrování provozu do internetu. Pokud chcete, aby služba NAT Gateway směruje provoz na internet místo síťového virtuálního zařízení, odeberte vlastní trasu pro provoz 0.0.0.0/0 do virtuálního zařízení. Provoz 0.0.0.0/0 se obnoví pomocí výchozí trasy na internet a místo toho se použije služba NAT Gateway.

Důležité

Před provedením jakýchkoli změn způsobu směrování provozu pečlivě zvažte požadavky směrování vaší cloudové architektury.

  • Služby nasazené ve stejné oblasti jako účet úložiště Azure používají privátní IP adresy Azure pro komunikaci. Na základě rozsahu veřejných odchozích IP adres nemůžete omezit přístup ke konkrétním službám Azure. Další informace najdete v omezeních pro pravidla sítě PROTOKOLU IP.
  • Koncové body služby Private Link používají privátní IP adresy instancí virtuálních počítačů ve vaší virtuální síti k připojení ke službám platformy Azure místo veřejné IP adresy služby NAT Gateway. Pomocí služby Private Link se připojte k dalším službám Azure přes páteřní síť Azure místo přes internet pomocí služby NAT Gateway.

Poznámka:

Private Link je doporučená možnost přes koncové body služby pro privátní přístup k hostovaným službám Azure.

Připojení selhání v cíli veřejného internetu

Scénář

Připojení služby NAT Gateway k internetovým cílům selžou nebo vyprší časový limit.

Možné příčiny

  • Brána firewall nebo jiné komponenty správy provozu v cíli.

  • Omezování rychlosti rozhraní API uložené na straně cíle

  • Zmírnění rizik DDoS pro volumetric nebo formování provozu přenosové vrstvy

  • Cílový koncový bod reaguje fragmentovanými pakety.

Řešení potíží

  • Ověřte připojení ke koncovému bodu ve stejné oblasti nebo jinde pro porovnání.

  • Proveďte zachytávání paketů ze zdrojové a cílové strany.

  • Podívejte se na počet paketů ve zdroji a cíli (pokud je k dispozici) a zjistěte, kolik pokusů o připojení bylo provedeno.

  • Podívejte se na zahozené pakety a zjistěte, kolik paketů zahodila služba NAT Gateway.

  • Analyzujte pakety. Pakety TCP s fragmentovanými pakety protokolu IP označují fragmentaci PROTOKOLU IP. NaT Gateway nepodporuje fragmentaci IP adres, takže připojení s fragmentovanými pakety selžou.

  • Ujistěte se, že je veřejná IP adresa služby NAT Gateway uvedená jako povolená v partnerských cílech s branami Firewall nebo jinými komponentami správy provozu.

Možná řešení selhání připojení v internetovém cíli

  • Ověřte, že je veřejná IP adresa služby NAT Gateway v cíli uvedená jako povolená.

  • Pokud vytváříte testování vysokého objemu nebo rychlosti transakcí, prozkoumejte, jestli snížení rychlosti snižuje výskyt selhání.

  • Pokud se sníží rychlost připojení, sníží se výskyt selhání, zkontrolujte, jestli cíl dosáhl limitů rychlosti rozhraní API nebo jiných omezení.

selhání Připojení na serveru FTP pro aktivní nebo pasivní režim

Scénář

Při použití služby NAT Gateway s aktivním nebo pasivním režimem FTP se zobrazí selhání připojení na serveru FTP.

Možné příčiny

  • Je povolený aktivní režim FTP.

  • Pasivní režim FTP je povolený a služba NAT Gateway používá více než jednu veřejnou IP adresu.

Možné řešení pro režim aktivního FTP

Protokol FTP používá dva samostatné kanály mezi klientem a serverem, příkazem a datovými kanály. Každý kanál komunikuje na samostatných připojeních TCP, jeden pro odesílání příkazů a druhý pro přenos dat.

V aktivním režimu FTP klient vytvoří kanál příkazů a server vytvoří datový kanál.

Služba NAT Gateway není kompatibilní s aktivním režimem FTP. Aktivní FTP používá příkaz PORT z klienta FTP, který serveru FTP řekne, jakou IP adresu a port má server použít v datovém kanálu pro připojení zpět k klientovi. Příkaz PORT používá privátní adresu klienta, kterou nelze změnit. Přenosy na straně klienta jsou službou NAT Gateway určené pro internetovou komunikaci, takže server FTP považuje příkaz PORT za neplatný.

Alternativou k aktivnímu režimu FTP je místo toho použití pasivního režimu FTP. Aby však bylo možné používat službu NAT Gateway v pasivním režimu FTP, je potřeba vzít v úvahu některé aspekty .

Možné řešení pro pasivní režim FTP

V pasivním režimu FTP klient naváže připojení k příkazům i datovým kanálům. Klient požaduje, aby server odpověděl na portu, místo aby se pokusil navázat připojení zpět k klientovi.

Odchozí pasivní FTP nefunguje pro službu NAT Gateway s více veřejnými IP adresami v závislosti na konfiguraci serveru FTP. Když služba NAT Gateway s několika veřejnými IP adresami odesílá odchozí provoz, náhodně vybere jednu z jejích veřejných IP adres pro zdrojovou IP adresu. Ftp selže, když datové a řídicí kanály používají různé zdrojové IP adresy v závislosti na konfiguraci serveru FTP.

Pokud chcete zabránit možným selháním pasivního připojení FTP, postupujte takto:

  1. Zkontrolujte, že je služba NAT Gateway připojená k jedné veřejné IP adrese, a ne k více IP adresám nebo předponě.

  2. Ujistěte se, že pasivní port od vaší brány NAT gateway může předávat všechny brány firewall v cílovém koncovém bodu.

Poznámka:

Snížení počtu veřejných IP adres ve vaší bráně NAT snižuje dostupnost inventáře portů SNAT pro odchozí připojení a může zvýšit riziko vyčerpání portů SNAT. Před odebráním veřejných IP adres ze služby NAT Gateway zvažte potřeby připojení SNAT. Nedoporučuje se měnit nastavení serveru FTP tak, aby přijímala provoz roviny dat z různých zdrojových IP adres.

Odchozí připojení na portu 25 jsou blokovaná

Scénář

Odchozí spojení se službou NAT Gateway na portu 25 pro přenos protokolu SMTP (Simple Mail Transfer Protocol) se nedá připojit.

Příčina

Platforma Azure blokuje odchozí připojení SMTP na portu TCP 25 pro nasazené virtuální počítače. Cílem tohoto bloku je zajistit lepší zabezpečení pro partnery a zákazníky Microsoftu, chránit platformu Azure Microsoftu a dodržovat oborové standardy.

K odesílání e-mailů z virtuálních počítačů Azure nebo ze služby Aplikace Azure Service použijte ověřenou předávací službu SMTP. Další informace najdete v tématu řešení potíží s odchozím připojením SMTP.

Další pokyny při řešení potíží

Extra síťové zachytávání

Pokud je vaše šetření bezvýsledné, otevřete případ podpory pro další řešení potíží a shromážděte následující informace, které pomůžou urychlit řešení. Zvolte jeden virtuální počítač v nakonfigurované podsíti služby NAT Gateway a proveďte následující testy:

  • Otestujte odpověď na port sondy pomocí ps ping jednoho z back-endových virtuálních počítačů v rámci virtuální sítě a výsledky záznamu (příklad: ps ping 10.0.0.4:3389).

  • Pokud v těchto testech ping nebyla přijata žádná odpověď, spusťte na back-endovém virtuálním počítači souběžné netsh trasování a během spuštění nástroje PsPing spusťte testovací virtuální počítač virtuální sítě. Pak trasování zastavte netsh .

Osvědčené postupy pro odchozí připojení

Azure monitoruje a provozuje svou infrastrukturu s velkou opatrností. U nasazených aplikací ale může docházet k přechodným selháním a neexistuje žádná záruka bezeztrátových přenosů. Brána NAT je upřednostňovanou možností pro vytvoření vysoce spolehlivého a odolného odchozího připojení z nasazení Azure. Pokud chcete optimalizovat efektivitu připojení aplikací, přečtěte si pokyny dále v článku.

Použití sdružování připojení

Při sdružování připojení se vyhnete otevření nových síťových připojení pro volání na stejnou adresu a port. Ve své aplikaci můžete implementovat schéma sdružování připojení, ve kterém se požadavky interně distribuují napříč pevnou sadou připojení a v případě potřeby se znovu používají. Toto nastavení omezuje počet používaných portů SNAT a vytvoří předvídatelné prostředí. Připojení sdružování pomáhá snížit latenci a využití prostředků a nakonec zlepšit výkon vašich aplikací.

Další informace o sdružování připojení HTTP najdete v tématu Připojení HTTP fondu pomocí HttpClientFactory.

Opakované použití připojení

Místo generování jednotlivých, atomických připojení TCP pro každý požadavek nakonfigurujte aplikaci tak, aby znovu používala připojení. Připojení opakované použití vede k výkonnějším transakcím TCP a je zvlášť relevantní pro protokoly, jako je HTTP/1.1, kde je výchozí použití připojení. Toto opakované použití se vztahuje na jiné protokoly, které používají protokol HTTP jako jejich přenos, jako je REST.

Použití méně agresivní logiky opakování

Když dojde k vyčerpání portů SNAT nebo selhání aplikace, agresivní nebo hrubá síla opakování bez zpoždění a zpětná logika způsobí vyčerpání nebo zachování. Poptávku po portech SNAT můžete snížit pomocí méně agresivní logiky opakování.

Pokud jsou pokusy příliš agresivní, připojení nemají dostatek času na zavření a uvolnění portů SNAT pro opakované použití v závislosti na nakonfigurované době nečinnosti.

Další pokyny a příklady najdete v tématu Vzor opakování.

Pomocí příkazu keepalives obnovte časový limit nečinnosti odchozího připojení.

Další informace o keepalives naleznete v tématu Vypršení časového limitu nečinnosti protokolu TCP.

Pokud je to možné, služba Private Link by se měla použít k přímému připojení z vašich virtuálních sítí ke službám platformy Azure, aby se snížila poptávka po portech SNAT. Snížení poptávky na portech SNAT může pomoct snížit riziko vyčerpání portů SNAT.

Pokud chcete vytvořit Private Link, přečtěte si následující příručky pro rychlý start, které vám pomůžou začít:

Další kroky

Vždy se snažíme vylepšit prostředí našich zákazníků. Pokud narazíte na problémy se službou NAT Gateway, které nejsou vyřešené nebo vyřešené tímto článkem, poskytněte zpětnou vazbu prostřednictvím GitHubu v dolní části této stránky.

Další informace o službě NAT Gateway najdete tady: