Felsöka Azure NAT Gateway-anslutning

  • Artikel

Den här artikeln innehåller vägledning om hur du felsöker och löser vanliga problem med utgående anslutningar med din NAT-gateway. Den här artikeln innehåller även metodtips för hur du utformar program för att använda utgående anslutningar effektivt.

Datapath-tillgänglighetsminskning på NAT-gateway med anslutningsfel

Scenario

Du ser en minskning av tillgängligheten för DATAPATH för NAT-gatewayen, vilket sammanfaller med anslutningsfel.

Möjliga orsaker

  • Portöverbelastning (SNAT) för källnätverksadressöversättning (SNAT).

  • Gränser för samtidig SNAT-anslutning.

  • timeouter för Anslut ion.

Felsökningssteg

  • Utvärdera hälsotillståndet för NAT-gatewayen genom att kontrollera datapath-tillgänglighetsmåttet.

  • Kontrollera måttet SNAT Anslut ion Count och dela upp anslutningstillståndet genom försök till och misslyckade anslutningar. Fler än noll misslyckade anslutningar indikerar SNAT-portöverbelastning eller når gränsen för antal SNAT-anslutningar för NAT-gateway.

  • Kontrollera att måttet för antal anslutningar ligger inom gränserna genom att verifiera måttet Totalt antal SNAT-Anslut joner. NAT-gateway stöder 50 000 samtidiga anslutningar per IP-adress till ett unikt mål och upp till 2 miljoner anslutningar totalt. Mer information finns i NAT Gateway-prestanda.

  • Kontrollera måttet för borttagna paket för eventuella paketförluster som överensstämmer med anslutningsfel eller hög anslutningsvolym.

  • Justera timerinställningarna för TCP (Transmission Control Protocol) vid behov. En timeruppsättning för inaktiv timeout som är högre än standardvärdet (4 minuter) håller fast vid flöden längre och kan skapa extra tryck på SNAT-portinventeringen.

Möjliga lösningar för SNAT-portöverbelastning eller uppnå samtidiga anslutningsgränser

  • Lägg till offentliga IP-adresser till din NAT-gateway upp till totalt 16 för att skala utgående anslutning. Varje offentlig IP-adress tillhandahåller 64 512 SNAT-portar och stöder upp till 50 000 samtidiga anslutningar per unik målslutpunkt för NAT-gateway.

  • Distribuera din programmiljö över flera undernät och ange en NAT-gatewayresurs för varje undernät.

  • Frigör SNAT-portinventering genom att minska tidsgränsen för TCP-inaktivitet till ett lägre värde. Tidsgränsen för TCP-inaktiv timeout kan inte ställas in under 4 minuter.

  • Överväg asynkrona avsökningsmönster för att frigöra anslutningsresurser för andra åtgärder.

  • Upprätta anslutningar till Azure PaaS-tjänster via Azure-stamnätet med Private Link. Privat länk frigör SNAT-portar för utgående anslutningar till Internet.

  • Om din undersökning är ofullständig öppnar du ett supportärende för ytterligare felsökning.

Kommentar

Det är viktigt att förstå varför SNAT-portöverbelastning uppstår. Se till att du använder rätt mönster för skalbara och tillförlitliga scenarier. Att lägga till fler SNAT-portar i ett scenario utan att förstå orsaken till efterfrågan bör vara en sista utväg. Om du inte förstår varför ditt scenario sätter press på SNAT-portinventeringen fördröjer tillägg av fler SNAT-portar genom att lägga till fler IP-adresser bara samma överbelastningsfel som programmet skalar. Du kanske maskerar andra ineffektiviteter och antimönster. Mer information finns i metodtips för effektiv användning av utgående anslutningar.

Möjliga lösningar för TCP-anslutningstimeouter

Använd TCP keepalives eller programlager keepalives för att uppdatera inaktiva flöden och återställa timeout-timern för inaktivitet. Exempel finns i .NET-exempel.

TCP keepalives behöver bara aktiveras från ena sidan av en anslutning för att hålla anslutningen vid liv från båda sidor. När en TCP keepalive skickas från ena sidan av en anslutning skickar den andra sidan automatiskt ett bekräftelsepaket (ACK). Timern för inaktiv timeout återställs sedan på båda sidor av anslutningen.

Kommentar

