Ubuntu 18 curl kann Webseite nicht abrufen
Hallo Zusammen,
für ein Projekt richte ich JIRA und Confluence ein. Beide befinden sich hinter einem Nginx. So weit so gut. Die installation von JIRA lief reibungslos. Im Adminbereich bekam ich die Meldung, dass JIRA sich nicht selbst aufrufen kann.
Das wollte ich mit curl testen. Als ich
durchführte wurde die richtige öffentliche IP-Adresse angezeigt und dann blieb es bis zum timeout stehen.
Hier ein Auszug:
Das gleiche bekomme ich auch über Port 80
Wenn ich den Befehl von einem dritten Server ausführe, dann klappt es.
Hier ein Auszug:
Der Server ist "ge-NAT-et" und die Hauptfirewall ist erstmal offen gestellt.
Habe ebenfalls ufw deaktiviert und iptables auf "Durchlass" gestellt, da ich dachte, dass es daran liegen würde.
Hier ein Auszug:
Aktuell habe keinen Ansatz wonach ich da noch suchen könnte. Was habe ich übersehen bzw. was kann noch machen um das Problem einzugrenzen.
Ich bedanke mich im Voraus.
Brizlop
für ein Projekt richte ich JIRA und Confluence ein. Beide befinden sich hinter einem Nginx. So weit so gut. Die installation von JIRA lief reibungslos. Im Adminbereich bekam ich die Meldung, dass JIRA sich nicht selbst aufrufen kann.
Das wollte ich mit curl testen. Als ich
curl -v https://<sub>.<domain>.<tld>
durchführte wurde die richtige öffentliche IP-Adresse angezeigt und dann blieb es bis zum timeout stehen.
Hier ein Auszug:
* Rebuilt URL to: https://<sub>.<domain>.<tld>/
* Trying xxx.xxx.xxx.xxx...
* TCP_NODELAY set
* connect to xxx.xxx.xxx.xx port 443 failed: Connection timed out
* Failed to connect to projekt.flexdemo.eu port 443: Connection timed out
* Closing connection 0
curl: (7) Failed to connect to projekt.flexdemo.eu port 443: Connection timed out
Das gleiche bekomme ich auch über Port 80
Wenn ich den Befehl von einem dritten Server ausführe, dann klappt es.
Hier ein Auszug:
* Rebuilt URL to: https://<sub>.<domain>.<tld>/
* Trying xxx.xxx.xxx.xxx...
* TCP_NODELAY set
* Connected to projekt.flexdemo.eu (xxx.xxx.xxx.xxx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=<sub>.<domain>.<tld>
* start date: Apr 30 13:58:37 2019 GMT
* expire date: Jul 29 13:58:37 2019 GMT
* subjectAltName: host "<sub>.<domain>.<tld>" matched cert's "<sub>.<domain>.<tld>"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: <sub>.<domain>.<tld>
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.14.0 (Ubuntu)
< Date: Thu, 02 May 2019 10:21:15 GMT
< Content-Type: text/html
< Content-Length: 612
< Last-Modified: Tue, 30 Apr 2019 14:44:40 GMT
< Connection: keep-alive
< ETag: "5cc85f58-264"
< Accept-Ranges: bytes
<
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
[http://nginx.org/ nginx.org].<br/>
Commercial support is available at
[http://nginx.com/ nginx.com].</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
* Connection #0 to host <sub>.<domain>.<tld> left intact
Der Server ist "ge-NAT-et" und die Hauptfirewall ist erstmal offen gestellt.
Habe ebenfalls ufw deaktiviert und iptables auf "Durchlass" gestellt, da ich dachte, dass es daran liegen würde.
Hier ein Auszug:
iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Aktuell habe keinen Ansatz wonach ich da noch suchen könnte. Was habe ich übersehen bzw. was kann noch machen um das Problem einzugrenzen.
Ich bedanke mich im Voraus.
Brizlop
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 447033
Url: https://administrator.de/contentid/447033
Ausgedruckt am: 25.11.2024 um 05:11 Uhr
12 Kommentare
Neuester Kommentar
Habe ein Traceroute auf den Zielserver ausgeführt mit wenig Erkenntnis.
Zeigt doch ganz klar das der Zielserver netzwerktechnisch gar nicht nicht erreichbar ist. *** bedeutet keinerlei Antwort.Da ist wohl wirklich irgendwo eine Firewall dazwischen die Port 80, 443 und ICMP (Ping, Traceroute) oder auch sämtlichen Traffic blockiert.
Sieht eher nach letzterem aus !
Sofern sich beide Komponenten in unterschiedlichen IP Netzen befinden kann dies auch eine fehlende Route sein zw. den Netzen.
Um ganz sicher zu sein kannst du mit nmap überhaupt erstmal checken ob dein Webserver erreichbar ist über TCP 80 und 443.
NMAP (apt install nmap) ist da dein bester Freund
nmap -p80,443 <sub>.<domain>.<tld>
Oder mit etwas mehr Detail:
nmap -sS -O -p80,443 <sub>.<domain>.<tld>
bekam ich die Meldung, dass JIRA sich nicht selbst aufrufen kann.
Moooment... ist das ein Server der "intern" (RFC1918 IP) steht, aber per NAT/Port-FW von "extern" (per öffentlicher IP/TLD) erreichbar ist?Und der Aufruf soll von intern über die Public IP/TLD erfolgen? Dann kann dein Router evtl. kein Haipin Routing, bzw hat das nicht erlaubt.
Aber schon interessant, dass von außen alles klappt nur intern nicht.
Hört sich nach Hairpin-NAT (NAT-Loopback) Problem an ... Entweder intern Split-DNS machen oder dem Server/Router Hairpin-NAT beibringen.How does NAT reflection (NAT loopback) work
Und der Aufruf soll von intern über die Public IP/TLD erfolgen?
Richtig ! Das ist dann ein Hairpin NAT Problem das der Router des TO nicht richtig handeln kann. Vermutlich ne billige Plastikbox oder fehlerhaft konfiguriert ?!https://wiki.mikrotik.com/wiki/Hairpin_NAT