ip hijacking voor failover *

[EgoH]

Ik heb 2 servers die beide hun sites draaien.
Nu zat ik alleen te denken, ik kan alle sites op beide servers mirroren voor als er een down gaat.

Nu was alleen het probleem van hoe zorg ik ervoor dat de traffic naar de andere server gaat, als de andere niet meer on-line is.
Nu dacht ik als ik op beide servers elke minuut een ping doe naar elkaar, en hij krijgt geen response van de ander, dat hij dan het ip van de andere server "hi-jacked".
Dan krijgt die server dus de traffic neem ik aan?
Want de servers staan in zelfde subnet, zelfde datacentre.
Als ik dan bij het opstarten er weer voor zorg dat het "ge-hijackte" ip weer wordt released, dat de server het weer over kan nemen.

Is dit mogelijk, of zit ik nu een beetje te dromen in theorie.

[mvdejong]

Niet alleen zit je niet te dromen, dit is een normale manier waarop dit soort problemen wordt opgelost.
Het is wel aan te bevelen dan de server-IP-adressen altijd als aliases uit te voeren, en het primaire IP-adres altijd aan de fysieke server toegekend te houden.

[EgoH]

mvdejong schreef op 01 september 2002 @ 21:23:
Niet alleen zit je niet te dromen, dit is een normale manier waarop dit soort problemen wordt opgelost.
Het is wel aan te bevelen dan de server-IP-adressen altijd als aliases uit te voeren, en het primaire IP-adres altijd aan de fysieke server toegekend te houden.

Ow, dat wist ik niet, is er toch niks mis met mijn gezonde verstand.

Ja tuurlijk moet je niet de primary ip adressen gebruiken, anders kan je niet meer checken wanneer server weer on-line komt.

Zijn er dingen waar je op moet letten als je dit wil gaan doen?
En zit er een delay in als je het ip-adres overneemt?

[ Voor 0% gewijzigd door EgoH op 01-09-2002 21:27 . Reden: typo ]

[Predator]

Zijn er dingen waar je op moet letten als je dit wil gaan doen?
En zit er een delay in als je het ip-adres overneemt?

Andere computers's (lokaal tov jouw server, zonder router ertussen) doen wel aan arp caching.
Ze houden dus bij welk ip aan welk mac adres verbonden is.

Dan sturen ze nog altijd de data naar de "oude" computer.
Omdat volgens hen dat ip nog altijd bij dat mac adres hoort.
Tot de cachetijd (normaal 5-15 mins dacht ik) verlopen is.