Att öka tidsgränsen för TCP-inaktivitet är en sista utväg och kanske inte löser rotorsaken till problemet. En lång timeout kan medföra fördröjning och orsaka onödiga fel med låg hastighet när tidsgränsen går ut.

Möjliga lösningar för UDP-anslutningstimeouter (User Datagram Protocol)

Tidsgränser för UDP-inaktivitet är inställda på 4 minuter och kan inte konfigureras. Aktivera UDP keepalives för båda riktningarna i ett anslutningsflöde för att underhålla långa anslutningar. När en UDP keepalive är aktiverad är den bara aktiv för en riktning i en anslutning. Anslutningen kan fortfarande vara inaktiv och tidsgränsen överskrids på andra sidan anslutningen. För att förhindra att en UDP-anslutning överskrider tidsgränsen för inaktivitet bör UDP keepalives aktiveras för båda riktningarna i ett anslutningsflöde.

Programlager keepalives kan också användas för att uppdatera inaktiva flöden och återställa tidsgränsen för inaktivitet. Kontrollera på serversidan vilka alternativ som finns för programspecifika keepalives.

Datapath-tillgängligheten minskar på NAT-gatewayen men inga anslutningsfel

Scenario

Tillgängligheten för NAT-gatewayen för datasökvägen sjunker men inga misslyckade anslutningar observeras.

Möjlig orsak

Tillfällig minskning av datasökvägstillgängligheten som orsakas av brus i datasökvägen.

Felsökningsanvisningar

Om du ser en minskning av tillgängligheten för datasökvägen utan någon effekt på din utgående anslutning kan det bero på att NAT-gatewayen hämtar tillfälligt brus i datasökvägen.

Konfigurera en avisering för att datapath-tillgängligheten ska avbrytas eller använda Azure Resource Health för att avisera om NAT Gateway-hälsohändelser.

Ingen utgående anslutning till Internet

Scenario

Du ser ingen utgående anslutning på NAT-gatewayen.

Möjliga orsaker

  • Felkonfiguration av NAT-gateway.

  • Internettrafiken omdirigeras bort från NAT-gatewayen och tvingad tunneltrafik till en virtuell installation eller till ett lokalt mål med ett VPN eller ExpressRoute.

  • NSG-regler (Network Security Group) har konfigurerats som blockerar Internettrafik.

  • TILLGÄNGLIGHETen för NAT-gatewaydatasökvägen har försämrats.

  • Dns-felkonfiguration (Domain Name System).

Felsökningsanvisningar

  • Kontrollera att NAT-gatewayen är konfigurerad med minst en offentlig IP-adress eller ett prefix och anslutet till ett undernät. NAT-gatewayen fungerar inte förrän en offentlig IP-adress och ett undernät är anslutet. Mer information finns i grundläggande konfiguration av NAT-gateway.

  • Kontrollera routningstabellen för det undernät som är kopplat till NAT-gatewayen. All 0.0.0.0/0-trafik som tvingas tunneltrafik till en virtuell nätverksinstallation (NVA), ExpressRoute eller VPN Gateway prioriteras framför NAT-gatewayen. Mer information finns i hur Azure väljer en väg.

  • Kontrollera om det finns några NSG-regler konfigurerade för nätverksgränssnittet på den virtuella datorn som blockerar internetåtkomst.

  • Kontrollera om tillgängligheten för NAT-gatewayen är i ett degraderat tillstånd. Se felsökningsvägledningen för anslutningsfel om NAT-gatewayen är i ett degraderat tillstånd.

  • Kontrollera DNS-inställningarna om DNS inte matchar korrekt.

Möjliga lösningar för förlust av utgående anslutning

OFFENTLIG IP-adress för NAT-gateway används inte för att ansluta utgående

Scenario

NAT-gatewayen distribueras i ditt virtuella Azure-nätverk, men oväntade IP-adresser används för utgående anslutningar.

Möjliga orsaker

  • Felkonfiguration av NAT-gateway.

  • Aktiv anslutning med en annan azure-metod för utgående anslutning, till exempel Azure Load balancer eller offentliga IP-adresser på instansnivå på virtuella datorer. Aktiva anslutningsflöden fortsätter att använda den tidigare offentliga IP-adress som tilldelades när anslutningen upprättades. När NAT-gatewayen distribueras börjar nya anslutningar använda NAT-gatewayen direkt.

  • Privata IP-adresser används för att ansluta till Azure-tjänster via tjänstslutpunkter eller Private Link.

  • Anslut till lagringskonton kommer från samma region som den virtuella dator som du upprättar en anslutning från.

  • Internettrafiken omdirigeras bort från NAT-gatewayen och tvingad tunneltrafik till en NVA eller brandvägg.

