Traffic von alten Server auf neuen Server umleiten (aber wie?

Dieses Thema im Forum "Server Administration" wurde erstellt von Feanwulf, 22. März 2013.

  1. Feanwulf

    Feanwulf Member

    Hallo,

    ich möchte den Trafficfür bestimmte Ports von meiner alten Ip-Adresse 5.x.x.x auf 213.x.x.x umleiten

    Eigentlich soll dafür rinetd geeignet sein, aber bei mir macht er das irgendwie nicht. Müssen sich die Quell und Ziel IP im gleichen Netzwerk aufhalten?

    Meine Regel sieht wie folgt aus:

    0.0.0.0 80 213.239.192.217 80
    0.0.0.0 25 213.239.192.217 25
    0.0.0.0 143 213.239.192.217 143
    0.0.0.0 993 213.239.192.217 993
    0.0.0.0 953 213.239.192.217 953

    Logfile schmeisst mir aber nur folgende Meldung raus:

    22/Mar/2013:19:35:47 0.0.0.0 0 (null) 0 0 0 accept-failed -


    Kann mir da jemand helfen oder eine alternative nennen?
     
  2. Brainfood

    Brainfood Member

    Ich versteh überhaupt nicht den Sinn/das Ziel dahinter?

    Port 25 / 80 / 143 / 993 sind doch alles reguläre Dienste, du sprichst doch die Dinger per rekusiver Anfrage ab, ob sich da eine IP im Hintergrund ändert ... ist doch wurscht ..., für dein Mailbetrieb kannst du sowieso neue Reverse DNS Einträge setzen ...

    Ärgerlich wäre es z.B wenn du einen Public DNS-Resolver abstellst :p

    oder betreibst du irgendwelche "Schmuddel"Seiten wo deine Leute den Webserver nur per direkter IP ansprechen? :D

    Wenn du unbedingt Traffic forwarden willst, dann musste halt weiter für die alte Kiste blechen ... Installier dir ein OpenBSD, pfctl hat massig viele Möglichkeiten die in Handumdrehen eingerichtet sind ...
     
  3. Feanwulf

    Feanwulf Member

    Der Sinn besteht dahinter, dass ich den Server am Sonntag rüberkopieren werden, der aber eine neue IP-Adresse verpasst bekommt und Postfächer, Webseiten aber dann über den neuen Server bearbeitet werden sollen.

    DNS Einträge ändern dauert bis zu 24 Stunden, bedeutet es kommen vielleicht keine Mails an ODER Dienste können nicht angesprochen werden, weil der "alte" Server dann nicht erreichbar ist.

    Wenn ich aber den Traffic von den ports auf die IP-Adresse des neuen Servers umleite, werden auch die Dienste weiter bedient, bis der DNS Eintrag sich rumgesprochen hat.

    War vielleicht nicht deutlich genug von mir beschrieben.

    Der alte Server soll ja 2-3 Tage parallel betrieben werden aber die eingehenden Emails oder Anfragen an den Webserver und der Teamspeakserver sollen nur noch auf dem neuen Server angesprochen werden.
     
  4. florian030

    florian030 Member

    Hast Du denn sonst noch Einträge in der rinetd.conf?

    Wenn ich bei mir testweise

    Code:
    0.0.0.0 80 213.239.192.217 80
    eintragen, lande ich offenbar auf deinem Server.

    Im Prinzip stimmt deine Config. Du darfst nur keinen Service aktiv haben, der an den entsprechenden Port gebunden ist.

    Alternativ könntest Du die Weiterleitung auch mit iptables machen.
     
  5. Feanwulf

    Feanwulf Member

    ok - dann teste ich das nachher noch mal danke ;) ich hatte zwar den Apache ausgeschaltet, und bei mir wollte das nicht, aber vielleicht habe ich da etwas übersehen ;)
     
  6. Brainfood

    Brainfood Member

    Da wir hier nicht von irgendeinem High Availabilty / Cluster Setup sprechen, wo mal eben fix eine VM von einem Node auf den anderen live migriert werden kann, wird dir zwangsläufig bei der Umstellung von einem physischen Server ... auf einen anderen eine Downtime widerfahren ....

    Was für 24 Stunden? du wirst doch sicherlich keine TTL von 1 Monat eingestellt haben oder?

    Was Webkram angeht, kannste deine Leute per "Maintenance Mode" darauf hinweisen, bis zu dem Stichtag findet der letzte Webcontent / DB sync statt, ab dann wird der alte Server offline genommen ... DNS Prio kannst ja einstellen.

    Bei Mail musste halt eine Zeit erwischen ... wo die Nutzung deines Dienstes am geringsten ist, (3-4 Uhr Morgen in der Früh?) ... dann schiebste einmal den IMAP Content per Dsync (unter Dovecot gibt es z.b. Dsync) auf den zweiten Server ... und stellst den ersten SRV auf @Domain RELAY mit einer Aufbewahrungszeit von 7 Tagen um ... (dieser Lagert nur noch ankommende/unzustellbare Mails für SRV2 zwischen, bis DNS seitig die neuen Einträge global übernommen werden)

    für Teamspeak und Co. Dienste musste dann wohl Datenströme weiterleiten ...

    Sofern sich die Umstellung im selben Netz befindet, frag bei deinem Hosting Center an ... ob die VLAN umgebogen werden kann ...

    Wenns unter Linux sein soll, von Meister Timme gibts mal wieder eine Anleitung:

    Port-Forwarding With rinetd On Debian Etch | HowtoForge - Linux Howtos and Tutorials


    oder Patric J. ? :>
     
    Zuletzt bearbeitet: 23. März 2013
  7. Brainfood

    Brainfood Member

    Deine "Alte" Schnitte 5.9.146.xxx hängt im xxx.ex3k1.rz19.hetzner.de ... deine Neue 213.239.192.xxx im xxx.ex3k5.rz13.hetzner.de, da kannste wohl nur selber routen ...
     
  8. Feanwulf

    Feanwulf Member

    Jap wird so sein - daher werde ich wohl einfach die TTL auf 3 Stunden stellen - damit müsste ichd as problem wohl fast umgehend erledigt haben ;)

    Mit dem relaying mach ich dann noch zusätzlich!
     
  9. Feanwulf

    Feanwulf Member

    Oh nein du kennst meinen Namen ;-)
     
  10. Brainfood

    Brainfood Member

    Code:
    ;; ANSWER SECTION:
    bla.de.		2474	IN	SOA	ns1.bla.de. webmaster.bla.de. 2013032204 7200 540 604800 86400
    bla.de.		2474	IN	TXT	"v=spf1 mx a:mail.blabla.de a:mail.ausgangsserver.de a:mail.eingangsserver.de a:web-ng.blabla.de ip4:213.239.192.xxx -all"
    bla.de.		2474	IN	MX	10 mail.bla.de.
    bla.de.		2474	IN	A	213.239.192.xxx
    bla.de.		2474	IN	NS	ns1.bla.de.
    bla.de.		2474	IN	NS	ns1.blablabla.de.
    
    Hast ey per default ne Stunde eingestellt :D

    Du hättest deine IP im Beispiel nicht verraten sollen, des hat mich neugierig gemacht ... etwas deine Kiste abzuklappern ;)
     
    Zuletzt bearbeitet: 23. März 2013
  11. Feanwulf

    Feanwulf Member

    Mit der TTL habe ich dann auch gesehen - gab aber noch Einträge mit 24 Stunden TTL

    @Kiste abklappern: Müsste eigentlich vernünftig gesichert sein - wenn nicht freue ich mich auf einen Hinweis
     
  12. Brainfood

    Brainfood Member

    das übliche Problem halt bei diesen Debian Kisten ... SSL + Renegotiation ... Debian Apache reagiert erstmal nicht darauf, Postfix läuft eh unter STARTTLS ... nur deinen Dovecot kannste damit DDOSn ...

    Wenn die Prozesse 99% CPU Power fressen ... werden deine Services unbrauchbar ...

    Allgemein kannst ja noch etwas an den Configs feilen ...
     

Diese Seite empfehlen