"Test" Wordpress Installation neben der Hauptseite

[wario]

Hi nochmals
Hab zu dem Thema wordpress noch kurz ne Frage, eigentlich gehts eher um den VPN

Wenn ich mich unterwegs via VPN auf mein LAN Netzwerk verbinde, habe ich keinen Zugriff auf meine domain. Ich kann alle IPs erreichen und mich auch mit der IP der NAS verbinden und das Interface und alles zugreifen. Die Geräte sind alle da. Nur wenn ich meine domain bearbeiten will geht das nicht. Kein Zugriff bzw host not found.

Ich habe die dynamische IP die ich beim VPN login bekomme in der Quell Liste des DNS servers hinzu gefügt, und außerdem versucht eine port fowarding einzurichten, port 1194 auf port 80 und hab es auch mit 443 versucht.

Komm da nicht drauf bzw lässt sich nicht verbinden

 

[blurrrr]

Das hat sicherlich etwas mit der DNS-Auflösung zu tun. Das Routing (IP) funktioniert ja, Du kommst an alles dran. Beim Webserver läuft das allerdings etwas anders, da geht es um das Thema "vHost", welche i.d.R. "namensbasiert" arbeiten, sprich das Ding reagiert auf einen FQDN (xxxx.example.tld) und liefert Inhalte aus einem bestimmten Ordner aus (z.B. /web/wordpress). Sprichst Du etwas anderes an (xxxx2.example.tld) wird ein anderer Inhalt ausgeliefert (z.B. /web/wordpress2).

Stellst Du jetzt einfach "nur" die VPN-Verbindung her, erhält Dein Client die Info, dass das angegebene Netz/die angegebenen Netze (z.B. 192.168.0.0/24 und 10.8.0.0/24 wie in Deinem Fall) über den VPN-Tunnel erreichbar ist/sind. Was sich bis jetzt NICHT geändert hat, ist der DNS-Server. Somit sind die Routen in die privaten Netze zwar bekannt, gefragt wird aber immer noch der DNS-Server, welchen der Client normalerweise nutzt (auch ohne VPN). Du versuchst somit von "aussen" auf die Website zuzugreifen (da Du als Antwort Deine "externe" IP für xxxx.example.tld von externen DNS-Anbieter bekommst).

Der Synology-VPN-Server wird Dir ja eine Konfigurationsdatei ausgegeben haben, welche Du beim Client importiert hast. Dort steht mitunter sowas drin:

#dhcp-option DNS DNS_SERVER_IP

Ersetz das mal durch:

dhcp-option DNS <interne IP Deiner Syno>

Exportier die Client-Config nochmal auf der Syno (oder ggf. hast Du sie noch irgendwo rumliegen), führe die genannte Änderung durch und importier die Config wieder am Client. Danach sollte der entsprechend hinterlegte DNS-Server benutzt werden (also Deine Syno).

Alternativ kann der VPN-Server die Info auch an den Client übergeben, da bin ich mir aber nicht so sicher, ob das ganze auch ein Update des VPN-Dienstes auf der Syno überlebt. Theoretisch wäre es wohl:

push "dhcp-option DNS <interne IP Deiner Syno>"

Kannst Du auch auf der offiziellen OpenVPN-Website nachlesen unter: https://openvpn.net/community-resources/pushing-dhcp-options-to-clients/

 

[wario]

der knaller blurrr, astrein, es funktioniert. Ich danke dir herzlichst. Will gar kein anderes Forum mehr
Auch die Erklärung hab ich super verstanden

besten dank und schönen Mittag )

 

[wario]

hmm doch nicht so ganz. meine via internet erreichbare domain funktioniert. die testwebsite aber hingegen nicht
also domain.ch funktioniert test.domain.ch geht nicht. der Eintrag im DNS server für die test domain ist aber vorhanden und lösst via nslookup auch richtig auf.

PS: den htacess deny hab ich mal entfernt. die testadresse ist natürlich auch nicht mit einem a rekord auf dem domain host angegeben. in meinem internen dns aber wie gesagt schon.

 

[blurrrr]

