Veel publieke adressen per (web)server.

[Brainstorm]

Al geruime tijd zit ik met een vraagstuk waar ik zelf niet uit kom. Het gaat om een aantal (Windows) webservers, waar per server meerdere webapplicaties c.q. websites op draaien. Deze services zijn voornamelijk over http te bereiken, maar voor zowel bestaande als nieuwe klanten worden steeds vaker applicaties ontwikkeld waarbij SSL vereist is. Momenteel hebben alle webservers 1 of meer publieke IP adressen. Omdat steeds vaker SSL vereist is, koppelen we momenteel steeds meer IP adressen aan de webservers.

Wij beschikken momenteel over verschillende publieke /26 subnetten. Een server wordt geplaatst en krijgt een IP adres. Naarmate meer SSL gebruikt wordt, worden er meer adressen gekoppeld. Op een gegeven moment zijn alle adressen uit het subnet 'op'. Niet handig, want stel dat we op zo'n server weer een SSL willen koppelen dan moeten we ofwel ruimte maken in het subnet, ofwel de service naar een andere server in een ander subnet plaatsen. Het wordt dan een heel gepuzzel om optimaal gebruik te maken van de beschikbare capaciteit van een server en de beschikbare adressen binnen een subnet.

Waar ik naar op zoek ben is om dit probleem enigszins op te lossen. Constant heen en weer schuiven met applicaties en adressen is arbeidsintensief en niet handig.

Qua netwerk is momenteel het volgende aanwezig:
* Cisco PIX. Deze wordt momenteel gebruikt als hardwarematige firewall
* Per subnet een VLAN. Ieder subnet wordt door de service provider naar het publieke adres van de PIX gerouteerd.
* De PIX heeft per subnet een IP adres op de interne interface
* Achter de pix hangen verschillende Dell switches
* Iedere server heeft een interface voor publiek verkeer. De server heeft 1 of meerdere publieke IP adressen uit het subnet waar deze aan gekoppeld is. Op deze interface staat als gateway adres het betreffende adres op de PIX.
Een relatief eenvoudige setup welke eigenlijk al jaren zo draait.

Waar we eigenlijk als eerste naar zijn gaan zoeken is om een server simpelweg lid te maken van meerdere subnets (bijvoorbeeld de fictieve adressen 84.20.1.0/26 en 86.20.1.0/26). Je krijgt dan problemen met verkeer wat op het tweede subnet binnen komt, deze wordt naar de gateway gestuurd van het eerste subnet. Een andere optie zou zijn om simpelweg grotere subnets aan te vragen (/24 o.i.d.) maar dit vermindert het probleem, voorkomt het niet.

Waar ik mee zit is dat ik niet goed weet in welke oplossingsrichting ik moet denken. Is dit netwerk technisch op te lossen? Of zullen er juist veranderingen in het netwerk plaats moeten vinden? Wat bijvoorbeeld termen zijn als je met Google gaat zoeken:
* IPv6 - momenteel nog geen oplossing/toepasbaar
* Static NAT - waarbij de publieke adressen vertaald worden naar een interne range
* PAT

Mja, ik kan niet echt achterhalen wat nu goede oplossingen zouden zijn en of ik eens met een bepaalde partij moet gaan praten over dit probleem, naar bepaalde hardware moet kijken of wat dan ook. Tot zover zijn er nog geen concrete oplossingen.

Wat ook meespeelt is:
* Niet alle servers zijn webservers. De overige servers bieden bijvoorbeeld streaming media, Exchange, etc. op totaal andere poorten dan HTTP/HTTPS.
* Er zijn weet-niet-hoeveel domeinen gekoppeld aan de servers. Van >95% verzorgen we ook DNS, maar dus niet van allemaal.
* Momenteel zijn we aan het kijken of het mogelijk is om naar een andere co-locatie aanbieder over te stappen.
* De gebruikte PIX zal ook niet eeuwig blijven. O.a. omdat deze geen IPv6 ondersteunt, maar 100 MBit levert en een single-point-of-failure is in de huidige netwerksituatie.
* Qua budget moet ik het allemaal wel kunnen verantwoorden