Så här felsöker du

  • Kontrollera att NAT-gatewayen har minst en offentlig IP-adress eller ett prefix associerat och minst ett undernät.

  • Kontrollera om någon tidigare utgående anslutningsmetod, till exempel en offentlig lastbalanserare, fortfarande är aktiv efter distributionen av NAT-gatewayen.

  • Kontrollera om anslutningar som görs till andra Azure-tjänster kommer från en privat IP-adress i ditt virtuella Azure-nätverk.

  • Kontrollera om Private Link eller tjänstslutpunkter är aktiverade för anslutning till andra Azure-tjänster.

  • Kontrollera att den virtuella datorn finns i samma region som Azure Storage när du upprättar en lagringsanslutning.

  • Kontrollera om den offentliga IP-adress som används för anslutningar kommer från en annan Azure-tjänst i ditt virtuella Azure-nätverk, till exempel en virtuell nätverksinstallation (NVA).

Möjliga lösningar för offentlig IP-adress för NAT-gateway som inte används för att ansluta utgående

  • Koppla en offentlig IP-adress eller ett prefix till NAT-gatewayen. Kontrollera att NAT-gatewayen är ansluten till undernät från samma virtuella nätverk. Kontrollera att NAT-gatewayen kan ansluta utgående.

  • Testa och lösa problem med virtuella datorer som håller kvar gamla SNAT IP-adresser från en annan utgående anslutningsmetod genom att:

    • Se till att du upprättar en ny anslutning och att befintliga anslutningar inte återanvänds i operativsystemet eller att webbläsaren cachelagrar anslutningarna. När du till exempel använder curl i PowerShell måste du ange parametern -DisableKeepalive för att tvinga fram en ny anslutning. Om du använder en webbläsare kan anslutningar också poolas.

    • Det är inte nödvändigt att starta om en virtuell dator i ett undernät som är konfigurerat för NAT-gateway. Men om en virtuell dator startas om rensas anslutningstillståndet. När anslutningstillståndet har tömts börjar alla anslutningar använda NAT-gatewayresursens IP-adress. Det här beteendet är en bieffekt av omstarten av den virtuella datorn och inte en indikator på att en omstart krävs.

    • Om du fortfarande har problem öppnar du ett supportärende för ytterligare felsökning.

  • Anpassade vägar som dirigerar 0.0.0.0/0-trafik till en NVA har företräde framför NAT-gatewayen för routning av trafik till Internet. Ta bort den anpassade vägen för 0.0.0.0.0/0-trafik som går till den virtuella installationen om du vill att NAT-gatewayen ska dirigera trafik till Internet i stället för NVA. Trafiken 0.0.0.0/0 återupptas med standardvägen till Internet och NAT-gatewayen används i stället.

Viktigt!

Innan du gör några ändringar i hur trafiken dirigeras bör du noga överväga routningskraven för din molnarkitektur.

  • Tjänster som distribueras i samma region som ett Azure Storage-konto använder privata Azure IP-adresser för kommunikation. Du kan inte begränsa åtkomsten till specifika Azure-tjänster baserat på deras offentliga utgående IP-adressintervall. Mer information finns i begränsningar för IP-nätverksregler.
  • Private Link- och tjänstslutpunkter använder de privata IP-adresserna för virtuella datorinstanser i ditt virtuella nätverk för att ansluta till Azure-plattformstjänster i stället för den offentliga IP-adressen för NAT-gatewayen. Använd Private Link för att ansluta till andra Azure-tjänster via Azure-stamnätet i stället för via Internet med NAT-gateway.

Kommentar

Private Link är det rekommenderade alternativet över tjänstslutpunkter för privat åtkomst till Azure-värdbaserade tjänster.

Anslut fel på det offentliga Internetmålet

Scenario

NAT-gatewayanslutningar till Internetmål misslyckas eller tidsgränsen överskrids.

Möjliga orsaker

  • Brandvägg eller andra trafikhanteringskomponenter på målet.

  • API-hastighetsbegränsning som införts av målsidan.

  • Volumetric DDoS-minskningar eller trafikformning på transportnivå.

  • Målslutpunkten svarar med fragmenterade paket.

