12
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 outDas 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 intactDer 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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 447033
Url: https://administrator.de/contentid/447033
Printed on: April 18, 2024 at 23:04 o'clock
12 Comments
Latest comment
Moin,
was sagt denn ein traceroute auf den Zielserver? Sieht aus also würde noch eine FW dazwischen hängen die blockt, oder das Routing passt nicht.
/EDIT: FW am Zielserver passt auch?
lg,
Slainte
was sagt denn ein traceroute auf den Zielserver? Sieht aus also würde noch eine FW dazwischen hängen die blockt, oder das Routing passt nicht.
/EDIT: FW am Zielserver passt auch?
lg,
Slainte
Danke für den Tipp.
Habe ein Traceroute auf den Zielserver ausgeführt mit wenig Erkenntnis.
(Die * habe ich nicht ersetzt)
Habe ein Traceroute auf den Zielserver ausgeführt mit wenig Erkenntnis.
traceroute to <sub>.<domain>.<tld> (xxx.xxx.xxx.xxx), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *(Die * habe ich nicht ersetzt)
Ich bin jetzt nicht der Pro in Sachen FW unter Linux.
Habe ufw deaktiviert und iptables so eingerichtet:
Habe ufw deaktiviert und iptables so eingerichtet:
ptables -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
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>
Danke !
Ich denke auch das es an den FW liegt. Aber schon interessant, dass von außen alles klappt nur intern nicht.
Hier ist das Ergebnis:
Ich denke auch das es an den FW liegt. Aber schon interessant, dass von außen alles klappt nur intern nicht.
Hier ist das Ergebnis:
nmap -sS -O -p80,443 <sub>.<domain>.<tld>
Starting Nmap 7.60 ( https://nmap.org ) at 2019-05-02 13:40 CEST
Nmap scan report for <sub>.<domain>.<tld> (xxx.xxx.xxx.xxx)
Host is up (0.00023s latency).
PORT STATE SERVICE
80/tcp filtered http
443/tcp filtered https
Too many fingerprints match this host to give specific OS details
OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 2.79 seconds 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
1
Ist der zu erreichende Server zufällig eine interne Ressource welche somit über die externe Adresse am WAN Gateway erreicht werden soll?
Das würde hairpin-NAT oder split-DNS nötig machen.
Das würde hairpin-NAT oder split-DNS nötig machen.
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
Genau! SlainteMhath hat es richtig beschrieben.
Habe mich mit den Netzverantwortlichen in Verbindung gesetzt und er wird dieses prüfen.
Melde mich sobald ich Feedback bekommen habe.
Vielen Danke an Alle für eure nützliche Unterstützung !
Lieben Gruß
Brizlop
Melde mich sobald ich Feedback bekommen habe.
Vielen Danke an Alle für eure nützliche Unterstützung !
Lieben Gruß
Brizlop
Melde mich sobald ich Feedback bekommen habe.
Wir sind gespannt...! 
