Beiträge von TheEPOCH

Okay,

ich hatte mir zwar immer mit einem ipconfig.exe /flushdns geholfen,

aber mit den 3600 Sekunden für die Gültigkeit und einmal zum Supermarkt rüber und zurück hat es jetzt funktioniert.

Ich bin zwar etwas überrascht, weil das sonst nie ein Problem mit der Wartezeit war, aber vielleicht ist ja auch einfach heute Weihnachtsfeier bei netcup...

Ich danke euch auf jeden Fall!

Zitat von Virinum

Hast du bei "Host" auch "domain.tld" drin stehen? Wenn ja, das ist zu viel. Somit hast du die Subdomain vps.domain.tld.domain.tld angelegt. Da gehört nur "vps" rein.

Zitat von m_ueberall

Wenn da in einer Spalte wirklich "vps.domain.tld" eingegeben wurde, würde ich einmal ein "ping vps.domain.tld.domain.tld" probieren, das sollte funktionieren. Die Domäne und TLD dürfen nämlich bei Netcup nicht miteingegeben werden und bislang gab es hier keinen Kontrollmechanismus, dafür aber massig Beiträge in diesem Forum zu ebendiesem Fehler.

Danke für die Hilfsbereitschaft und entschuldigt meinen falsche Fragestellung.

Im DNS Eintrag steht natürlich nur "vps". Ich habe mein Beispiel falsch aufgeschrieben.

Zugegeben 48h habe ich jetzt noch nicht gewartet, aber es sind jetzt schon > 6h und ich muss zugeben, dass ich bei allen DNS Spielereien die hier bei netcup gemacht habe, eigentlich nie länger als 30 Min warten musst.

Hallo zusammen,

ich habe eine Frage bzw. ein Problem mit dem ich nicht weiter komme.

Ich habe einer meiner Zusatzdomains, einem meiner Webhosting Pakete hinzugefügt. Danach habe ich manuel der Domain einen DNS eintrag hinzugefügt, der auf die feste IP eines weiteren VPS verweist.

Wir reden also von den netcup Standardeinstellungen (inkl. * und @) + Eintrag: vps A 123.123.123.123
(entschuldigung ich habe mich vertippt, nicht: vps.domain.tld A 123.123.123.123, es steht da wie oben)

Jetzt geht jeder Ping den ich an vps.domain.tld sende, an die IP des Webhosting Paketes und der manuelle Eintrag wird anscheined ignoriert.

Ist bei den Standardeinträgen einer dabei, welcher diesen Fehler bzw. die "Mißbeachtung" des manuellen Eintrages verursachen kann?

Achso, hab natürlich abgewartet.

Vielen Dank und beste Grüße,

Hallo zusammen,

danke für Eure Anworten.

Zitat von Steini

Klingt für mich nach einem Firewallproblem. Die IP, die du zugewiesen bekommst ist nicht automatisch "intern". Die muss in der Firewall auch freigeschaltet werden. Hast du das gemacht?

Wenn du sowieso schon am rumprobieren bist, kannst du dir auch Wireguard anschauen. Meiner Meinung nach gehört dem die Zukunft.

Ja ich habe das ganze Subnet in der Firewall freigegeben. Ich werde mir Wireguard mal anschauen, ich hatte davon jetzt auch schon häufiger gelsen und da es ja jetzt einen Windows Client gibt ist das mal einen Blick wert.

Zitat von H6G

Der SSH Daemon müsste auch auf dem virtuellen Interface lauschen.

Wenn der vor dem VPN Daemon gestartet wird, weiß SSH gar nichts von dem VPN Interface.

Die Server sind ohne NAT an das Internet angeschlossen. Den Promiscuous Mode kannst du selbst aktivieren, weil du ja der Administrator des Servers bist. Notwendig ist das allerdings nicht.

Wie sieht denn deine OpenVPN Konfiguration und iptables Konfiguration aus?

Alles anzeigen

Der SSH Daemon hört auf any. Das mit der Reihenfolge hatte ich bisher allerdings nicht auf dem Schirm. Ich werde das mal ausprobieren.

Das ich den Promiscuous Mode selbst einstellen kann, wusste ich ebenfalls nicht. Ich hatte das bisher als eine Einstellung in der VM Umgebung verstanden in welcher der "root" Server läuft.

Eine aktuelle openVPN Config habe ich nicht, da der openVPN den Try&Error anheim gefallen ist.

iptables über ufw (before.rules)

*nat
-A POSTROUTING -s 10.1.1.0/24 -o ens3 -m policy --pol ipsec --dir out -j ACCEPT
-A POSTROUTING -s 10.1.1.0/24 -o ens3 -j MASQUERADE
COMMIT

*mangle
-A FORWARD --match policy --pol ipsec --dir in -s 10.1.1.0/24 -o ens3 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1$
60
COMMIT

[...]

-A ufw-before-forward --match policy --pol ipsec --dir in --proto esp -s 10.1.1.0/24 -j ACCEPT
-A ufw-before-forward --match policy --pol ipsec --dir out --proto esp -d 10.1.1.0/24 -j ACCEPT

(sysctl.conf - Änderung zu standard)

net/ipv4/ip_forward=1

net/ipv4/conf/all/accept_redirects=0
net/ipv4/conf/all/send_redirects=0
net/ipv4/conf/default/accept_redirects=0
net/ipv6/conf/all/accept_redirects=0
net/ipv6/conf/default/accept_redirects=0

net/ipv4/icmp_echo_ignore_broadcasts=1
net/ipv4/icmp_ignore_bogus_error_responses=1
net/ipv4/icmp_echo_ignore_all=0

net/ipv4/ip_no_pmtu_disc=1

Danke!

Hallo,

ich versuche schon seit geraumer Zeit einen VPN Server auf meinem netcup "Root-Server" (Root-Server Spring 2019) zum laufen zu bringen (System Ubuntu 18.04 LTS). Dabei habe ich schon verschiedenste Server-Dienste (openVPN, Strongswan, etc.) und verschiedenste Tutorials durchprobiert.

Letztendlich scheitere ich immer an dem Punkt, dass ich zwar eine Verbindung aufbauen kann und auch eine IP vom VPN erhalte, aber eine Kommunikation mit anderen Diensten auf dem Server (z. B. eine SSH Verbindung welche nach extern mit einer Firewall blockiert wird und ergo intern über VPN ja funktionieren sollte) nicht möglich ist.

Jetzt bin ich letztendlich an das Tool "SoftEther" (https://www.softether.org/) geraten. Wenn ich dort die Einrichtung durchlaufe, komme ich an einem Punkt, an dem mir die Fehlermeldung ausgegeben wird, dass der Server (sinngemäß) an einem NAT verwaltetem virtuellen Netzwerkdevice arbeitet und ich für die Kommunikation den Administrator bitten soll einen sogenannten "promiscuous mode" zu aktivieren.

Kann das sein? Wie verhält sich das bei netcup? Ich habe diesbezüglich mal gesucht, aber keine Einträge gefunden, dass andere damit ein Problem haben, bzw. diese Stichworte tauchen nicht auf. Andererseits habe ich jetzt schon an die 10 Tutorials durchgearbeitet und verschiedenst auch kombiniert (ja auch mit entsprechenden forwarding und Firewall-, Netzwerk- und Kernleinträgen) und das die jetzt alle einen grundlegenden Fehler beinhalten will ich auch mal ausschliessen.

Hat einer von euch einen funktionierenden VPN bei netcup laufen? Wie seid ihr da vorgegangen? Habt ihr bezüglich dieser "promiscuous mode"-Sache spezielle Einstellungen vornehmen müssen?

Danke und beste Grüße,

Fabian

Danke! Der Router Cache war die Lösung!

Hallo zusammen,

ich bin neu bei netcup und etwas verwirrt was die DNS-Zonen Verwaltung der Domains angeht.

Bisher habe ich das so verstanden, dass der Eintrag "@ A 235.235.235.235" doch meineDomain.de auf den Server verweisen lassen sollte, welcher unter der IP erreichbar ist.

Leider bleibt ein Ping auf meineDomain.de unaufgelöst, bzw. verweist auf eine mir unbekannte IP (46.38.243.234, kommt die von netcup?).

Im Gegensatz dazu wird der Eintrag "server A 235.235.235.235", durch einen Ping auf server.meineDomain.de anstandslos aufgelöst.

Kann mir hier jemand Starthilfe geben?

Vielen Dank,

Fabian