VPN og flere avdelinger

[HDSoftware]

Folkens. Jeg fikk svar tidliger på hvordan man setter opp VPN mellom to SITE's. Men hvordan gjør man dette i praksis hvis man har flere sites ?

 

Sett at man har et hovedkontor A der alle serverer og slikt er plassert. Så har man 3 avdelinger som skal nyttegjøre disse serverene. Hva er best practice her? Skal man lage et nett av VPN mellom alle avdelingene eller holder det med at avdekingene knyttes opp til A ? Vil f.eks. Avdeling B da kunen snakke med avdeling C ?

[Topguy]

Det er avh. av routingtabellen i VPN-routeren hos A.

 

Antagelig enklest å sette det opp i et stjernenettverk med A i midten, men belastningen på linken hos A blir jo høyere siden all trafikk mellom B og C må innom A. Så det vil være behovet for trafikk som antagelig vil være styrende for om du ønsker å sette opp en egen B<->C VPN link eller ikke.

[HDSoftware]

Ok. Gakker. Site A har 20Mb linje så det regner jeg med bør være greit..

[lhegdal]

I de sammenhenger jeg har benyttet vpn for å knytte sammen flere avdelingskontorer/ serversiter og lingende har benyttet et Alle til Alle forhold. Dette reduserer antall hopp for pakken, det gir større feiltolleranse - I dagens IT verden er det sjeldent aksept for at tjenester stopper grunnet at en link er nede, og er mer skalerbart.

 

Om 20Mbit/s er nok avhenger helt troughput. Om du/dere skal benytte VPN over internett eller dedikert nett må dere selv avgjøre. Begge fungerer og har ulik kost/nytte.

[HDSoftware]

SÅ det du sier er at et stjerneformet VPN ikke er å foretrekke... Men heller bruke et Alle til Alle VPN, der avdeling 1 kobler seg til hovedkontor + avdeling 2 og avdeling 3 etc. etc.

Stemmer dette ?

Endret 4. oktober 2011 av HDSoftware

[lhegdal]

Jeg ville satt det opp på følgende måte:

 

 

Oppsettet krever flere VPN linker, men du er mindre avhengig av hver link.

 

Hva slags oppsett du til slutt bør være avhengig av behov forretningssiden har. Det som spiller inn er hva som er hensikten med VPN linkene, har du WAN access på alle sitene/bør det være det?, båndbredde behov, osv.

 

Hva som er best og hva som er hensiktsmessig er ulikt fra løsning til løsning.

[HDSoftware]

Tja, når jeg tenker etter så er kansje dette litt overkill. Det er kunn ett sted det er en server og det er pr. idag. Men løsningen din ser interresant ut for den lar meg sette en server på alle stedene og kjøre synkronisering mellom disse...

[conundrum]

Tja, når jeg tenker etter så er kansje dette litt overkill. Det er kunn ett sted det er en server og det er pr. idag. Men løsningen din ser interresant ut for den lar meg sette en server på alle stedene og kjøre synkronisering mellom disse...

Grunnen til at et alle-til-alle-oppsett er ganske vanlig når man bruker IPsec, er at det ikke er noe mindre arbeid å sette opp et hub/spoke-oppsett.

 

Gitt 3 lokasjoner, A, B og C, og man ønsker å sette opp IPsec-tunneller slik at lokasjon B blir "midten", og kommunikasjon mellom A og C går via B:

 

A <=> B <=> C

 

Det festlige da, er at man må ha to nettdefinisjonener (og således to IPsec SAer) mellom A og B; en som definerer trafikk mellom nett A og nett B, og en annen som definerer trafikk mellom Nett A og nett C. Ja, routeren/brannmuren på lokasjon B må ha en IPsec-tunnel som definerer nettet på lokasjon C som nettet i sin ende. Oppsettet mellom B og C blir likedan.

 

Etter hvert som antallet lokasjoner øker, må man ta et valg: Enten ha en hub/spoke-løsning der direkte trafikk mellom ytterpunktene ikke tillates (alt går via midtpunktet), ha en gudsjammerlig mengde IPsec SA-definisjoner, eller tunnelere via en protokoll som tillater nummererte tunneler, f.eks. GRE.

 

Hvis man istedet for IPsec i tunnel-modus bruker GRE-tunneller mellom endepunktene og krypterer denne trafikken med IPsec i transport-modus, ender man opp med virtuelle interface m/IP-adresser i begge ender, som representerer tunnelen. Og interface med adresser kan man som kjent route via, og dermed er problemet løst. En bonus er at man også kan bruke routing-protokoller som RIP, OSPF etc.

[HDSoftware]

Hmm. GRE tunneller har jeg ikke hørt om. Hva er det?

[conundrum]

GRE (Generic Routing Encapsulation) er en IP-protokoll, nr. 47 for å være eksakt. Den er laget for å tunnelere IP-trafikk, i utgangspunktet uten kryptering med mindre man krypterer dataene først eller hele tunnelen via f.eks. IPsec.

 

