Beiträge von frank_m

Zitat von Hamsterbacke

Das Installationsskript Wireguard Road Warrior sollte dir dabei helfen Wireguard ohne Probleme handumdrehend aufzusetzen.

Von solchen Scripten halte ich gar nichts. Sie funktionieren immer für den vorgesehenen Anwendungsfall, aber sobald man den verlässt, ist man verloren. Gerade mit Fritzboxen funktionieren die überhaupt nicht, da man bei der Wireguard LAN-LAN Einrichtung mit Fritzboxen einige Besonderheiten beachten muss (siehe AVM Anleitungen!). Also: Finger weg! Wenn man mit Fritzboxen arbeiten, dann ausschließlich die AVM Anleitungen befolgen! Keine Scripte, keine Howtos, keine fency Youtube Videos. Nur die AVM Anleitung.

Zitat von Mordor

Unter allowed ips: solltest Du außer der 0.0.0.0/0 noch die Wireguard-IP der Fritzbox mit /32 eintragen.

allowed ips:192.168.1.1/32, 0.0.0.0/0

Warum das? Das bringt wirklich gar nichts, denn die IP ist bereits Bestandteil von 0.0.0.0/0.

Zitat von retaildata

Kannst Du die Wireguard-IP der FritzBox anpingen? - Nein

Es darf keine Wireguard-IP der Fritzbox geben. Siehe AVM Anleitung.

Zitat von retaildata

Prinzipiell muss der gesamte Netzwerktraffic nicht über die FritzBox gehen.

Kann ich dies auch mit 128.0.0.0/1 anpassen?

Nicht allein. Dann musst du auch noch ein 0.0.0.0/1 hinzufügen. Aber Vorsicht, dass du damit nicht den VPS vom Internet abklemmst. Wenn du wirklich den gesamten Traffic eines VPS über deine Fritzbox zu Hause schicken willst (warum auch immer man das wollen würde): Was spricht gegen 0.0.0.0/0?

Ich denke, es ist an der Zeit, die konkrete Konfiguration beider Seiten sowie die resultierenden Routen auf VPS Seite bei aktivem VPN zu zeigen. Sonst wird es schwierig mit der Analyse.

Du hast die Domain im Host drin. Das ist falsch.

Zeig doch mal Screenshots. Im Moment sieht man nicht mal, ob du TXT Einträge oder was anderes erzeugt hast.

Zitat von MichaelGee76

die DNS einträge stehen jetzt auf unknown

Dann kann es nicht funktionieren.

Übrigens: Warum Wildcard? Du kannst ja auch mehrere Sub-Domains ohne Wildcard unterbringen, und dann brauchst du keine DNS Änderungen.

Zitat von VeePay

Ich wollte keine DNS Schleuder in die Welt setzen und da dieser nur mit meinem VPN erreichbar ist, habe ich diesbezüglich nichts zu befürchten.

Ist ja auch völlig ok. Ich hab auch einen unbound und einen Pi-hole auf dem VPS - ebenfalls hinter dem VPN. Aber nur deshalb würde ich niemals die Defaultroute über VPN leiten.

Zitat von VeePay

Jetzt hab ich mein Subnetzwerk der Fritzbox via wg eingefügt aber kann leider nach wie vor nicht drauf zugreifen.

Jetzt ist es an der Zeit, das Setup auf beiden Seiten zu prüfen. Stimmen alle Adressen? Alle Routen? Vor allem auch auf der Fritzbox-Seite.

Zitat von Hille

Dann sollte das Setzen der zusätzlichen Route ebenfalls zum Erfolg führen.

Das ist dann nicht mehr nötig. Wireguard setzt die Routen selber, die zu den Allowed IPs passen.

Zitat von VeePay

Aber genau das ist von mir gewollt.

Und warum? Welchen Mehrwert soll das bringen? In öffentlichen Hotspots, ok. Aber vom heimischen Internetzugang?

Zitat von VeePay

Ich habe alles darüber laufen, da dann bei allen Geräten auch mein AdGuard Home greift. Der läuft auch auf dem Server.

Das ist ein DNS Eintrag in der WG Config, aber definitiv kein Grund, die Default-Route über VPN zu leiten.

Zitat von VeePay

Den Eintrag der AllowedIPs habe ich in der Config für den Router Client eingefügt.

Da darf er natürlich nicht rein. In der Router Config müssen die IPs rein, mit denen der Router auf Server-Seite kommunizieren soll.

Allowed IPs bestimmen, welche IPs man ausgehend erreichen kann. Für eingehende Daten darf man keine Einträge machen, das gibt Routing Kuddel Muddel.

Ich wage zu bezweifeln, dass man das auf Windows Server auf einem VPS (praktisch ohne GPU) zum Laufen bekommt. Ist vermutlich auch besser so.

Zitat von VeePay

