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

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: 13.11.2024 um 07:11 Uhr

12 Kommentare

Neuester Kommentar

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

Danke für den Tipp.
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
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *

(Die * habe ich nicht ersetzt)

Ich bin jetzt nicht der Pro in Sachen FW unter Linux.

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:

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

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.

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