Search

JensB 16.03.2017 - 15:10

Server nicht erreichbar trotz „Box is reachable from outside“

Moin,

Disclaimer: ich habe vergleichsweise wenig IT-Kenntnisse – bis gestern hatte ich von ssh, putty oder dyndns noch nie in meinem Leben etwas gehört. Ich hoffe man kann mir trotzdem helfen!

Das Problem: Ich habe gestern versucht, nach der Anleitung (unter https://support.protonet.info/de/faq/cat-faq/kundenspezifische-anpassungen/#dyndns-einrichten) unseren Maya-Server auf eine dyndns-Adresse umzustellen. Ich bin allen Schritten gefolgt, leider ist der Server trotzdem nicht unter der neuen Adresse erreichbar. Ich habe die Schritte aus der Anleitung zur Umstellung mehrfach wiederholt und auch sonst alle Einstellungen mehrfach überprüft. Der Server ist auch von anderen Geräten mit anderen Browsern nicht erreichbar (Windows 10 mit Firefox, Chrome und Edge, Mac mit Safari alles getestet).

Ich habe putty für den ssh-Zugriff auf den Server benutzt. Soweit ich das sehen kann hat letsencrypt auch funktioniert und meldet u.a. „your box is reachable from the outside via [dyndns-Adresse]“. Die dyndns-Adresse ist von no-ip.com, da sieht für den Laien auch alles so aus als würde es funktionieren, das entsprechend DUC-Programm läuft im Hintergrund und sieht auch normal aus. Die Portweiterleitungen für 443 und 80 habe ich im Router (Speedport W 921v) eingerichtet.

Was muss ich tun, damit der Server erreichbar ist?

Hier das log vom ssh-Zugriff:

Normal
0

21

false
false
false

DE
X-NONE
X-NONE

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:“Normale Tabelle“;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:““;
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin-top:0cm;
mso-para-margin-right:0cm;
mso-para-margin-bottom:8.0pt;
mso-para-margin-left:0cm;
line-height:107%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:“Calibri“,“sans-serif“;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:“Times New Roman“;
mso-bidi-theme-font:minor-bidi;
mso-fareast-language:EN-US;}

login as: protonet
protonet@192.168.1.107’s password:
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.13.0-35-generic x86_64)

* Documentation:  https://help.ubuntu.com/

System information as of Thu Mar 16 14:30:01 CET 2017

System load:    0.47      Users logged in:       0
Usage of /home: unknown   IP address for wlan0:  10.42.0.1
Memory usage:   32%       IP address for br0:    192.168.1.107
Swap usage:     0%        IP address for virbr0: 10.44.0.1
Processes:      309

Graph this data and manage this system at https://landscape.canonical.com/

Last login: Thu Mar 16 11:57:07 2017 from climb1

protonet@[neue dns-Adresse] soul2 (stable/101)
~ $ custom_nodename [neue dns-Adresse] [neue dns-Adresse]

