Hay,
Bei mir ist das nicht so. Ich benütze aber auch einen anderen Namen für das „Customer“-Verzeichnis.
das "aber" zählt in dem Fall für mich nicht, denn mein Customerverzeichnis wird durch den Accountnamen ergänzt und es funktioniert auf die beschriebene Weise bei mir... 
also /var/customers/webs/account/domain.tld
Das mit den Domainnamen habe ich manuell gemacht (also /domain.tld/ beim Anlegen der Domain hinterlegt, nicht als Standardeinstellung).
CU, Peter
Hay,
möglicherweise habe ich die Lösung, das scheint eine kleine Zweideutigkeit zu sein.
In meiner Installation sind die Pfade der Nutzer-/Domainverzeichnisse (trotz startendem "/") relativ zum /var/customers/web/ Verzeichnis und es funktioniert. Ändere mal den Pfadnamen auf "/domain/", also ohne die einführenden "/var/customers/webs" und probiere es aus.
CU, Peter
Hay,
es gibt grad noch eine andere Idee... hast Du denn auch die IPv6-Adressen in Froxlor eingetragen? Wenn dafür keine vhosts existieren, Du aber mittels IPv6 zugreifst, dann fühlt sich der Standardhost verantwortlich - und der ist halt /var/www/.
Nachtrag: Vorausgesetzt, Du hast IPv6 für den VServer aktiviert und konfiguriert.
CU, Peter
Hay,
die Darstellung sieht bei mir zwar etwas anders aus, aber unter Einstellungen bei der Domain steht: /var/customers/webs/<domain_name>/
inwiefern sieht es anders aus? Anderes Theme oder andere Inhalte?
Hast Du wie im Bild auf rot-eingekreist geklickt oder auf blau-eingekreist. Mein Bild des vorigen Beitrags stammt vom rot-eingekreisten.
Notfalls mal die Configs neu schreiben lassen (gelb) und dann warten (der Froxlor-Cronjob braucht etwas) oder manuell erzwingen über ssh:
/usr/bin/php5 /var/www/froxlor/scripts/froxlor_master_cronjob.php --force
CU, Peter
Hay,
1) wären Froxlor-Anfragen besser in der Kategorie Froxlor aufgehoben
2) phpinfo() zeigt das immer von der Admin-Oberfläche von Froxlor so an
3) Als Nutzer der Domains anmelden ("Kunde" hinter dem Domainnamen) -> Domains/Einstellungen -> Domain bearbeiten (Stift) -> Pfad... steht da das Unterverzeichnis mit / hinten (siehe Bild)?
CU, Peter
Hay,
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.10.100:80
-A PREROUTING -i eth0 -p tcp -m udp --dport 80 -j DNAT --to-destination 10.0.10.100:80
aber so wirklich hast Du meinen Beitrag nicht gelesen, wenn da noch die 10er IPs drinstehen, Du aber den Server unter der 192er IP ansprechen kannst wie ein paar Beiträge drüber erwähnt? Stehen da auch die entsprechenden Regeln für 443? Du brauchst UDP nicht weiterzuleiten, weil HTTP nur TCP benutzt.
Also bitte nochmal: Du hast geschrieben, dass Du vom VServer aus den häuslichen Webserver erreichen kannst. Fakt or Fake?
Unter welcher IP erreichst Du ihn (ping; telnet)? 192.168.0.100 oder 10.0.10.100?
CU, Peter
Hay,
Portforwarding: Wenn es http ist, dann würde ich einfach einen vorhanden Apache mitbenutzen oder einen kleinen proxy wie haproxy benutzen. Das ist doch viel einfacher.
... mittlerweile schon
CU, Peter
Hay,
korrekt?
ist die Frage, was Du unter P2P verstehst (ich weiß persönlich nicht, was es in dem Zusammenhang heißen soll...).
- IPV4 Forwarding aktivieren
- die von CmdrXay vorgegebenen Regeln hinterlegen
Ja. In den Regeln die IP-Adresse statt der 10.0.10.100 hinterlegen, die vom OpenVPN-Server für die Webservices ping- und connectierbar ist. Und deine generellen Accept-Roules aus Posting #1 natürlich auch.
CU, Peter
Hay,
Ich komme gerade nicht mit.
naja, mir sind mittlerweile auch schon zuviele verschiedne Class-a-b-c Netzwerke im Spiel, ich bin auch abgehängt
Ich gehe gerade von folgemden aus:
OpenVPN-Server (nc:94.16...) <-> (OpenVPN 10.0.10.0/24 [oder /30] als Transfernetz) <-> Zuhause (192.168.0.100/24 mit 192.168.0.100 als Webserver). In der Konfig ist das 10er Netz komplett irrelevant, weil das Zuhause-Netz anscheinend transparent zur Verfügung steht. ggf. korrigieren bitte 
CU, Peter
Hay,
Wieso müsste der Heim-Server von seiner neuen IP-Adresse bescheid wissen, wenn dieser per VPN verbunden ist? Der VPN-Server kann den Client über seine lokale IP-Adresse 192.168.0.100 erreichen.
dann routest Du das ganze Netzwerk 192.168... über das VPN und hast nicht einen einzelnen Client angeschlossen? ping 192.168.0.100 funktioniert also vom VServer aus? Und telnet 192.168.0.100 80 bringt einen Connect?
In dem Fall müssten dann in den iptables-Einträgen von mir statt der 10.er IPs die 192.168.0.100 eingetragen werden.
CU, Peter
Hay,
also irgendwas funktionert jedenfalls... über https://ip kommt das bei mir.
Das kann aber ev. ein Webserver auf dem OpenVPN-Server sein. Das wäre natürlich fatal, weil der ggf. alles auf Port 443 wegfischt.
Kann es sein, dass der Dienst auf dem Server auf der Seite des MAC-Mini nichts von seiner 10er-Adresse weiss?
Ja, das kann es auch sein - dass die Dienste ev nicht an die 10er IP gebunden sind. Notfalls an 0.0.0.0 binden zum testen.
CU, Peter
Hay,
Die Ports des V-Servers. Im Heimnetz selber (und über meinen alten VPN-Anbieter) kann ich den Heim-Server erreichen.
Es "lauscht" ja auch nichts an Port 80 des Vservers, also gibts am Port 80 über z.B. nmap kein Ergebnis.
Müsste der V-Server jetzt nicht einfach alle eingehenden Port 80 und 443 Verbindungen an die statische IP des VPN-Clients weitergeben?
Er gibt "nur" die Pakete weiter, nicht die Verbindung.
Was kommt denn jetzt als Ergebnis wenn Du http://<öffentliche-vserver-ip> machst?
CU, Peter
Hay,
Ein Scan der offenen Ports ergibt
Scan von welchem Server? Zuhause oder der VServer hier?
CU, Peter
Hay,
Sollte der Server nicht bereits die 10.0.10.100 IP erhalten, sobald dieser per VPN verbunden ist?
die (externe) IP-Adresse des OpenVPN-Servers. Die Pakete müssen ja von zuhause wieder zurückgeroutetmaskiert werden
Nachtrag: das ganze natürlich dann noch für Port 443.
CU, Peter
Hay,
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.0.10.100:80
iptables -t nat -A POSTROUTING -p tcp -d 10.0.10.100 --dport 80 -j SNAT --to-source <ip des servers>(aus dem Kopf; ohne Gewähr).
CU, Peter
Hay,
Die IP-Adressen der VPN-Clients sind erst einmal nicht statisch, daher möchte ich einfach auf das angegebene Subnetz weiterleiten.
das musst Du schon konkret machen, woher soll der OpenVPN-Server wissen, was er mit den eintrudelnden Paketen auf dem Port 80 anfangen soll?
Er kann sie ja schlecht als Broadcast ans Subnetz schicken (oder doch? Nie gemacht, nie gesehen...) in der Hoffnung, dass ein Server dort antwortet. Wenn der "zuhause-Client" eine feste IP bekommen soll, musst Du ein Profil ins ccd-Verzeichnis von OpenVPN legen, der feste VPN-IP-Adressen zuweist.
Wegen Masq melde ich mich gleich nochmal, sofern kein Kollege schneller war... bin gerade unterwegs.
CU, Peter
Hay,
Das Webhosting Spezial Mini Paket wäre eventuell auch noch eine Option gewesen.
CU, Peter
Hay,
kurz zur Aufklärung: Du möchtest von außerhalb auf einen Webservice zuhause zugreifen?
Von "überall" (bzw. jeder darf) darauf zugreifen oder von einem Gerät, welches sich ebenfalls ins OpeVPN einwählt?
Von überall: Masquerading einschalten und Portforward auf die IP des häuslichen Clients.
OpenVPN: peer-to-peer aktivieren in der Config von OpenVPN.
CU, Peter
Hay,
Ich bin mir nicht sicher, wie Du das gemeint hast. Aber eine Bitte habe ich an netcup: Bitte überprüft im CCP nicht, ob der eingegebene FQDN wirklich auf die angegebene IP-Adresse auflöst!
wenn solche Fragen aufkommen (der eine will's [vielleicht], der andere nicht), dann halte ich es sinnvoll, es für den Anwender einstellbar zu machen. Checkbox rein und fertig
CU, Peter
