VPN concentrator site fail over

[Verwijderd]

beste forumleden,

Ik wil graag eigen VPS hosten vanuit de (cloud) deze opstelling kan eventueel gehost worden op eigen locatie of in een datacenter.

het idee is dat vpsen een lokaal Ip adres krijgen achter een VPN.

Iedere klant heeft een VPN verbinding en kan op die manier bij zijn eigen interne subnet op de VPS omgeving.

het probleem waar ik mee zit is wat er gebeurt als de vpn verbinding weg valt. hoe kan ik ervoor zorgen dat er een site failover mogelijk is tussen twee locaties?

ik vraag me af hoe een vpn concentrator die bereikbaar is op een publiek ip direct bereikbaar wordt op hetzelfde publieke IP op een andere locatie en hoe datacenters hiermee omgaan. dat zelfde geld voor publieke adressen die ik nu al in bezit heb, kunnen deze mee verhuizen naar een datacenter of moet ik nieuwe IP blokken aanvragen hiervoor?

het is misschien niet moeilijk te realiseren maar het netwerk / vpn gedeelte icm failover is voor mij redelijk nieuw.

ik hoop dat iemand hier iets over kan zeggen.

alvast bedankt!

[Equator]

Tjonge, je vraagt nogal wat, maar je bent niet heel erg scheutig met informatie.

Er zijn verschillende opstellingen mogelijk:

Een VPN doos die geschikt is om in een active/passive configuratie te werken (zoals bijvoorbeeld een Cisco ASA cluster) gebruikt een zelfde netwerk aan de 'buitenkant' en een zelfde netwerk aan de 'binnenkant' om zorg te dragen voor gelijke IP adressen (zowel intern als extern). Zo kan bij een failover exacte dezelfde configuratie naar de passieve node verhuizen en werkt alles gewoon door (hoewel de VPN opnieuw opgebouwd moet worden). Met Gratuitous ARP wordt dan de ARP tabel snel geüpdatet zodat het IP bekend is op het MAC adres van de passieve node.

Dit is prima te realiseren binnen een enkel DC (of zelfs over twee DC's) maar het nadeel hiervan is dat je een L2 verbinding moet realiseren. Zowel binnenkant als buitenkant moeten in hetzelfde broadcast domein zitten. Dat geeft echter weer wat issues met zich mee die vervelend kunnen zijn. (maar met voldoende kennis en kunde kan het prima)

Als je een failover over verschillende DC's wilt realiseren, dan zijn er meerdere mogelijkheden:
De cheap and dirty variant: Round Robin DNS, maar dat werkt eigenlijk gewoon slecht. De meeste clients houden de DNS cache vast, waardoor het systeem al niet werkt, en je krijgt bij een failover dus geen garantie dat alles direct functioneerd.

Een andere oplossing is om je externe IP adres(sen) via een andere Internet uplink te laten adverteren. Daar kunnen de meeste zakelijke ISP's je wel mee helpen. BGP wordt dan gebruikt om bij een failover de advertentie van je externe IP adressen op een andere uplink te doen. Dit klinkt mooi en makkelijk, maar het heeft heel wat voeten in aarde, en je bent er ook nog eens stevig geld voor kwijt.

Een andere oplossing is om alles redundant uit te voeren in een active active oplossing en ontwerpen voor failure. (En dat is meer en meer de oplossing om niet te afhankelijk te worden van een enkele locatie, server, etc.)


Maar goed, dit zijn mogelijke oplossingen. Echter, ik ben zeer benieuwd wat je nu exact wilt bereiken. Jij wilt (virtuele) servers hosten die via een VPN voor klanten benaderbaar zijn?

Waar wil je die virtuele servers plaatsen? en is dat op 1 locatie?

je geeft namelijk aan:

hoe kan ik ervoor zorgen dat er een site failover mogelijk is tussen twee locaties?

Welke twee locaties bedoel je hier? Van de klant, of voor jouw virtuele server(s)?

Kan je (desnoods met MS Paint) een schema maken van hoe jij het precies voor je ziet?

[KoeKk]

Aansluitend op Equator, alleen bekeken naar de IPSEC VPN vraag:

Er zijn ook VPN concentrators welke een 'backup peer' ondersteunen op een ander IP adres (O.a. cisco (Met alleen IKE-v1 dacht ik), Juniper en Fortinet ondersteunen dat). Maar dat gaat dan wel over de apparatuur van je clients, op elke concentrator heb je dan dezelfde tunnel configuratie.

Of de VPN router bij de klant maakt een aparte tunnel naar concentrator A en B, en door middel van een routing protocol zorg je dat een van de twee tunnels actief gebruikt wordt. Valt er een weg dan heb je een automatische failover naar je andere tunnel.
Dit vereist wel dat je routed VPN kan doen in plaats van policy/crypto-map, maar routed vind ik sowieso een duidelijkere manier.

Ik gebruik het laatste intern, met OSPF als routing protocol, en dat werkt prima, zonder dat sessies opnieuw opgebouwd moeten worden.

[Verwijderd]

Bedankt voor de snelle reacties !!


zie het plaatjehttps://www.google.com/ur...eAex&ust=1548948447529888 voor mijn idee. het is eigenlijk geen bijzondere omgeving en publieke ip adressen krijgen we nu van onze provider middels BGP. deze kan ik koppelen aan servers in de cluster.

beheerde VPSen wil ik bereikbaar maken via VPN ivm veiligheid en ik heb dan ook geen publiek IP nodig.
ik leef met de gedachte om deze VPN 'concentrator' virtueel uit te voeren op dezelfde cluster als waar de VPS omgeving op draait.

DNS Round Robin is inderdaad geen optie.

De tweede optie over BGP is misschien wel interessant, moet ik dat zien als een oplossing die door mijn isp moet worden toegepast. ISP ziet als het ware de status van verbinding A en besluit als bgp peer a wegvalt hij hetzelfde verkeer routeerd via BGP peer B?

daarbij ga ik er dan vanuit dat bgp peer a op locatie a binnenkomt en bgp peer B op locatie B. dit zijn in dat geval twee aparte locaties, aangezien ik site failover wil realiseren.

ik ga de omgeving hosten in een datacenter. maar als het gemakkelijk zelf te realiseren is bekijk ik mijn opties nogmaals. Zelf beschikken we over twee locaties waar we verschillende BGP subn[img]C:\Users\Gebruiker\Desktop\site.jpg[/img]ets binnen krijgen. op locatie a hebben we wel een uplink failover gerealiseerd vanuit het oogpunt van interne apparaten. als verbinding 1 (peerA ) niet meer beschikbaar is gaan ze via de alternatieve verbinding waar dezelfde BGP configuratie op draait.


gr, Robby

[ Voor 9% gewijzigd door Verwijderd op 30-01-2019 16:29 ]

[The Realone]

Equator schreef op woensdag 30 januari 2019 @ 15:17:
De cheap and dirty variant: Round Robin DNS, maar dat werkt eigenlijk gewoon slecht. De meeste clients houden de DNS cache vast, waardoor het systeem al niet werkt, en je krijgt bij een failover dus geen garantie dat alles direct functioneerd.

Het is inderdaad niet de mooiste oplossing, maar ik heb wel erg goeie ervaringen met Azure Traffic Manager voor een cheap and dirty failover via DNS. Dat werkt bijzonder snel. Het kost geen drol, afhankelijk natuurlijk van de hoeveelheid DNS requests die binnen komen.

[Verwijderd]

morgen ben ik in staat om een eigen tekening te uploaden. ik zal mijn verhaal dan gelijk verduidelijken.