Ich hoste einige Websites/Dienste wie Jenkins auf einem Server, den ich zu Hause habe. Ich möchte, dass sie sowohl vom Internet als auch vom Intranet über einen öffentlichen Domänennamen zugänglich sind. Dafür habe ich einen NoIP-Domänennamen registriert, der auf meine (dynamische) öffentliche IPv4 verweist. Der Router hat Portweiterleitungen konfiguriert, um einen Port per NAT auf meinen Server zu übertragen.
Das alles hat gut funktioniert, bis ich letztes Wochenende den Netzanbieter und damit auch meinen Router gewechselt habe.
Jetzt kann ich mit dem öffentlichen Domänennamen, der in meine öffentliche IP aufgelöst wird, keine Verbindung vom Intranet zu meinen Sites herstellen.
Was ich getestet habe:
- Das Pingen des öffentlichen Domänennamens aus dem Intranet löst die richtige öffentliche IP auf -> kein DNS-Problem
- Auf die Websites kann über das Internet zugegriffen werden, wenn der öffentliche Domänenname (oder die IP-Adresse) und der richtige Port verwendet werden.
- Sites sind NICHT vom Intranet aus zugänglich, wenn der öffentliche Domänenname (oder die IP) und der richtige Port verwendet werden. In diesem Fall zeigt der Browser einen Timeout-Fehler bei der Netzwerkverbindung an (ERR_CONNECTION_TIMED_OUT).
- Auf die Sites kann vom Intranet aus zugegriffen werden, wenn die interne IP-Adresse und der richtige Port verwendet werden (wie in der Portweiterleitungsregel für das Ziel angegeben).
Welche Netzwerkkonfiguration muss am Router geändert werden, damit dieser dies korrekt vom Intranet aus weiterleitet?
Routerkonfiguration:
Die Firewall ist derzeit deaktiviert, um sicherzustellen, dass sie keine Probleme verursacht:
Dies ist eine Kopie meines Beitrags hier:https://networkengineering.stackexchange.com/posts/59290
Antwort1
Dies ist größtenteils eine auf Vermutungen basierende Antwort, die auf dem häufigsten Problem dieser Art basiert. Um jedoch ganz sicher zu sein, müssen Sie tatsächlich untersuchen, was der Server sieht (Wireshark/tcpdump sind gute Tools).
DNAT (Portweiterleitung) innerhalb desselben Subnetzes ist sehr problematisch, da der Rückweg vom Server zum Client normalerweise den Router umgeht und keine Möglichkeit besteht, das NAT dieses Rückverkehrs aufzuheben.
Um dies zu umgehen, verfügen einige (aber nicht alle) Router über eine Option „NAT Loopback“ oder „NAT Hairpin“. Soweit ich weiß, führt diese Option zusätzlich SNAT für alle Verbindungen aus und schreibt dieKlientIP-Adresse und dem Server vorgaukeln, dass alle Verbindungen vom Router selbst kommen.
Ohne Loopback/Hairpin erreichen Ihre Clients zwar den Server, erkennen jedoch eingegangene Antworten des Servers nicht (da die IP-Adresse nicht mehr passt) und es kann nie eine Verbindung aufgebaut werden.
Wenn Ihr Router diese Option nicht hat, aber eine manuelle erweiterte NAT-Konfiguration, können Sie selbst eine ähnliche NAT-Regel erstellen – sagen Sie dem Router, dass er alle Verbindungen, die vom LAN kommen und zum selben LAN zurückkehren, „maskieren“ soll.
(Dies hat natürlich immer noch den gleichen Nachteil, dass die IP-Adressen der Clients vor dem Server verborgen werden.)
Die beste Option (persönlich nicht getestet, aber ich habe keinen Grund zu der Annahme, dass es nicht funktionieren sollte) ist meiner Meinung nach jedoch, den Server auf einemanderes Subnetzvom Rest Ihrer Geräte. Solange der Rückverkehr des Servers zu den Clients über das Gateway läuft, sollte das Problem vermieden werden – auch wenn keine VLAN-Trennung vorhanden ist und beide Subnetze auf demselben Ethernet laufen.
Das oben Genannte könnte möglicherweise auch durch Ändern der Subnetzmaske oder Hinzufügen benutzerdefinierter Routen zum Server implementiert werden.