In welke richting zou ik moeten gaan zoeken? Ik weet zeker dat hier goede oplossingen voor zijn... toch?

[TrailBlazer]

Static nat is een optie of je kan zelfs een loadbalancer constructie maken waarbij je op dit moment slecht een echte server achter hebt zitten. de huidige publieke ip's gebruik je als virtual IP's met daarachter al je servers op private IP space. Met een beetje loadbalancer kan je zelfs SSL ofloading doen.

[jvanhambelgium]

Sowieso in onze datacenter services doen wij het via NAT. Alle klanten die hosts hebben draaien (virtueel op onze vmware infrastructure of fysieke hosts) met hun spullen erop krijgen enkel interne ranges waarna op de grote Juniper dozen de nodige NAT's gezet worden en firewall policies draaien

Echte loadbalancer kan ook natuurlijk voor de grotere projecten (ACE-module)

[Bl@ckbird]

De ACE module van de 6500 switch is er tegenwoordig ook als appliance:
http://www.cisco.com/en/U...Sheet_Cisco_ACE_4710.html
En dan het model ACE-4710-0.5F-K9 die een halve Gbps throughput heeft.

[Brainstorm]

Ok, dan weet ik inderdaad genoeg. Ik ga morgen eens testen of het volgende werkt:
* Nieuw intern subnet aan maken.
* Op de PIX dat subnet routeren naar de achterliggende router
* Op de PIX een static NAT instellen tussen een publiek IP en een adres uit het interne subnet
* Server er aan hangen

Zou wel moeten lukken denk ik zo.

[Guru Evi]

Zo wordt het gedaan in verschillende datacenters. Je IP's worden getermineerd op je firewall en via NAT doorgegeven naar de correcte servers. Als je dedicated/colocated systemen hebt kun je die via VLAN afschermen van de rest van je netwerk. Het is meer flexibel omdat je intern kunt subnetten/supernetten naargelang je systeem evolueert en je moet enkel maar de firewall aanpassen en je moet niet bijhouden welke host welk extern IP adres heeft.

In ieder geval kun je ook meerdere subnets aan een enkele server hangen dus ik versta je probleem niet echt. Het enige dat je moet doen is als je VLAN's gebruikt die instellen (meerdere VLAN's naar een enkele netwerkkaart is mogelijk).

[Verwijderd]

reverse proxies gaan gebruiken. En alle ip's en certs koppelen aan de proxy(s), dan kan je webserver verder af met 1 ip, doordat je de proxy-webserver request gewoon over http laat gaan (als dat natuurlijk security technisch toegestaan is). Wil dit succesvol zijn dan moet je natuurlijk wel een groot subnet hebben anders loop je tegen dezelfde routing problemen die je zelf al beschreef.
Door wildcard certs kan je eventueel ook nog wat reductie krijgen in het aantal certificaten/ip's die je nodig hebt en is uitermate geschikt voor een reverse proxy opstelling, omdat je niet afhankelijk bent van waar de websites draaien.

reverse proxying geeft je in ieder geval meer mogelijkheiden NAT.

[ Voor 5% gewijzigd door Verwijderd op 16-07-2009 13:13 ]

[CyBeR]

Brainstorm schreef op woensdag 08 juli 2009 @ 22:00:

Waar we eigenlijk als eerste naar zijn gaan zoeken is om een server simpelweg lid te maken van meerdere subnets (bijvoorbeeld de fictieve adressen 84.20.1.0/26 en 86.20.1.0/26). Je krijgt dan problemen met verkeer wat op het tweede subnet binnen komt, deze wordt naar de gateway gestuurd van het eerste subnet.

Waarom is dat een probleem? Da's dezelfde PIX als ik je setup goed begrijp. Sowieso is source adres alleen maar boeiend met NAT-achtige hacks (ok, en policy routing etc.) en die heb je nu niet.

Los hiervan: de simpelste oplossing is, inderdaad, een reverse proxy ervoor proppen waar je al je SSL op doet.

[ Voor 8% gewijzigd door CyBeR op 29-07-2009 00:23 ]