Als je dat ook niet wil moet je de mac adressen ook aanpassen (samen met de ip's).

[boner]

Als je na de hijack ook een ping doet naar het broadcast adres van het subnet doet is ook het arp-probleem meestal opgelost. Alleen ondersteunen niet alle ip-stack dit soort van adressen voor een PING.

[EgoH]

Predator schreef op 01 september 2002 @ 21:39:
[...]

Andere computers's (lokaal tov jouw server, zonder router ertussen) doen wel aan arp caching.
Ze houden dus bij welk ip aan welk mac adres verbonden is.

Dan sturen ze nog altijd de data naar de "oude" computer.
Omdat volgens hen dat ip nog altijd bij dat mac adres hoort.
Tot de cachetijd (normaal 5-15 mins dacht ik) verlopen is.

Als je dat ook niet wil moet je de mac adressen ook aanpassen (samen met de ip's).

15 minuten is nogal veel ja voor de situaties waar ik het voor wil gebruiken.
Maar 1 vraag:
Je kan het mac-adres faken, maar zullen de origenele ip's gebonden aan het originele mac-adres dan nog wel goed werken, als je het andere mac-adres overgenomen hebt?
Je kan toch niet 2 mac-adressen hebben neem ik aan?
Kan iemand hier wat duidelijkheid over geven?


Dit maakt dus niet uit voor de router?
De andere servers zullen dus alleen de verkeerde server proberen te bereiken, maar hij kan wel paginas voor het web serveren?

[Hermanvh]

Ehm zit ik nu gek te denken

Kan je niet het ip van server 1 koppelen aan de primary DNS en het ip van server 2 aan de secondary DNS?

[iNSaNe-oNe]

EgoH, de oplossing die je vraagt lijkt een beetje op hetgeen wat vaak bij netwerken wordt toegepast. Dat is het volgende:

Stel: op een subnet hebben alle nodes een default gateway ingesteld staan (nodig om van het subnet af te komen). We nemen voor het gemak het volgende netwerk: 192.168.1.0/24. Stel dat het default gateway-adres 192.168.1.254 is.

Om een vorm van redundancy hierin in te bouwen, kunnen hiervoor twee routers in dat subnet gehangen worden. De interfaces die in dat subnet hangen (één per router), hebben als fysieke adressen 192.168.1.252 en 192.168.1.253 ingesteld staan. Samen hosten zij een virtueel IP-adres 192.168.1.254, wat dus het default gateway adres is. Door middel van keepalives onderling detecteren de routers of ze nog te bereiken zijn. Klapt één van de routers onderuit, en het was de router die op dat moment houder van het virtuele adres .254 was, dan reageert de andere router die nog wel online is door onmiddelijk het MAC-adres over te nemen van de andere router en meteen requests op zich te nemen van de actieve nodes in het segment.

Dit protocol die dit bij netwerkcomponenten regelt heet VRRP (Virtual Routing Redundancy Protocol, een IETF standaard), bij Cisco-apparatuur heet dit HSRP (Hot-Standby Routing Protocol, Cisco proprietary).

Meer info:
http://www.cisco.com/warp/public/619/hsrpguide4.shtml (HSRP)
http://www.ietf.cnri.reston.va.us/rfc/rfc2338.txt (RFC over VRRP)

Ik denk dat je voor jouw servers een soortgelijk iets zal moeten kunnen implementeren. Hoe? Geen idee.

[Verwijderd]

wat dacht je van heartbeat.
2 de zelfde systemen mirroren en als er eenje uitvalt dan neemt de andere het gewoon over. zelf de ipadressen.

http://linux-ha.org/

[Oblii]

Je kan het mac-adres faken, maar zullen de origenele ip's gebonden aan het originele mac-adres dan nog wel goed werken, als je het andere mac-adres overgenomen hebt?
Je kan toch niet 2 mac-adressen hebben neem ik aan?
Kan iemand hier wat duidelijkheid over geven?

naar mijn weten zit er een route tabel (met mac adressen) in de switch waar je 'm aan hebt hangen, als die computer eruit gaat zal op den duur die entry verdwijnen en zal de computer waarvandaan het verkeer komt ook z'n tabel (ip&mac) moet updaten....

oftewel; volgens mij moet je even kijken of het mogelijk is met de hardware die in die colo hangt (95% ja), en zo ja, ff kijken hoesnel die hardware van hun dat wil overnemen enzo? ....

(dit geheel is niet met eigen proberen onderbouwd)

edit;

http://linux-ha.org/failover/
Each of these technologies has a certain inherent takeover speed. For example MAC address takeover is almost instantaneous (but messy), IP address takeover is a little slower and less reliable, and Dynamic DNS reconfiguration is slower yet, but has nice load-balancing properties.

[Fish]

EgoH schreef op 01 september 2002 @ 21:47:
[...]


15 minuten is nogal veel ja voor de situaties waar ik het voor wil gebruiken.
Maar 1 vraag:
Je kan het mac-adres faken, maar zullen de origenele ip's gebonden aan het originele mac-adres dan nog wel goed werken, als je het andere mac-adres overgenomen hebt?
Je kan toch niet 2 mac-adressen hebben neem ik aan?
Kan iemand hier wat duidelijkheid over geven?


Dit maakt dus niet uit voor de router?
De andere servers zullen dus alleen de verkeerde server proberen te bereiken, maar hij kan wel paginas voor het web serveren?

komt er op neer dat je het gewoon moet proberen dus
Waar je wel voor moet uitkijken is dat windows er uit klapt als er een andere windows bak met hetzelfde ip adres draaid. Onder linux weet ik het niet

We hebben hier op werk stackjes van hp draaien maar die hebben geen moeite met 2 dezelfde ip adressen op 2 vershillende poorten ...

Maar ik heb n.l. gewoon een printer in het netwerk gehangen op het zelfde ip van een pc .. maar ja die gebruikt weer andere poorten dus ik dacht .. what the fuck lets try it, en het werkte vlekkeloos.

[serkoon]

't is eigenlijk niet zo moeilijk..

server 1 houdt server 2 in de gaten en andersom. Zodra er server 1 eruitklapt, aliast server 2 dat ip-adres en start het een programmatje die arp-verkeer in de gaten houdt. Zodra server 1 er weer is, zal deze een arp-request op zichzelf broadcasten, zodat server 2 dan z'n alias weer loslaat en server 1 gewoon z'n eigen ip-adres weer heeft.

Misschien moet je dat aliassen zelf doen ipv met ifconfig, omdat anders server 2 nog replied op de arp-request van server 1 als die weer opkomt, maar da's niet zo heel veel extra werk meer..

[Predator]

http://www.linuxvirtualserver.org/

[EgoH]

serkoon schreef op 02 september 2002 @ 09:14:
't is eigenlijk niet zo moeilijk..

server 1 houdt server 2 in de gaten en andersom. Zodra er server 1 eruitklapt, aliast server 2 dat ip-adres en start het een programmatje die arp-verkeer in de gaten houdt. Zodra server 1 er weer is, zal deze een arp-request op zichzelf broadcasten, zodat server 2 dan z'n alias weer loslaat en server 1 gewoon z'n eigen ip-adres weer heeft.

Misschien moet je dat aliassen zelf doen ipv met ifconfig, omdat anders server 2 nog replied op de arp-request van server 1 als die weer opkomt, maar da's niet zo heel veel extra werk meer..

Zo dacht ik het ook ja, enne over dat opkomen van de server, als je elke 30 seconden het script laat lopen laat hij het ip vanzelf weer los als hij een reply van het primary ip adres krijgt.

Ook bedankt allemaal voor de andere programma's maar ik ga eerst kijken of ik het op deze manier voor elkaar kan krijgen, inplaats van programma's waar ik zo snel geen zicht op de totale werking heb.

[qoute]
NICs based on the DEC Tulip chips are especially well-suited to MAC address takeover, since they can support multiple MAC addresses on a single NIC. Otherwise, you need a spare NIC for each MAC address to be taken over
[/qoute]

Jammer dat ik die denk ik niet heb, bij alleen deze kaarten is het dus mogelijk om verschillende mac-adressen op de virtual ip's te gebruiken?
Ik ga vanmaddig testen.

Ik laat de resultaten wel weten.

[QBiT]

Predator schreef op 01 september 2002 @ 21:39:
[...]

Andere computers's (lokaal tov jouw server, zonder router ertussen) doen wel aan arp caching.
Ze houden dus bij welk ip aan welk mac adres verbonden is.

Dan sturen ze nog altijd de data naar de "oude" computer.
Omdat volgens hen dat ip nog altijd bij dat mac adres hoort.
Tot de cachetijd (normaal 5-15 mins dacht ik) verlopen is.

Als je dat ook niet wil moet je de mac adressen ook aanpassen (samen met de ip's).

Lijkt me niet. Zodra de pcs/switches door hebben dat die node down is, gaan ze niet vrolijk door met sturen, maar sturen ze een broadcast van "hea, wie heeft er dit mac adres ?"
Misschien dat het bovenstaande wel het geval is als de node met dat mac adres nog up is, maar daar hebben we het niet over

[EgoH]

Ik heb net even zitten testen.
Het lijkt perfect te werken!!

Ik voeg ip toe met:

code:

ifcfg eth0:5 add 64.191.*.*

Dan draait het op de orginele server.

Als ik dan dit doe

code:

ifcfg eth0:5 del 64.191.*.*

Krijg ik op ip meteen time-outs, als ik het add commando op de 2e server uitvoer, werkt het ip binnen 1 seconde op de andere server.
Het lijkt er dus op dat de mac-adress change hier niet nodig is, waar ik al blij mee ben .

Als ik het dan weer probeer te toe te voegen als andere server ip nog heeft, krijg ik mooie error:

code:

Error: some host already uses address 64.191.*.* on eth0.

Zoals het ernu uitziet zal ik met een klein simple scriptje de failover kunnen maken die ik in gedachten heb.

Laat nog wel iets weten in verder stadium.

[nero355]

Hmm allemaal zeer interessant maar je moet dan ook de eene server de andere laten updaten hoe wil je dat dan gaan doen??

Bijvoorbeeld:

Bij tweakers valt de eene server uit waar ik ingelogd ben dan moet die andere wel weten dat ik ingelogd ben als de eerste uitvalt!! Ook de reacties moeten op beide servers identiek zijn anders wordt het een zooitje!!

Succes hiermee alvast!!

[EgoH]

nero355 schreef op 02 september 2002 @ 18:12:
Hmm allemaal zeer interessant maar je moet dan ook de eene server de andere laten updaten hoe wil je dat dan gaan doen??

Bijvoorbeeld:

Bij tweakers valt de eene server uit waar ik ingelogd ben dan moet die andere wel weten dat ik ingelogd ben als de eerste uitvalt!! Ook de reacties moeten op beide servers identiek zijn anders wordt het een zooitje!!

Succes hiermee alvast!!

Voor synchronisatie is dit niet echt relevant, dat gaat weer over heel iets anders .
Maar dit is op mijn servers niet zo'n probleem omdat er alleen databases opdraaien die ik zelf update.
Alleen wat logs worden dan gereset maar daar is mee te leven
Dit is voor nood-oplossing, ben niet van plan het elke week te hoeven gebruiken.

[nero355]

Aha cool thnx weten we dat ook weer.