Nätverksanslutningstest network-connectivity-test
Nätverksanslutningstestet är ett diagnostikverktyg från Cloud Manager som gör att du kan validera konfigurationen av avancerat nätverk och VPN innan du aktiverar avancerat nätverk i dina miljöer och innan du publicerar. Använd den för att verifiera att värdarna och portarna som AEM måste nå, inklusive interna eller privata slutpunkter, är tillgängliga via samma anslutningsväg som Advanced Networking kommer att använda.
Testet körs från utgångens proxyinfrastruktur som tillhör programmets avancerade nätverkskonfiguration, inte från en författare- eller publiceringsplats. Den använder samma utgående nätverkssökväg som AEM använder när Advanced Networking är aktivt. Den designen är särskilt användbar för VPN -scenarier: du kan bekräfta DNS-matchning, nätverksroutning, brandväggsregler och tjänsttillgänglighet för privata eller lokala system innan du publicerar.
Bakgrund om etablering av VPN, dedikerad IP-adress eller flexibel portutgång finns i Konfigurera avancerat nätverk för AEM as a Cloud Service.
När det här verktyget ska användas when-to-use
- När Avancerat nätverk har skapats på program-nivå och före eller när det aktiverats i miljöer.
- Om du vill verifiera VPN-anslutningen till privata eller lokala system använder du (till exempel interna värdnamn eller privata IP-adresser).
- För att begränsa DNS-problem jämfört med brandvägg eller routningsproblem när en tjänst inte svarar som förväntat.
Förutsättningar prerequisites
- Ett Cloud Manager-program.
- En avancerad nätverksinfrastruktur har redan skapats för programmet (se Konfigurera avancerat nätverk).
Så här kör du ett test how-to-run-a-test
-
Logga in på Cloud Manager på my.cloudmanager.adobe.com och öppna din organisation och ditt program.
-
Öppna fliken Miljö för programmet. Välj Nätverksinfrastrukturer i det vänstra sidfältet.
-
På sidan Nätverksinfrastrukturer letar du reda på din infrastruktur i tabellen. Välj antingen en rad för att öppna testupplevelsen eller öppna menyn för radåtgärder (
) och välj Test.
-
Dialogrutan Nätverkstestning öppnas. Ange Värd och Port, välj Test och granska DNS-upplösning, öppen port, HTTP-anslutning och nåbarhet i resultatområdet. Valfria åtgärder som Kopiera till Urklipp och senaste testhistorik visas i dialogrutan. Mer information om hur du tolkar varje avsnitt finns i Förstå resultat.
Indatafält input-fields
internal-api.example.com, 10.0.1.50443Steg test-steps
- Ange Värd och Port.
- Välj Testa. Resultaten visas vanligtvis inom några sekunder.
- Valfritt: Använd Kopiera till Urklipp för att hämta det fullständiga JSON-resultatet (användbart för supportärenden).
- Senaste tester kan listas för snabbkörningar.
Förstå resultat understanding-results
Verktyget rapporterar flera dimensioner. De beskriver tillsammans om målet kan nås från avancerade nätverk och hur HTTP-kompatibla kontroller fungerar.
DNS-matchning dns-resolution
ips: ["10.0.1.50"]error: "DNS resolution error: ..."Öppna port port-open
Yes / trueNo / falseHTTP-anslutning http-connectivity
Ett försök till HTTP/HTTPS-begäran görs på varje port. Verktyget försöker alltid HTTPS först och återgår sedan till HTTP. Om inget av dem fungerar mappas resultatet till ett kort, läsbart error -meddelande (se tabellen nedan).
Slutförda utdata
protocol: "https", status_code: 200, reason: "200 OK"protocol: "http", status_code: 301, reason: "301 Moved Permanently"Klassificerade felutdata
"Not an HTTP/HTTPS service""The service appears to be a non-HTTP service (e.g., database, message queue, or custom TCP). Use the port_open and reachability fields to verify connectivity.""Connection refused""The port is not accepting connections. Verify the service is running and listening on this port.""Connection timed out""The connection timed out. Check firewall rules and network routing.""No IPs resolved for host"200, 301, 302, 403, 404 eller 500) är en framgångssignal för anslutning, vilket betyder att nätverkssökvägen fungerar. Statuskoden återspeglar tjänstens egna svar, inte den övergripande nätverkshälsan. För icke-HTTP-tjänster anger verktyget Inte en HTTP/HTTPS-tjänst. Använd Öppna port och Tillgänglighet som tillförlitliga indikatorer för de tjänsterna.Nå reachability
Flera DNS-lösningar multiple-dns-resolvers
Om din avancerade nätverksinfrastruktur definierar fler än en DNS-matchare:
- När alla matchare returnerar identiska resultat visas ett enskilt konsoliderat-resultat med etiketten
default. - När matchare returnerar olika resultat visas resultatet för varje lösare separat (märkt
resolver_1,resolver_2och så vidare), med IP-adressen för lösaren, så att du kan se vilken DNS-server som orsakar inkonsekvensen.
Felsökning troubleshooting
I följande scenarier paras vad du kan se i verktyget med steg för att begränsa orsaken. Fullständig Kopiera till Urklipp JSON som illustrerar samma situationer finns i Exempelutdata.
DNS-matchningen misslyckades dns-failed
Utdata
Värdnamnet löstes inte med dina avancerade DNS-inställningar för nätverk, så verktyget kan inte testa porten. I resultatvyn visar DNS-matchning en felsträng och NåNå rapporterar att DNS misslyckades:
DNS Resolution: error: "DNS resolution error: ..."
Reachability: "Unreachable: DNS resolution failed"
Rekommendationer
- Kontrollera att värdnamnet är korrekt. Kontrollera om det finns tecken och att du använder den avsedda DNS-zonen (fel zon är ett vanligt fel).
- Kontrollera att dina DNS-matchare (de som konfigurerats i nätverksinfrastrukturen) kan nås från CIDR-intervallet för avancerat nätverk (samma adressutrymme som verktyget och AEM använder för utgående kontroller). Om du förlitar dig på privat DNS måste dessa servrar vara tillgängliga via VPN-tunneln eller inom det nätverksadressutrymme som routning exponerar för avancerad nätverksbearbetning.
- Verifiera att dina konfigurerade DNS-servrar kan matcha värdnamnet - Avancerade nätverk använder endast de matchare som definierats i nätverksinfrastrukturkonfigurationen, inte offentlig DNS (till exempel
8.8.8.8). Om din interna DNS inte har någon post för det värdnamnet misslyckas matchningen. - För VPN-inställningar: Bekräfta att IP-adresserna för DNS-servern finns i VPN-adressutrymmet (fjärrnätverkets CIDR-adress är inbyggd för). Det går inte att nå lösningar på ett undernät som inte dirigeras via VPN-tunneln från avancerade nätverk.
DNS fungerar men porten är inte tillgänglig dns-ok-port-blocked
Utdata
Verktyget kan matcha värden, men TCP till porten fungerar inte. En sammanfattning ser ofta ut så här:
DNS Resolution: ips: ["10.0.1.50"]
Port Open: No
Reachability: "Unreachable: Port not accessible"
Rekommendationer
- Granska brandväggen och reglerna för tillåten lista i måltjänsten - inkommande trafik från CIDR-intervallet (och IP-adresser för utgångar som används av AEM) måste vara tillåtna. Om du använder ett VPN-nätverk inkluderar du CIDR-filer för fjärrnätverk när designen kräver det.
- Kontrollera att tjänsten körs och lyssnar på den värd och port som du angav i testet.
- För VPN-inställningar: Bekräfta att tunneln är uppe, routningen når målundernätet och måladressen finns i fjärrnätverkets adressutrymme som överförs via VPN.
- Granska nätverkssäkerhetsgrupper (NSG), säkerhetsregler eller motsvarande som kan blockera porten mellan avancerat nätverk och målet i din infrastruktur.
- Bekräfta portnumret - kontrollera att processen lyssnar på den port du testar.
Testet kan nås, men AEM kan inte ansluta reachable-but-aem-fails
Utdata
Anslutningskontrollen lyckas. En komprimerad sammanfattning ser ofta ut så här:
Port Open: Yes
Reachability: "Reachable"
Detta innebär att sökvägen från Advanced Networking till den värddator och port som du testade är öppen. Det garanterar inte att AEM-programtrafik använder den sökvägen: när koden körs kanske tjänstloggarna fortfarande inte visar några begäranden från IP-adressen för utgångar som du förväntar dig.
Rekommendationer
- Programkoden måste vara konfigurerad att använda proxyn. Anslutningstestet bevisar att nätverkssökvägen fungerar, men AEM måste uttryckligen vidarebefordra begäranden via Advanced Networking proxy (till exempel via miljövariabeln
AEM_PROXY_HOST). Om koden skapar direkta anslutningar utan proxyn går trafiken inte genom infrastrukturen för avancerade nätverk. - Granska proxyinställningarna i dina HTTP-klienter - HTTP-klienterna bör använda samma proxykonfiguration (
AEM_PROXY_HOST) och portvidarebefordran där det är tillämpligt). - Verifiera portvidarebefordringskonfigurationen för avancerat nätverk på miljönivå: i
portForwardsmåste varje post mappaportOrigtillportDestpå den högra målvärden.portOrigär den port som din AEM-programkod ansluter till när den öppnar den utgående anslutningen via proxyn.portDestär den faktiska porten på måltjänsten där fjärrprocessen lyssnar. målvärddatorn är värdnamnet eller adressen för tjänsten som används i framåtriktningen. Alla tre måste matcha hur ditt program är skrivet för att kunna ansluta. - Kontrollera
nonProxyHosts. Om målvärden finns där, begär att ska hoppa över proxyn för den värden och inte följa den avancerade nätverkssökvägen som du har verifierat.
HTTP visar ett fel men porten är öppen http-error-port-open
Utdata
TCP lyckades, men HTTP/HTTPS-avsökningen rapporterar fortfarande ett fel. En sammanfattning ser ofta ut så här:
Port Open: Yes
HTTP Connectivity: error: "Connection error: ..." or "Both HTTPS and HTTP failed. ..."
Reachability: "Reachable"
Rekommendationer
- Tjänsten kanske inte talar HTTP eller HTTPS - till exempel rå TCP, gRPC eller något annat protokoll. HTTP-avsökningen kan misslyckas medan
Port open: YesochReachability: Reachablefortfarande bekräftar att nätverkssökvägen fungerar. Använd dessa fält som källa för sanning för icke-HTTP-tjänster. - Undersök TLS och certifikatkonfigurationen. Om HTTPS misslyckas men HTTP lyckas (anges ibland av en anteckning som
HTTPS failed, HTTP succeeded), kan tjänsten ha certifikatproblem eller bara erbjuda HTTP på den porten.
Timeout för begäran timeout
Utdata
{ "error": "Request timeout" }
Rekommendationer
- Tillåt tjänstens svarstid - kontrollen använder en timeout på 5 sekunder. Målgrupper som svarar långsammare än det gör att det tar längre tid, även när de i övrigt är hälsosamma.
- Konto för nätverksfördröjning. På VPN-anslutningar kan hög latens eller en ohälsosam tunnel föra den runda resan över gränsen. Granska tunnelstatus och routning.
- Kör testet igen. Engångsfel i nätverk kan skapa en timeout som inte återkommer.
Exempelutdata example-outputs
HTTPS-test lyckades (t.ex. internt API på port 443) example-output-successful-https
{
"resolvers": [
{
"name": "default",
"dns_resolution": {
"ips": ["10.0.1.50"]
},
"port_open": true,
"http_connectivity": {
"protocol": "https",
"status_code": 200,
"reason": "200 OK"
},
"reachability": "Reachable"
}
]
}
Tjänsttestet som inte är HTTP lyckades (t.ex. databasen på port 5432) example-output-successful-non-http
{
"resolvers": [
{
"name": "default",
"dns_resolution": {
"ips": ["10.0.1.50"]
},
"port_open": true,
"http_connectivity": {
"error": "Not an HTTP/HTTPS service",
"note": "The service appears to be a non-HTTP service (e.g., database, message queue, or custom TCP). Use the port_open and reachability fields to verify connectivity."
},
"reachability": "Reachable"
}
]
}
DNS-matchningsfel example-output-dns-resolution-failure
{
"resolvers": [
{
"name": "default",
"dns_resolution": {
"error": "DNS resolution error: dial udp 10.0.0.2:53: i/o timeout"
},
"port_open": false,
"http_connectivity": {
"error": "DNS resolution failed"
},
"reachability": "Unreachable: DNS resolution failed"
}
]
}
Porten är inte tillgänglig (brandväggen/tjänsten nere) example-output-port-not-accessible
{
"resolvers": [
{
"name": "default",
"dns_resolution": {
"ips": ["10.0.1.50"]
},
"port_open": false,
"http_connectivity": {
"error": "Connection error: dial tcp 10.0.1.50:443: i/o timeout"
},
"reachability": "Unreachable: Port not accessible"
}
]
}
Viktiga anteckningar important-notes
Vad det här testet inte gör what-this-test-does-not-do
- Testet körs inte inifrån en AEM-författare eller publiceringsruta. Det körs från utressens proxyinfrastruktur. Detta validerar nätverkslagret, inte proxykonfigurationen på programnivå i koden.
- Proxyinställningarna för ditt AEM-program valideras inte. Även om resultatet är
Reachablemåste AEM-koden fortfarande konfigureras att använda proxyn. - Det verifierar inte portvidarebefordrningskonfigurationen på miljönivå separat. Den testar råanslutning från infrastrukturens väg.
- Det skickar inte anpassade nyttolaster. HTTP-tester utfärdar en grundläggande
GET-begäran till/.
Svarstid response-time
- Normalt: cirka 2 till 3 sekunder.
- Maximalt: ungefär fem sekunders timeout.
- Alla DNS-matchare och anslutningskontroller körs parallellt.
HTTP jämfört med icke-HTTP-tjänster http-vs-non-http-services
Verktyget försöker upprätta en HTTP/HTTPS-anslutning på alla portar. För icke-HTTP-tjänster (t.ex. PostgreSQL på port 5432, MySQL på 3306, SFTP på 22, Redis på 6379) kan HTTP-kontrollen misslyckas med ett anslutningsfel - detta förväntas. Använd Port open och Reachability för att bekräfta anslutningen för dessa tjänster.