protonet@[neue dns-Adresse] soul2 (stable/101)
~ $ letsencrypt
— Custom domain [neue dns-Adresse] correctly set at /etc/protonet/nodenames/                                                                                                                     custom
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100    12    0    12    0     0    114      0 –:–:– –:–:– –:–:–   324
— Box is reachable from the outside via [neue dns-Adresse] — Using jensbusch@climb-hamburg.de for letsencrypt registration.
— OK! Grabbing new SSL certificate via letsencrypt
ln: failed to create symbolic link `/etc/letsencrypt/letsencrypt‘: File exists
Cloning into ‚/tmp/letsencrypt’…
remote: Counting objects: 44382, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 44382 (delta 3), reused 0 (delta 0), pack-reused 44372
Receiving objects: 100% (44382/44382), 13.01 MiB | 2.74 MiB/s, done.
Resolving deltas: 100% (31732/31732), done.
Note: checking out ‚v0.6.0‘.

You are in ‚detached HEAD‘ state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name

HEAD is now at 8e742fa… Release 0.6.0
ok: down: /home/protonet/dashboard/shared/services/enabled/nginx: 1s, normally up
* Stopping haproxy haproxy                                              [ OK ] Checking for new version…
Upgrading certbot-auto 0.6.0 to 0.7.0…
Replacing certbot-auto…
Requesting root privileges to run certbot…
/home/protonet/.local/share/letsencrypt/bin/letsencrypt certonly –standalone                                                                                                                     

-d [neue dns-Adresse] –email jensbusch@climb-hamburg.de –agree-tos –force-renew

IMPORTANT NOTES:
– Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/[neue dns-Adresse]/fullchain.pem. Your cert
will expire on 2017-06-14. To obtain a new or tweaked version of
this certificate in the future, simply run letsencrypt-auto again.
To non-interactively renew *all* of your ceriticates, run
„letsencrypt-auto renew“
– If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let’s Encrypt:   https://letsencrypt.org/donate
Donating to EFF:                    https://eff.org/donate-le

— Successfully generated certificate.
— Certificate files exist.
ok: run: /home/protonet/dashboard/shared/services/enabled/nginx: (pid 28792) 0s
* Starting haproxy haproxy                                                                                                                                                                   [ OK ] — Enabling cron job to renew certificate once in a while.

8 answers

Micha 16.03.2017 - 15:25

Hallo Jens,

toll, dass Du das einfach mal versucht hast 🙂

Hast Du das PS meiner Emailantwort gesehen?
Dein Server ist für uns über seine neue Adresse von außen erreichbar. Du hast daher offensichtlich nur ein internes Routingproblem, oder musst einfach warten, bis die DNS-Server sich upgedated haben.

Schau doch mal selbst von Deinem Handy aus, statt aus dem gleichen Netzwerk, wie die Box steht. Dann wirst Du ggf. auch erfolgreich zugreifen können.

Herzliche Grüße
Micha

JensB 16.03.2017 - 15:34

Moin Micha,

danke für die schnelle Antwort! Dein PS hatte ich tatsächlich überlesen und du hast Recht: bei mir funktioniert es auf dem Handy sobald ich das WLAN ausmache. Nun können wir den Server zwar intern einfach über die IP-Adresse erreichen, trotzdem würde ich es gerne hinbekommen, dass er auch intern über die .ddns-Adresse erreichbar ist. Wie lange dauert es denn, bis sich die DNS-Server updaten und wo müsste ich nach dem internen Routing-Problem suchen?

Best,
Jens

Micha 16.03.2017 - 15:37

Hallo Jens,

warte erstmal bis morgen entspannt ab, denn da kannst Du eh nichts beschleunigen.
Von intern solltet ihr eh über die interne IP-Adresse zugreifen, damit ihr nicht ohne Grund über das Internet auf die Box im eigenen Netzwerk zugreift und euch somit selbst ausbremst.

Herzliche Grüße
Micha

msch 17.03.2017 - 13:03

Wie Micha schon schreibt, intern immer über die (interne) IP zugreifen.

Alle Daten müssen sonst raus und wieder rein, das erhöht den Traffic über die Internetverbindung und auch den internen Traffic.

Solltet ihr das aus Komfortgründen so wünschen, könnt ihr über eine lokale hosts Datei regeln (dort wird dann die dyndns-Adresse mit der internen IP verknüpft). 😉

https://de.wikipedia.org/wiki/Hosts_(Datei)

Damit bleibt der Traffic intern.

Micha 17.03.2017 - 16:50

+1

tien 20.03.2017 - 13:36

Moin JensB,

ich habe ein Speedport W724V und dort einen Rasp-Pi im Netzwerk.
Da kann ich intern nicht über die DynDNS auf den Pi zugreifen sondern nur über die IP.
Bei mir liegt es daran, dass der Router NAT Loopback nicht unterstützt. Ich vermute fast es ist bei deiner Speedport das gleiche Problem.
Es sieht auch nicht so aus als würde die Telekom das ändern wollen.
Ein warten bis die Host-Datei des Routers sich aktualisiert wird bringt (zumindest mir) leider nicht viel. Ich muss mit 2 Adressen leben oder den Router wechseln…

JensB 20.03.2017 - 14:50

Moin,

erstmal danke für die Antworten! Ich denke mit dem Zugriff über die IP-Adresse können wir auch leben, nun ist eine andere Frage aufgekommen: Wenn man sich jetzt auf dem Server einloggen will kommt eine Nachricht von (ich glaube) Firefox, dass die Verbindung nicht sicher sei und die Zugangsdaten auf dieser Seite in falsche Hände geraten können. (Die gleiche Nachricht bekomme ich auch, wenn ich mich über Firefox beim Router einlogge über speedport.ip). Müssen wir uns da irgendwelche Sorgen machen oder ist das normal? Die Verbindung ist in diesem Fall ja komplett intern, braucht man da einfach keine sichere Verbindung?

Best,
Jens

Micha 20.03.2017 - 17:44

Hallo Jens,

„Die Verbindung ist in diesem Fall ja komplett intern, braucht man da einfach keine sichere Verbindung?“
Genau das ist der Knackpunkt: Wenn Du auf interne Adressen via https zuzugreifen, dann ist das Zertifikat für diese internen Adressen nicht zuständig und somit wird die Warnung angezeigt.
Es besteht also kein Grund zur Sorge.

In der Regel sind interne Verbindungen sicher, wenn man sich in seinem eigenen, abgeschotteten Netzwerk befindet.

Herzliche Grüße
Micha