Så här felsöker du

  • Verifiera anslutningen till en slutpunkt i samma region eller någon annanstans för jämförelse.

  • Genomför paketinsamling från käll- och målsidor.

  • Titta på antalet paket vid källan och målet (om tillgängligt) för att avgöra hur många anslutningsförsök som gjordes.

  • Titta på borttagna paket för att se hur många paket som släppts av NAT-gatewayen.

  • Analysera paketen. TCP-paket med fragmenterade IP-protokollpaket indikerar IP-fragmentering. NAT-gatewayen stöder inte IP-fragmentering och därför misslyckas anslutningar med fragmenterade paket.

  • Se till att den offentliga IP-adressen för NAT-gatewayen visas som tillåten på partnermål med brandväggar eller andra trafikhanteringskomponenter.

Möjliga lösningar för anslutningsfel på Internetmål

  • Kontrollera att den offentliga IP-adressen för NAT-gatewayen visas som tillåten på målet.

  • Om du skapar hög volym- eller transaktionshastighetstestning kan du utforska om en minskning av frekvensen minskar förekomsten av fel.

  • Om en minskning av antalet anslutningar minskar förekomsten av fel kontrollerar du om målet har nått sina API-hastighetsgränser eller andra begränsningar.

Anslut ionsfel på FTP-servern för aktivt eller passivt läge

Scenario

Du ser anslutningsfel på en FTP-server när du använder NAT-gateway med aktivt eller passivt FTP-läge.

Möjliga orsaker

  • Aktivt FTP-läge är aktiverat.

  • Passivt FTP-läge är aktiverat och NAT-gatewayen använder mer än en offentlig IP-adress.

Möjlig lösning för aktivt FTP-läge

FTP använder två separata kanaler mellan en klient och server, kommandot och datakanalerna. Varje kanal kommunicerar på separata TCP-anslutningar, en för att skicka kommandona och den andra för överföring av data.

I aktivt FTP-läge etablerar klienten kommandokanalen och servern upprättar datakanalen.

NAT-gatewayen är inte kompatibel med aktivt FTP-läge. Aktiv FTP använder ett PORT-kommando från FTP-klienten som talar om för FTP-servern vilken IP-adress och port som servern ska använda på datakanalen för att ansluta tillbaka till klienten. PORT-kommandot använder klientens privata adress, som inte kan ändras. Trafik på klientsidan SNATeds av NAT-gatewayen för internetbaserad kommunikation, så PORT-kommandot ses som ogiltigt av FTP-servern.

En alternativ lösning till aktivt FTP-läge är att använda passivt FTP-läge i stället. Men för att kunna använda NAT-gateway i passivt FTP-läge måste vissa överväganden göras.

Möjlig lösning för passivt FTP-läge

I passivt FTP-läge upprättar klienten anslutningar på både kommando- och datakanalerna. Klienten begär att servern svarar på en port i stället för att försöka upprätta en anslutning tillbaka till klienten.

Utgående passiv FTP fungerar inte för NAT-gateway med flera offentliga IP-adresser, beroende på ftp-serverkonfigurationen. När en NAT-gateway med flera offentliga IP-adresser skickar utgående trafik väljer den slumpmässigt en av sina offentliga IP-adresser för källans IP-adress. FTP misslyckas när data- och kontrollkanaler använder olika käll-IP-adresser, beroende på din FTP-serverkonfiguration.

Gör följande för att förhindra eventuella passiva FTP-anslutningsfel:

  1. Kontrollera att din NAT Gateway är kopplad till en enda offentlig IP-adress i stället för flera IP-adresser eller ett prefix.

  2. Kontrollera att det passiva portintervallet från NAT-gatewayen tillåts att passera brandväggar vid målslutpunkten.

Kommentar

Om du minskar mängden offentliga IP-adresser på NAT-gatewayen minskar SNAT-portinventeringen som är tillgänglig för utgående anslutningar och kan öka risken för SNAT-portöverbelastning. Överväg dina SNAT-anslutningsbehov innan du tar bort offentliga IP-adresser från NAT-gatewayen. Vi rekommenderar inte att du ändrar FTP-serverinställningarna för att acceptera kontroll- och dataplanstrafik från olika käll-IP-adresser.

Utgående anslutningar på port 25 blockeras