Kernel-IP-Routentabelle

Ziel Router Genmask Flags Metric Ref Use Iface

0.0.0.0 89.58.48.1 0.0.0.0 UG 0 0 0 eth0

10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0

89.58.48.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0

Das sieht soweit erst mal gut aus, nur sollte - wie gesagt - das lokale Subnetz der Fritzbox benutzt werden. Also Allowed IPs 10.8.0.0/24 durch 192.168.178.0/24 (oder was auch immer) austauschen.

Zitat von VeePay

Wenn ich die IPs hinzufüge, bekomme ich mit der FRITZ!box keine Verbindung zum VPN.

Du hast die IPs aber nicht auf der Seite der Fritzbox hinzugefügt, oder? Die müssen natürlich in den VPS.

Zitat von VeePay

Habe auch 0.0.0.0/0 & ::/0 drin, um sämtlichen Traffic darüber laufen zu lassen. Ist das ein Problem?

Ich hoffe, das steht in der Fritzbox. Im VPS wäre es fatal. Aber: Zum einen halte ich davon gar nichts*, zum anderen: Wenn das drin steht, ist alles andere egal, denn dann schickt die Box eh den gesamten Traffic über die VPN Verbindung.

* Warum halte ich nichts davon? Wenn der gesamte Datenverkehr über den VPS geleitet wird, erzeugt das nur zusätzliches Delay. Außerdem taucht die öffentliche IP des VPS beim Aufruf der Dienste als Quell-IP auf, was zu Problemen führen kann. Einige Dienste gleichen die Quell-IP der Anfrage mit öffentlichen Listen ab und sehen, ob die Anfrage von Privatkunden-Anschlüssen, Servern oder VPN Anbietern kommt. Je nach Quelle kann das Probleme geben, z.B. bei Streaming Diensten.

Zitat von Hille

/usr/sbin/route add -net 192.168.178.0/24 dev wg0

Nein, darum muss sich Wireguard über die Allowed IPs kümmern. Einfach eine zusätzliche Route aufs WG Interface zu legen bringt gar nichts, ohne Allowed IPs lässt WG den Traffic eh nicht durch.

Zitat von KrisAusEU

Trotzdem interessiert es mich schon aus Lernzwecken, wieso das mit einer Standard out of the box lösung von wireguard nicht funktioniert .

Doch, das geht mit einer Out of the Box Wireguard Lösung. Ich hab genau sowas bei mir am laufen: Zwei Heimnetze bauen jeweils dauerhaft einen Tunnel zum VPS auf, und die mobilen Knoten wählen sich auf dem VPS ein und haben dann Zugriff in die Heimnetze.

Die Konfiguration braucht ein bisschen Feinschliff, besonders unter der Berücksichtigung der Besonderheiten in der Fritzbox. Dann wird das schon klappen.

Zitat von VeePay

Ich bin heute zufällig darüber gestoßen, dass man im WG die selbe IP Range nutzen soll wie die Fritzbox intern.

Genau das meinte ich. Die Fritzboxen nutzen kein Transfernetz. D.h., in den Allowed IPs der Router Config müsste das lokale Subnetz der Fritzbox auftauchen, umgekehrt in der Config der Fritzbox das lokale Netz der VPN Clients auf dem VPS.

Wie sehen die resultierenden Konfigs und Adressen aus? Nutzt du ein Transfernetz? Falls ja: gibt es eine statische Route dazu? Macht das VPN NAT? Hast du die Hinweise aus dem AVM VPN Portal für die Einrichtung befolgt?

In der 50-cloud-init.yaml ist ja schon der Beginn von policy based Routing drin. Hast du das durchgezogen? Sonst sperrst du dich durch die Default Route auf dem Tunnel Interface aus.

Zitat von engine

Wireguard VPN auf Port 443.

Das ist meines Erachtens nicht optimal, weil Wireguard mit UDP arbeitet. UDP Port 443 ist in den meisten Firewalls nicht offen, sondern nur TCP.

Wenn man Wireguard nativ machen will, dann eher auf Port 500 UDP. Der ist in vielen Firewalls offen für IPSec. Alternativ OpenVPN auf TCP Port 443, das klappt sehr häufig.

Zitat von heusmich

Das ist die Internet-Schnittstelle des Root-Servers.

Dachte hier kommen vielleicht irgendwelche Daten durch, wenn ich mich im Spiel auf den Server verbinde.

So sollte es auch sein. Hast du dich denn im Spiel auf den Server verbunden? Wenn schon an der Eingangsschnittstelle des Servers nichts ankommt, dann deutet das darauf hin, dass das Spiel gar nichts an den Server schickt. Das könntest du mit tcpdump oder Wireshark auf dem Spiele PC prüfen.

Zitat von heusmich

Über Webmin sehe ich noch andere Schnittstellen:

Dringender Hinweis: Benutze niemals graphische Tools wie Webmin. Die Dinger furwerken wild in den Konfigurationsdateien herum, und wenn man dann Dinge ändern muss, die man über Webmin nicht erreicht, sucht man sich zu Tode, wo überall was geändert wurde.

Was die Schnittstellen an sich sind, solltest du über die Konsole ja leicht herausfinden können.

Zitat von heusmich

"asanet" ist denk ich von den ARK - Survival Ascended Servern.

Das musst du im Auge behalten: Was ist das für eine Schnittstelle, wo kommt sie her und was soll damit gemacht werden? Vielleicht benötigt sie eine besondere Konfiguration, damit der Server wie vorgesehen funktioniert, oder vielleicht kollidiert sie auch mit anderen Schnittstellen im System.

Zitat von heusmich

tcpdump -i eth0 -n udp port 27035

Der Befehl lauscht auf eth0 und wird dir alle UDP Pakete ausspucken, die auf Port 27035 ankommen bzw. rausgehen.

Welche Schnittstelle ist eth0 denn? Und welche Daten würdest du da erwarten?

Spucken beide Anfragen die gleiche IP aus?

Man kann auch Port Knocking nutzen. Da muss nicht nur ein Port passen, sondern direkt mehrere müssen stimmen.

Ich schneide über munin mit, was meine Firewall und meine WAF so feststellen. Portscans, Zugriff von IPs auf Blacklisten, PHP Attacken, usw. Im Schnitt kommt ein Zugriff pro Sekunde vorbei, den ich nicht will.

Ich werde oft dafür kritisiert, wenn ich Neulinge hier im Forum darauf aufmerksam mache, dass sie ihren Server absichern sollen, bevor sie anfangen, die eigentliche Applikation einzurichten. Aber genau das ist der Grund dafür, und es ist wichtig. Sonst hat man wenig Freude an seinem Server.

Grundsätzlich ist gegen die Verwendung grafischer Oberflächen ja auch nichts einzuwenden - wo es passt. Das Problem bei diesen Admin Oberflächen: es gibt verschiedene Möglichkeiten, in Linux z.B. die Netzwerk-Konfiguration anzulegen (netplan, ifup-down mit der /etc/network/interfaces, NetworkManager, ...) oder die Firewall (iptables, ufw, nftables, ...). Eine Oberfläche kann unmöglich alle unterstützen, und nicht alle Linux Distris unterstützen alle Varianten dieser Einstellungspakete. Ganz abgesehen von Versionsunterschieden dieser Tools.

Dann kommen noch die Oberflächen hinzu, die gewisse Metainformationen brauchen und dafür eigene Ergänzungen in die Files schreiben, z.B. in Kommentar-Form, ... und schwupp hat man das schönste Kuddel-Muddel, durch das kein Mensch mehr durchsteigt. Spätestens, wenn die Oberflächen die eigentlichen Linux Dateien durch Links ins "eigene Universum" ersetzen, hört der Spaß auf, schon allein aus Zugriffsrechte-Gründen. Der Web-User hat einfach nichts an meinen kritischen Systemeinstellungen verloren.

Deshalb ist die Konsole das einzig Wahre für die Konfiguration eines Linux Servers. Und wenn man keine Zeit hat, sich einzuarbeiten, sollte man sich ein anderes Hobby suchen. Man schießt im Wald ja auch nicht wild um sich, bevor man einen Jagdschein macht.

Ok. Aber so schnell entstehen Gerüchte. Aus Foren kriegt man das nie wieder raus, und irgendwann kommt einer vorbei, und glaubt es.

Zitat von KrisAusEU

Wie gesagt, falsche Einstellung meinerseits schließe ich aus, ging ja vorher noch...

Da das Rettungssystem funktioniert, kannst du davon ausgehen, dass es doch so ist.

Zitat von KrisAusEU

heute Nachmittag eine 2. IP gekauft, DirectAdmin installiert und Backups vom "Schrott Server" eingespielt.

Ich vermute, da ist es passiert. Warum macht man so einen Unsinn? Richte das doch von Hand vernünftig ein. Wer wird freiwillig eine grafische Oberfläche verwenden, wenn er eine Konsole haben kann? Ich werde das nie verstehen. Und Backups von anderen Systemen würde ich nur sehr selektiv einspielen - eine Datenbank zum Beispiel. Aber das war es dann auch schon, alles anderen - inkl. der Dienste - richtet man auf neuen Servern von Hand ein. Sonst schleppt man Fehler über Jahre mit durch.

Geh systematisch vor. Checke IP-Adressen. Wie hast du die 2. IP eingerichtet? Dann die Routen, danach die Firewall und schließlich die Dienste. Aber auf der Konsole, denn ich wage zu bezweifeln, dass DirectAdmin die ganze Wahrheit anzeigt.