Wie richte ich denn sonst eine Weiterleitung auf eine andere Homepage ein?
Nunja, beispielsweise so für nginx, für Apache funktioniert analog mit anderer Syntax:
server {
listen 80;
listen [::]:80;
server_name domain.de;
return 301 https://www.google.com;
}Gruß Oli
Und was ist mit .org-Domains?
Die tar Anwendung wird unter dem gegebenen Pfad /usr/bin nicht gefunden! Versuchs mal nur mit tar, ohne Pfadangabe.
Also an meiner Uni sind die Doppeldosen auch nur mit einem 8-adrigen Kabel angeschlossen (4 Adern pro Anschluss), wie ich die Woche erst mitgeteilt bekam. Gigabit ist damit zwar nicht möglich, Fast Ethernet jedoch schon. Sollte also mit deinen 4 Adern möglich sein.
Hast du Ständerwände? Dann wäre das nachträgliche Einziehen von CAT Zwillingskabeln ja auch schnell erledigt.
OK, ist also eine Rechenaufgabe, ob die Bandbreite ausreicht, bzw. ob die Drosselung einsetzt. Wenn dem so ist würde die dedizierte Karte aber mehr Sinn machen, wegen der Gigabit Anbindung und dem klaren Abrechnungsmodell. Bei der virtuellen NIC stellt sich die Frage, ob diese auch gedrosselt wird, bzw. wie dabei das Abrechungsmodell aussieht.
Wozu brauchst du für den Fall denn ein VLAN? Reicht nicht das Loadbalancing auf deine öffentliche Server IPs? Wenn es um Datenverschlüsselung/Abhörsicherheit geht gibt's ja auch noch andere Methoden (SSH Tunnel, VPN).
Hallo Gooth,
ich hatte auch mal Windows Server laufen, hatte nie Probleme mit der Sicherheit. Gilt ja im Prinzip das gleiche wie für Linux Server: In der Firewall alles freigeben was nötig ist, jedoch so wenig wie möglich.
Daher fährst du mit deinen Ports (RDP für die Administration und die Exchange Ports) schon gut. Worauf du achten solltest: Installation von Programmen und Diensten öffnen dir gerne mal die Firewall durch automatisch hinzugefügte Regeln. Daher nach einer Konfigurationsänderung einfach mal nachschauen.
Ich habe damals neben dem Deaktivieren der nicht nötigen Regeln deren Remoteadresse noch auf Localhost gesetzt, damit, im Falle der unbeabsichtigten Aktivierung, trotzdem die Ports nicht nach Außen geöffnet sind.
Zusätzlich könntest du noch den RRAS Dienst einrichten und deinen RDP Port nur für ein internes Subnetz freigeben. Damit hast du noch eine zusätzliche Hürde für Angreifer.
Noch eine Frage: Benötigst du für den Exchange nicht noch einen Domain Controller?
Gruß Oli
Hallo und Willkommen,
da hast du “leider“ schon das richtige Produkt gefunden. Die IPs gibt's nur mind. 12 Monate und sind nach Zuweisung eines Servers auch auf dessen primäre IP geroutet. Änderbar ist diese Zuweisung dann wiederum nur gegen eine Bearbeitungsgebühr.
Ein Hinweis: Dein RS ist bereits virtualisiert. Das sollte dir bewusst sein. Containervirtualisierung ist kein Problem, VMs hingegen schon, dafür müsstest du noch das VMX Flag durchreichen lassen. Ist nach Kontakt mit dem Support gegen Aufpreis aber auch möglich.
Ein Vorschlag: Containervirtualisierung mit einer IPv4 und NAT auf ein privates Subnet. Ist z. B. mit Proxmox recht flott eingerichtet. Dienste müssen dann natürlich auf unterschiedliche Ports laufen oder du setzt für beispielsweise deine Webseitencontainer noch einen Reverse Proxy Container auf und leitest allen Http Traffic dadurch zum jeweiligen Zielcontainer. Mit so einem Setup arbeite ich sehr erfolgreich. Ist aber die Frage, was braucht man und was will man 
Hm OK, dann werd ich wohl doch wieder selbst per Zabbix monitoren 
Danke für eure Antworten.
Hat noch wer Erfahrungen mit False Positives bei uptimerobot.com? Derzeit werden meine Netcup-Server wieder als Down angezeigt, obwohl sie nachweislich von außerhalb erreichbar sind. Letztens hatte ich das schon mal, plötzlich sind alle Server bei Netcup Down, was aber nicht der Wahrheit entspricht.
Gibt es eine Art Rate Limiting für eingehende Pings auf das Netcup-Netzwerk? Oder ist der Dienst allgemein nicht mehr so verlässlich?
Nutzt ihr Alternativen?
Gruß Oli
Ich dachte UTC = GMT, seis drum...
Ich denke aber trotzdem dass die Anzeige in der Uhrzeit von Deutschland ausgegeben werden sollte. Und das ist (dachte ich) GMT+1 mit DST.Da das hier aber ja der Laberthread ist können wir gerne noch ein paar Haare spalten
Deutsche Zeit ist immer UTC+1 im Winter (ohne DST) und UTC+2 im Sommer (mit DST).
GMT war mal die Zeitreferenz, als es noch keine Atomuhren gab und das ganze noch mittels Sonnenstand gemacht wurde. Mit UTC wurde eine neue Referenz eingeführt, die auf Atomuhren basiert und GMT als Referenz ersetzte.
GMT ist genauer gesagt eine Zeitzone, die ebenfalls, wie alle anderen Zeitzonen, UTC als Zeitreferenz hat. Der Offset von GMT gegenüber UTC ist +-0, daher sind die Zeiten gleich. Technisch gesehen ist aber UTC keine Zeitzone, sondern eine Zeitreferenz, GMT ist eine Zeitzone, wie auch z. B. die EST.
UTC?! Damit gibts kein DST
Prinzipiell kann so etwas ja jeder machen. Muss ja nur deine Domain als Subdomain vor seine Domain setzen. Der Sinn sei mal dahingestellt, für dich im Allgemeinen allerdings erstmal nicht tragisch, da er ja weiterhin verantwortlich für seine Domain und damit seine Subdomains ist. Direkte Verbindungen zu dir gibt's ja per se nicht.
Hatte mal ein ähnliches Problem mit einem RS und Windows Server. Neuen Server bestellt, genauso eingerichtet, den alten per Zufriedenheitsgarantie widerrufen. Hat dann geklappt, leider mit deinem VPS nur nicht möglich 
Kann also manchmal auch auf dem Node einfach der Wurm drin sein und ein anderer funktioniert.
Ein ping6 fe80::1%ens3 gibt mir, genau so wie Pings zu anderen IPv6-Adressen, nur ein "Destination unreachable: Address unreachable".
Hm, wenn das schon nicht geht, dann ist da wohl was im Argen.
Fresh Install von Debian 9? Ich habe bei mir die Gatewayzeile erst gar nicht drin, wird aber wohl bei dir nicht das Problem sein!
Nach dem Poweroff mal ne Minute gewartet?
Ansonsten mal beim Support nachfragen, evtl. arbeiten die da gerade an was oder es gibt halt ein Problem mit deinem Netzwerk.
Gruß Oli
Dann habe ich herausgefunden, dass man beim Aufbau einer VPN-Verbindung mittels PUSH DHCP DNS x.x.x.x einen DNS-Server mitgeben kann. Trage ich da die IP meines V-Servers ein, dann läufts. Und wenn ich in der unbound-conf meine von der Telekom zugewiesene IP als Voraussetzung zum Access eintrage, dann gehts auch noch. Daraus folgere ich, dass die Pakete mit den DNS-Anfragen von meinem PC aus an den V-Server gehen, nicht aber über die sichere getunnelte Verbindung, sonst würde man doch eine interne IP als Access eintragen müssen und nicht die externe, oder liege ich da falsch?
Richtig, für den interen Zugriff auf deinen DNS-Server musst du auch über die interne IP auf ihn zugreifen!
Die externe IP wird ja "von außen" auf den Server geroutet, es sei denn du hast manuell eine Route zu der IP erstellt, welche über dein TAP-Interface führt.
Ich würde aber gerne auch die DNS Anfragen über den VPN-Tunnel schicken und sicherstellen, dass der DNS-Server (unbound) nur darauf reagiert. Da sich meine von der Telekom zugewiesene IP dauernd ändert, müsste das ja am unbound immer wieder angepasst werden.
Hilft nicht einfach eine Verringerung der Metrik deines TAP-Interfaces bzw. der default Route? Dann würde einfach dein gesamter Traffic über den VPN laufen! Die Metrik bei Netzwerkadaptern unter Windows kannst du in den erweiterten Einstellungen zur IP-Konfiguration auch manuell setzen, z. B. für dein TAP-Interface auf den Wert 0. So hab ichs zumindest bei meinem gemacht, damit der gesamte Traffic - falls mit VPN verbunden - auch über eben diesen Tunnel läuft.
EDIT: Vielleicht sage ich noch dazu: Ich nutze den Softether VPN mit eigenem internem Subnetz für das VPN (192.168.11.0/24). IP-Adressvergabe über DNSMASQ für IPv4 und IPv6. Dient bei mir vor allem als IPv6-Gateway, da mein DSL-Anschluss nur IPv4 bietet. Als DNS-Server reiche ich die Public DNS von Google durch (IPv4 & IPv6). Falls nicht mit VPN verbunden nutzt mein Rechner den Heimrouter als DNS Resolver.
Gruß Oli
Danke! Wie hast du denn das genau gemacht? Gibt es spezielle Dinge zu beachten, wenn ich die Daten migriert habe?
Habe schon einmal mit rsync migriert, war aber fummelig und ich möchte das nicht mehr durchmachen.
Also meine Durchführung lehnt sich an der hier an: https://www.linode.com/docs/platform/…-image-over-ssh
Nur, dass ich eben kein img erstellt habe, sondern direkt die Daten bitweise von der Festplatte des alten Servers auf die Festplatte des neuen Servers geklont habe. Ich hatte im Endeffekt somit eine 1:1-Kopie der alten Festplatte auf dem neuen Server.
Voraussetzung dafür ist eigentlich nur, dass die Zielfestplatte mind. genauso groß ist, wie die Quellfestplatte! Ist sie sogar größer, kannst du deine Partition ja nachträglich noch erweitern, um den ungenutzten Speicher ebenfalls zu nutzen.
Der Vorgang war wie folgt:
1. Beide Server in den Rettungsmodus. Auf dem Quellserver musst du den root-Zugriff per SSH zulassen. Ist zwar nicht best-practice, mit einem starken Root-Passwort oder gar pubkey-Auth im Rettungssystem sollte das aber für die kurze Dauer des Transfers kein Problem sein. Extra Pubkey einzurichten im Rettungssystem halte ich für den Fall eigentlich sogar für overkill! Sollte aber jeder für sich selbst entscheiden.
2. Auf dem Zielsystem folgendes ausführen:
ssh root@<QuellIP> "dd if=/dev/sda bs=1M " | dd of=/dev/sda bs=1MDieser Befehl schickt dir die binären Festplattendaten in Blöcken von 1MB direkt von der Quell- auf die Zielplatte.
VORSICHT: bloß nicht Quelle und Ziel vertauschen, sonst löschst du deine Daten unwiederbringlich! Also doppelt und dreifach checken!
Außerdem musst du aufpassen, dass die Gerätenamen stimmen (/dev/sda), vorher am besten auch jeweils auf jedem System per fdisk -l checken!
3. Warten bis der Vorgang beendet ist (angezeigt wird am Ende eine Meldung, wieviele Records übertragen wurden, dies sollte der Festplattengröße in MB entsprechen)
4. Bei statischer IP-Konfig im Rettungssystem auf dem Zielserver die root-Partition (z. B. /dev/sda1) ins Verzeichnis /mnt mounten und die /etc/network/interfaces an die IP-Einstellungen des neuen Servers anpassen.
5. Rettungsmodus beenden, etwaige weitere Einstellungen/Umstellungen am neuen Server wie gewohnt vornehmen. Dieser sollte jetzt normal laufen!
Nach beenden des Rettungsmodus ist der root-Zugriff auf SSH natürlich wieder inaktiv, dieser gilt ja nur solange das Rettungssystem gebootet ist!
Hoffe es geht bei dir genauso problemlos
Wenn der neue Server einige Tage parallel läuft könntest du auch mittels dd migrieren. Einfach beide Server in den Rettungsmodus und dann per ssh die Daten vom alten auf den neuen Server tunneln. So hab ich's vor kurzem bei nem Server gemacht.
Und warum macht die iptables aus IP-Adressen teilweise richtige URLs??
Wenn du iptables mit dem -n Flag aufrufst nicht. Ansonsten wird versucht den PTR-Record für die entsprechende IP zu bekommen.
War bei mir genauso, bei nem frisch gebuchtem Server. In der Doku steht auch irgendwo, dass neue/unbekannte IPs wohl erst geblockt sind und sich den Zugriff quasi verdienen müssen. Heißt: freischalten lassen, dann geht der Zugriff eingeschränkt. Wenn es auf Dauer ohne Probleme läuft wird die Einschränkung auch aufgehoben.