GRE er forholdsvis utbredt, om enn ikke så godt støttet som IPsec. Man finner GRE-støtte i Cisco-routere og faktisk i D-Link-brannmurer. Den dukker også opp steder man kanskje ikke forventer det; Microsoft (mis)brukte GRE da de laget PPTP, så der går VPN-dataene over GRE etter at autentisering er foretatt og kryptering forhandlet frem via en TCP-basert kontrollforbindelse.

 

GRE fungerer som en hvilken som helst tunneleringsprotokoll ved at dataene enkapsuleres i en annen pakke i det de passerer endepunktet på vei ut, og pakkes ut igjen i den andre enden. Det som skiller GRE-tunneler fra IPsec (utenom krypteringen), er at GRE implementeres som et virtuelt interface på endepunktene, med egen IP-adresse.

 

Eksempel: Gitt to nett, A og B, med Cisco-routere som gateway-enheter:

 

Nett A (192.168.10.0/24) - gw1 <=> (Internet) <=> gw2 - Nett B (192.168.20.0/24)

 

De to routerne gw1 og gw2 har to nettverksgrensesnitt, FastEthernet0 og FastEthernet1. FA0 er tilkoblet Internet og FA1 er tilkoblet lokalnettet. Dersom man setter opp en GRE-tunnel mellom disse routerne, innebærer det at de begge får hver sitt nye, virtuelt interface som tilsynelatende er koblet sammen på lag 2 (point to point). Slik blir konfigurasjonen:

 

gw1:

interface tunnel0
ip address 192.168.200.1 255.255.255.252
tunnel source (gw1s eksterne IP-adresse)
tunnel destination (gw2s eksterne IP-adresse)

 

...og på gw2:

interface tunnel0
ip address 192.168.200.2 255.255.255.252
tunnel source (gw2s eksterne IP-adresse)
tunnel destination (gw1s eksterne IP-adresse)

 

Man kan nå route en hvilken som helst trafikk gjennom tunnelen, ved å angi IP-adressen til interfacet i den andre enden som next hop:

 

På gw1:

ip route 192.168.20.0 255.255.255.0 192.168.200.2

På gw2:

ip route 192.168.10.0 255.255.255.0 192.168.200.1

 

...eller, siden tunnel-interfacene er PtP-forbindelser:

 

gw1:

ip route 192.168.20.0 255.255.255.0 tunnel0

gw2:

ip route 192.168.10.0 255.255.255.0 tunnel0

 

Fordelene fremfor IPsec er de virtuelle interfacene som tillater tunnelering via routing, inkludert dynamisk routing. Ulempen er at tunnelen ikke er kryptert, men det løser man enkelt med IPsec i transport-modus (og det holder med én definisjon pr. endepunkt-par).

[HDSoftware]

Utrolig interresant. Dette må jeg se nærmere på. Er det kansje dette Hamachi bruker ?

[conundrum]

Hamachi pakker dataene inn i UDP-pakker (siden "UDP Hole Punching" er mulig å få til på svært mange brannmurer), så de bruker uansett ikke "ren" GRE. Hva som befinner seg inne i disse UDP-pakkene er ikke godt å si, ettersom spesifikasjonene er proprietære og ikke offentliggjort.

 

Men de kunne utmerket godt basert systemet på GRE (evt. GRE i en UDP-pakke).

[HDSoftware]

Men du sier at M$ (miss)bruker GRE i sin PPTP, betyr det at jeg egentlig bare kan koble site's sammen med PPTP og lage en routing tabell mellom sitene ? Jeg har brukt PPTP en del, men det har liksom vært mere Client-Server relatert, men det er kansje ikek noe forskjell på det ?

 

Jeg mener, jeg har jo allerede satt opp Windows 2008 som router på alle SITE's så da er vel dette kansje like greit ? eller.... ?

Endret 4. oktober 2011 av HDSoftware

[conundrum]

Det er fullt mulig å sette opp site-to-site-tunneler med PPTP, selv om det (som du sier) er mest vanlig å bruke PPTP til klientoppkoblinger.

 

Jeg vil likevel anbefale IPsec, ikke minst fordi PPTP er en utdatert teknologi (iflg. Microsoft).

[HDSoftware]

Ok. Men da er vi inne på noe vesentlig her. Jeg har nemlig satt meg litt inn i PPTP, men aner ingenting om hvordan man router trafikk, annet en at jeg har prøvd å skriver ROUTE PRINT i DOS for å se hva som skjer. Klarer vel å tolke resultatet der, men føler ikke helt at jeg vet hva det er for noe. Kansje du kunen fortalt meg litt om dette slik at jeg kunen fått det til med PPTP i et testmiljø. Dermed ville jeg skjønt hva det dreier seg om å ROUTE og pålutselig kansje jeg skjønner hva IPSEC er for noe og dermed kan gå over til dette i produksjon...

 

På forhånd en masse takk for all hjelp

[conundrum]

Du kan jo lage en tråd om routing og se hva som skjer.

[HDSoftware]

Jepp ;-) Will do..