Wie testest Du denn überhaupt? Laptop via LTE verbunden und via VPN eingewählt? Ich weiss jetzt grade aus dem Stehgreif nicht, ob die Syno als VPN-Gateway ggf. die Adressen beim Zugriff auf das Heimnetzwerk umschreibt (Client kommt z.B. von 10.8.0.2, geht über die Syno (192.168.0.x) und ggf. wird die anfragende IP des Clients (10.8.0.2) via NAT umgeschrieben auf die IP der Syno (192.168.0.x). Somit müssten die anderen Teilnehmer im LAN das Netz 10.8.0.0/24 garnicht kennen, da die Anfrage (augenscheinlich) direkt von der Syno kommt. Vielleicht lässt die Syno das aber auch beim Zugriff auf "sich selbst" sein, dann würde die Anfrage direkt von der Client-IP auf der Syno aufschlagen (10.8.0.2).

Jetzt zum "eigentlichen" Problem (vermutlich)... Du hast bei der Testseite die .htaccess erstellt und dort den Zugriff auf das LAN beschränkt (192.168.0.0/24), da gehört das VPN-Netz (10.8.0.0/24) natürlich nicht zu. Du müsstest demnach die .htaccess noch um das VPN-Netz erweitern:

Order Deny,Allow
Deny from all
Allow from 192.168.0.0/255.255.255.0
Allow from 10.8.0.0/255.255.255.0

So sollte das dann wohl aussehen, also einfach nur eine Zeile dazu mit dem VPN-Netz

 

[blurrrr]

Achso... noch eine kleine Anmerkung am Rande: Beim DNS-Server der Syno hast Du ja auch sicherlich eine "Ansicht" erstellt und da ggf. auch eine Einschränkung getroffen:



Hast Du dort nur das LAN (192.168.0.0/24) hinterlegt, oder ggf. auch das VPN-Netz (10.8.0.0/24)?

 

[wario]

Das VPN netz habe ich dort hinterlegt, bzw hatte, aus irgendeinem grund war der Eintrag gerade weg, hab den wieder erstellt und jetzt ist die testdomain auch erreichbar

Hatte aus Testzwecken die denies, allow Einträge der htaccess ja vorher schon entfernt.

Problem war der DHCP DNS Eintrag in der vpnconfig

Ich hab da noch ne Verständnisfrage. Du hast ja geschrieben dass der client, der über vpn im internen Netzwerk ist, immernoch seinem eigenen DNS verwendet und nicht den der Syno, dass jetzt die interne Testdomain nicht erreichbar ist leuchtet mir ein. wieso ist dann aber die öffentliche domain nicht erreichbar? Der DNS des clients fragt ja dann seine externe Einträge abnoder wird weiter geleitet, der fragt irgendwann den DNS des host ab und dann sollte das doch auflösen? Wo ist mein Denkfehler?

Ich teste ganz einfach über das Smartphone im LTE Netz

 

[blurrrr]

Das kommt mitunter auch auf die Reihenfolge der Dinge an, welche da im weg stehen/standen/wie auch immer. Grundsätzlich besteht so eine "Web-Anfrage" (xxxx.example.com) immer aus mehreren Dingen:

1) Du trägst z.B. in der Adressleiste des Browsers ein: "xxxx.example.com"
2) Der Client versucht mit seinem hinterlegten DNS-Server diese Adresse in eine IP aufzulösen
3) Nach Erhalt der IP wird eine Anfrage an die erhaltene Ziel-IP mit dem Inhalt nach xxxx.example.com gestellt
4) Der Webserver (Ziel-IP) schaut nach, ob er dafür (xxxx.example.com) einen vHost-Eintrag hat und liefert die Inhalte aus dem entsprechend hinterlegten Ordner aus.

Heisst schon mal in erster Instanz: Wird Dein interner DNS nicht gefragt, läuft die Anfrage an öffentliche DNS-Server. Der öffentliche DNS kennt logischerweise Dein internes Netz nicht und wird somit auch den Eintrag mit der zurückgeben, welcher im öffentlichen DNS (bei Deinem externen DNS-Anbieter) hinterlegt ist. Vermutlich Deine öffentliche WAN-IP vom Router. Somit wandern die Pakete zum Webserver über das öffentliche Netz, landen beim WAN-Interface Deines Routers, welcher die Pakete nach innen an den Webserver weiterleitet (Portweiterleitung).

Wird der interne DNS gefragt, wird dieser Dir den entsprechend dort hinterlegten Eintrag zum FQDN liefern (also die interne IP des NAS (192.168.0.x)). Somit wandern die Pakete durch den VPN-Tunnel (Dein Client weiss durch die Routing-Tabelle, dass die Netze 192.168.0.0/24 und 10.8.0.0/24 über das Tunnel-Interface erreichbar sind) und erreichen durch die privaten Netze den Webserver.