Scenario

Det går inte att ansluta utgående med NAT-gateway på port 25 för SMTP-trafik (Simple Mail Transfer Protocol).

Orsak

Azure-plattformen blockerar utgående SMTP-anslutningar på TCP-port 25 för distribuerade virtuella datorer. Det här blocket är att säkerställa bättre säkerhet för Microsofts partner och kunder, skydda Microsofts Azure-plattform och följa branschstandarder.

Använd en autentiserad SMTP-relätjänst för att skicka e-post från virtuella Azure-datorer eller från Azure App Service. Mer information finns i felsöka utgående SMTP-anslutningsproblem.

Mer vägledning om felsökning

Extra nätverksinsamlingar

Om din undersökning är ofullständig öppnar du ett supportärende för ytterligare felsökning och samlar in följande information för att kunna lösa problemet snabbare. Välj en enskild virtuell dator i nat-gatewayens konfigurerade undernät och utför följande tester:

  • Testa avsökningsportsvaret med hjälp ps ping av från en av de virtuella serverdelsdatorerna i det virtuella nätverket och registrera resultat (exempel: ps ping 10.0.0.4:3389).

  • Om inget svar tas emot i dessa ping-tester kör du en samtidig netsh spårning på den virtuella serverdelsdatorn och det virtuella nätverket testar den virtuella datorn medan du kör PsPing och stoppar sedan spårningen netsh .

Metodtips för utgående anslutning

Azure övervakar och driver sin infrastruktur med stor försiktighet. Tillfälliga fel kan dock fortfarande inträffa från distribuerade program och det finns ingen garanti för förlustfria överföringar. NAT-gateway är det bästa alternativet för att upprätta mycket tillförlitliga och motståndskraftiga utgående anslutningar från Azure-distributioner. Information om hur du optimerar programanslutningseffektiviteten finns i vägledningen senare i artikeln.

Använda anslutningspooler

När du slår samman dina anslutningar undviker du att öppna nya nätverksanslutningar för anrop till samma adress och port. Du kan implementera ett schema för anslutningspooler i ditt program där begäranden distribueras internt över en fast uppsättning anslutningar och återanvänds när det är möjligt. Den här konfigurationen begränsar antalet SNAT-portar som används och skapar en förutsägbar miljö. Anslut ionspooler bidrar till att minska svarstiden och resursutnyttjandet och i slutändan förbättra prestandan för dina program.

Mer information om hur du slår samman HTTP-anslutningar finns i Pool HTTP-anslutningar med HttpClientFactory.

Återanvända anslutningar

I stället för att generera enskilda, atomiska TCP-anslutningar för varje begäran konfigurerar du programmet för att återanvända anslutningar. återanvändning av Anslut resulterar i mer högpresterande TCP-transaktioner och är särskilt relevant för protokoll som HTTP/1.1, där återanvändning av anslutningar är standard. Återanvändning gäller för andra protokoll som använder HTTP som transport, till exempel REST.

Använda mindre aggressiv logik för återförsök

När SNAT-portar är uttömda eller programfel uppstår, orsakar aggressiva eller råstyrkeförsök utan fördröjning och back-off-logik att överbelastning uppstår eller kvarstår. Du kan minska efterfrågan på SNAT-portar med hjälp av en mindre aggressiv logik för återförsök.

Beroende på den konfigurerade tidsgränsen för inaktivitet har anslutningar inte tillräckligt med tid för att stänga och släppa SNAT-portar för återanvändning om återförsöken är för aggressiva.

Mer information och exempel finns i Återförsöksmönster.

Använd keepalives för att återställa tidsgränsen för utgående inaktivitet

Mer information om keepalives finns i TCP-timeout för inaktivitet.

När det är möjligt bör Private Link användas för att ansluta direkt från dina virtuella nätverk till Azure-plattformstjänster för att minska efterfrågan på SNAT-portar. Genom att minska efterfrågan på SNAT-portar kan du minska risken för SNAT-portöverbelastning.

Information om hur du skapar en privat länk finns i följande snabbstartsguider för att komma igång:

Nästa steg

Vi strävar alltid efter att förbättra våra kunders upplevelse. Om du stöter på NAT-gatewayproblem som inte har åtgärdats eller lösts av den här artikeln kan du ge feedback via GitHub längst ned på den här sidan.

Mer information om NAT-gateway finns i: