172.16.x.x 2 lokaties VPN verbonden

[Verwijderd]

Wij hadden vandaag op kantoor het volgende scenario waar we niet uitkomen:

Wij hebben de servers draaien bij een housing provider. Op dit netwerk gebruiken wij het 172.16.x.x. netwerk. (weet zo niet wat het subnet is, maar ik ga even uit van 255.255.0.0) We hebben dus een aantal server met ip 172.16.1.1 1.72.16.1.2 etc

Dit gehele netwerk maakt via een cisco router verbinding met een andere router bij de klant d.m.v. VPN.

Nu moeten deze server verhuisd worden naar een 2e lokatie. Nu willen we dat niet in een Big Bang doen maar in twee gedeeltes. De vraag is nu: moeten we alle machines in het nieuwe 2e lokatie netwerk gaan omnummeren of kunnen we gewoon wederom hetzelfde network id 172.16 gebruiken voor deze 2e lokatie ? Probleem is ook dat er allerlei scripts lopen die dan ook aangepast zouden moeten worden naast het omconfigureren van de machines en dat willen we liever niet.

Ik denk het laatste. Communicatie tussen server 172.16.1.1 en 172.16.1.2 vindt plaats evenals communicatie tussen server 172.16.1.3 en 172.16.1.4. Plan is dus om de .1 en .2 de verhuizen het ene weekend en de .3 en .4 het andere weekend bv.

Als je dan twee netwerken hebt met allebei network id 172.16 en twee routers die in de nieuwe situatie verbinding legen met de klant router moet volgens mij alleen maar de klant eventueel op zijn vpndevice hard de 4 verschillende host definieren en welke route deze hebben. Maar misschien is dit nog niet eens nodig want de verbinding wordt geinitieerd vanuit ons netwerk.

Graag reacties.

P.S. ik vergeleek het net op de zaak met twee personeelsleden die allebei via vpn inloggen op het bedrijfsnetwerk en misschien ook allebei wel thuis een 172.16.x.x netwerk hebben draaien. Daarvan gaat een VPN opzetten toch ook goed en weten de packetjes de route toch ook terug te vinden.

[Asteroid9]

Dat gaat wel behoorlijk lastig worden. Routeren kan je hier niet, dus zul je in 2 richtingen NAT moeten gebruiken.
Dan moet je VPN device ook direct aan je 172.16.0.0 netwerk hangen en voor elke server die je remote wil benaderen een mapped IP hebben.

Aangezien je op de andere servers hier geen routes voor aan kan maken moet je vpn device ook echt de IP adressen broadcasten. (arp broadcast)
Niet alle firewalls kunnen dat, dus dat zul je uit moeten zoeken.

Daarom moet je in scripts en dergelijke ook altijd een fqdn gebruiken, een hardcoded IP adres is nooit een goed idee!
Bij thuiswerkers gaat het eigenlijk altijd om one-way traffic, en dat is niet vergelijkbaar met wat je hier wil.

Overigens is dit niet echt PNS, en hoop ik dat wanneer je dit als commerciele oplossing aan een klant aanbied nog even goed je huiswerk gaat doen...

[Verwijderd]

maar momenteel is dit dus voor 1 private netwerk toch ook werkend? Een private range met aan de andere kant van de routerinterface een off. inet adres. De router zet een tunnel op met de vpn/router klant en voila op het netwerk.

De verbindingen van het 172.16.x.x netwerk worden geinitieerd vanuit dit netwerk naar het klant netwerk en op de router staat de te volgen route en type (vpn) gedefinieerd.

Als je ditzelfde met een tweede 172.16.x.x netwerk doet welke ook alleen traffic initieerd vanuit dit netwerk naar de klant vpn/router hoeft hier toch alleen een tweede off. inet adres te worden geconfigureerd wat wordt toegelaten op de router ?

[Qwerty-273]

Probleem is dat je dus niet kan routeren op het zelfde subnet, je zou kunnen proberen (zoals Asteroid9 al aangeeft) te kijken naar de vpn devices of ze een tunnel tussen twee locaties op kunnen zetten met aan beide kanten het zelfde subnet. Grootste probleem (en de reden waarom het eigenlijk nooit gebruikt wordt) is dat al je broadcast verkeer dus ook door je tunnel gaat (en dat kan behoorlijk wat wezen).

Daarnaast inderdaad liever fqdn gebruiken (desnoods een hostname die je in je lokale hoststabel omzet naar een ip adres), voorkomt veel problemen en geeft je veel meer mogelijkheden met het vervangen/migreren van hosts.

Je voorbeeld met een thuis VPN gaat vaak niet op, omdat je vaak vanaf een 1 host een vpn opzet en je vanaf je bedrijfsomgeving dus niet het complete netwerk thuis kan benaderen. 1:1 of 1:n en niet n:n. Als je wel n:n wilt dan kom je met dezelfde subnets in hetzelfde probleem.

[bazkar]

Op zich zou hetgeen jij wilt moeten kunnen, maar dat hangt erg van je setup (Lees: je scripts) af.
Het probleem zit hem in de vpn-router van de klant.

Als er scripts bij je klant draaien die naar 172.16.x.x willen connected en er een site 2 site tunnel opgezet is, dan kan de router bij je klant dit maar naar 1 andere peer sturen.
Het is dus normaal niet mogelijk/handig om 2 site-2-site tunnels te definieren met aan beide remote eindes hetzelfde netwerk.

Wat je uiteraard wel kunt doen is de tunnel (het encryptie-domain, welke remote netwerken waar zitten) splitsen.
Je kunt bv. zeggen dat 172.16.1.x naar locatie 1 en 172.16.2.x naar locatie 2 getunneld worden.
Dat kun je tot op host niveau splitsen, maar afhankelijk van het aantal hosts en de verdeling over de netwerken kan dat VEEL werk zijn.

Een oplossing met NAT zou betekenen dat de hosts zelf niet omgeconfigureerd hoeven te worden, maar dat de klant probeert te verbinden naar bv. 172.17.x.x als hij naar locatie 2 wil, de router aldaar NAT dat static terug naar 172.16.x.x. Maar dat is dus afhankelijk van hoe makkelijk je je scripts aan kunt passen.

Het verschil met thuiswerk is zoals hierboven uitgelegd, dat een 172.16.x.x thuisnetwerk helemaal niet zichtbaar is voor het LAN op de zaak. Het LAN ziet alleen het publieke IP van je router. Je kunt dus ook niet vanaf je LAN naar dat thuiswerk connecten. Omdat je zegt dat de verbindingen geinitieerd worden vanuit het 172.16 netwerk, zou het kunnen dat dit in jouw situatie werkt, maar je opmerking over scripts doet mij hieraan twijfelen....

[ Voor 16% gewijzigd door bazkar op 09-11-2007 11:19 ]

[Verwijderd]

even ter aanvulling / verduidelijking: "ons" 172.28 netwerk haalt dmv (s)ftp bestanden op bij het klant netwerk. Dat is de enige verbinding die geinitieerd wordt naar het klant netwerk

In de nieuwe situatie zal je dan twee 172.28 netwerken hebben die allebei vanaf hun eigen 172.28 netwerk sftp opzetten naar dezelfde klant vpn router.lokatie 1 vanaf 172.28.2.9 en 172.28.2.7 en vanaf lokatie 2 vanaf 172.28.2.2 en 172.28.2.6.

De scripts draaien om te sftp-en en alleen om verbinding te maken met het klantnetwerk(via de klantvpnrouter) Niet terug vanuit de klant naar het 172.28.x.x netwerk dus.

Dat de tunnel over Internet loopt is toch niet interessant. Dit wordt toch afgehandeld door de beiden VPN routers, en aangezien de verbindingen voor sftp vanuit beide 172.16 netwerken worden opgezet moet dit toch gewoon werken ?

Ik ben wat eigenwijs :-) Denken jullie te moeilijk of ik te makkelijk ?

[Asteroid9]

Je zal per server een routering toe moeten voegen, zowel op elke server als op de VPN devices.
Voor elke server (specifiek IP) een route met als gateway het VPN device.
Op het VPN device exacte routes om per server bij te houden aan welke kant van de tunnel ze staan.

Dan kan het misschien werken, maar ik heb nog zo m'n twijfels...

Alternatief zou je al het broadcast verkeer over de tunnel moeten gooien, maar dan heb je een volledig transparante VPN tunnel nodig en niet elke firewall/vpn router kan dat.

[Tomsworld]

Tunnel opzetten tussen de 2 locaties en gewoon op layer2 een domein gebruiken. Voor een korte tijd en mits genoeg capaciteit moet dat wel werken.

Het is verre van ideaal als dat over een internet vpn tunnel moet, als het een ptp dark fiber ofzo is is het veel simpeler.

[bazkar]

Verwijderd schreef op vrijdag 09 november 2007 @ 12:54:
even ter aanvulling / verduidelijking: "ons" 172.28 netwerk haalt dmv (s)ftp bestanden op bij het klant netwerk. Dat is de enige verbinding die geinitieerd wordt naar het klant netwerk

In de nieuwe situatie zal je dan twee 172.28 netwerken hebben die allebei vanaf hun eigen 172.28 netwerk sftp opzetten naar dezelfde klant vpn router.lokatie 1 vanaf 172.28.2.9 en 172.28.2.7 en vanaf lokatie 2 vanaf 172.28.2.2 en 172.28.2.6.

De scripts draaien om te sftp-en en alleen om verbinding te maken met het klantnetwerk(via de klantvpnrouter) Niet terug vanuit de klant naar het 172.28.x.x netwerk dus.

Dat de tunnel over Internet loopt is toch niet interessant. Dit wordt toch afgehandeld door de beiden VPN routers, en aangezien de verbindingen voor sftp vanuit beide 172.16 netwerken worden opgezet moet dit toch gewoon werken ?

Ik ben wat eigenwijs :-) Denken jullie te moeilijk of ik te makkelijk ?

Als je routering en tunneldefinities op orde zijn (heel specifiek dus) dan werkt dit.

Een tunnel bestaat (naast een boel encryptieparameters en keys e.d.) uit 4 zaken, 2 peers (de VPN routers) en 2 encryptiedomeinen. De encryptiedomeinen zijn de netwerken waarvan de router weet dat ze 'in' het VPN zitten. In een normaal site-to-site VPN (zonder NAT/PAT) zijn de encryptiedomeinen 2 private netwerken. In dat geval kun je dus niet 2 tunnels bouwen op de klantrouter die allebei hetzelfde netwerk (encryptiedomein) aan de overkant hebben zitten. Dat snapt die router niet.
Aan jullie kant is dit geen probleem, maar het moet uiteraard aan beide kanten werken.

Als voorbeeld:

Klant netwerk is 172.16.x.x
Klant Peer IP (VPN router) is 1.1.1.1

Jullie netwerk 1 is 172.28.x.x
Jullie Peer IP 1 is 2.2.2.2

Jullie netwerk 2 is 172.28.x.x
Jullie Peer IP 2 is 3.3.3.3

Dan moet de klant dus 2 tunnels opzetten (naar peers 2.2.2.2 en 3.3.3.3) met beide hetzelfde encryptiedomein (172.28.x.x), dat werkt niet.
De tunneldefinities bij jullie zijn 2 keer een tunnel naar peer 1.1.1.1 met encryptiedomein 172.16.x.x en dat is geen probleem.


Op het moment dat je VPN router het netwerk wat erachter zit verbergt d.m.v. PAT dan kun je dus als encryptiedomein het ene adres van je VPN router opgeven (ik heb zelf slechte ervaringen met als peer IP en NAT-IP (encryptiedomein) hetzelfde adres te gebruiken, maar dat is erg device-specifiek).
Als je adressen over hebt zou ik zeker een 2e publiek IP gebruiken als PAT IP

Wat je dan dus bij je klant krijgt is:
2 tunnels: naar peer 2.2.2.2 met encryptiedomein 2.2.2.3 en naar peer 3.3.3.3 met encryptiedomein 3.3.3.4
bij jullie verandert niets aan de tunnel, MAAR, er moet wel PAT ingesteld worden op de routers, zodat ze de 172.28.x.x netwerken verbergen achter hun eigen publieke NAT IP (2.2.2.3 en 3.3.3.4 dus).

Het kan dus wel op deze manier, maar of je er blij van moet worden is de volgende vraag.