Das kannst Du auch alles sehr schön überprüfen, via "nslookup <FQDN Deiner Website>" und "tracert <FQDN Deiner Website>". Zum einen siehst Du mit dem ersten Befehl, welche IP bei der DNS-Anfrage ausgegeben wird, zum anderen sieht Du mit dem anderen Befehl auch die "Strecke", welche die Pakete zum Ziel nehmen.

Kleines Beispiel dazu aus vorheriger Konfiguration: VPN-Client ist eingewählt, kennt also die internen Netze, aber der externe DNS wird noch benutzt. Ein "nslookup" würde nun die öffentliche WAN-IP Deines Routers ergeben. Ein "tracert" würde nun zeigen, dass die Pakete eben NICHT in den VPN-Tunnel wandern, sondern die Pakete direkt ins öffentliche Netz gehen.

Das ist erstmal ganz grundlegendes Zeugs und ist für alle gleich. Zusätzlich gibt es dann noch weitere kleine Fallstricke, wie z.B. die ".htaccess" auf dem Webserver, oder Einschränkung der Ansicht beim DNS-Server, etc. Das sind aber schon wieder so "extra" Geschichten. Die grundsätzliche Funktionsweise ist mit den Themen Routing, Namensauflösung und wenn man will noch noch "vHost" (beim Webserver) eigentlich erledigt

EDIT: Hab Deine Frage garnicht direkt beantwortet: Es kommt halt darauf an... Wenn die öffentliche Website nicht erreichbar ist, muss da ein "Grund" für vorliegen (wer hätte es gedacht ). Wenn etwas nicht so funktioniert, wie es "sollte", kannst Du in erster Instanz via nslookup und tracert die grundlegenden Dinge überprüfen (funktioniert die Namensauflösung und das Routing korrekt), sowas gilt auch für öffentliche Netze (ist egal, ob Du rein intern agierst, oder im öffentlichen Raum, die Spielregeln diesbezüglich sind immer die selben).

Wenn jetzt eine Seite geht und eine andere nicht (auf dem gleichen Webserver), heisst es grundsätzlich erstmal, dass (zumindestens für die eine Seite) die DNS-Einträge korrekt sind und "generell" das Routing auch funktioniert. Da könnte man mal den DNS-Eintrag für die fehlerhafte Seite kontrollieren (nslookup). Ist das auch alles korrekt, ist das Problem sehr wahrscheinlich in der Webserver-Ecke zu suchen. Hat dieser einen entsprechend vHost für die fehlerhafte Seite? Ist da alles korrekt? Falls man das auch alles mit "ja" beantworten kann, geht es an die Website selbst bzw. die Inhalte im Webordner, wie z.B. eine .htaccess. Alternativ dazu, gibt es - es handelt sich in Deinem Fall ja um Wordpress - auch noch div. Security-Addons, welche ggf. auch Zugriffe verhindern können, usw. Die Liste der Möglichkeiten ist mitunter schon etwas länger, schlau beraten ist man allerdings, wenn man sich erstmal um die "grundlegenden" Dinge kümmert (oftmals ist da schon irgendwo ein Fehler).

 

[wario]

vielen dank nochmals für deine ausführliche Erklärung. das routing funktioniert nun ja generell auf die dienste die ich benötigte.
Hab mich nur gefragt wieso die Namensauflösung der online domain nicht funktionierte wenn ich via vPN eingeloggt bin. Es ging ja extern via LTE und intern im LAN problemlos (ohne vpn). Bei der lokalen test.domain ists mir ja klar dass die domain nicht erreichbar ist wenn der externe DNS verwendet wird. Aber die online domain muss ja auflösen wenn die DNS Einstellung des clients (smartphone) auch wenn ich in einem VPN eingeloggt bin? Aber wie du sagtest, es lag sicherlich an einer der nachfolgenden Baustellen (wordpress, plugins und etc)

Auf jedenfall mitlerweile funktioniert alles problemlos und ich teste bereits Proxmox auf meinem Hauptrechner und habe bereits 3 VMs intsalliert Und dank der ganzen "Probleme" funktionieren die Einstellungen in den konfigs jetzt auch deutlich schneller und ich muss weniger nachschlagen