Sette opp VPN mellom to steder

[HDSoftware]

Folkens...

Jeg har et nettverk på jobben som styres med Microsoft Forefront server som brannvegg etc.

 

IP range jeg har valgt der er 172.16.x.x

 

Så hr jeg akkurat fått et skap hos en ISP der jeg har fått en fast publick IP. Jeg har kjøpt inn en CISCO 8 porters router med VPN. IP Range her er 172.16.20.X

 

Jeg ønsker å sette opp et VPN mellom disse stedene. Jeg har svert liten erfaring med Site2Site VPN så jeg hendvender meg her. All hjelp er hjertelig velkommen..

[conundrum]

Forutsatt at den første x'en i nettverket som ligger bak TMG-brannmuren ikke er 20 og at ingen av nettene har 16-bits nettmaske (man kan ikke route mellom to identiske nettverk), kan du lett lage en VPN-tunnel mellom lokasjonene.

 

Det enkleste og vanligste er å sette opp en enkel IPsec-tunnel i ESP-modus med fast nøkkel (Pre-Shared Key, PSK) og IKE/ISAKMP-keying av selve forbindelsen. Dette støttes av alt som finnes av brannmurer. Du må da gjøre dette:

 

1. Definere parametre for "phase 1" (IKE Security Association). Dette er parametre for hovedforbindelsen mellom de to brannmurene, og omfatter:

 

- definisjoner på hva som skal være endepunktenes identitet (du vil her bruke IP-adressene)

- hvilken Diffie-Hellman-gruppe (krypteringsalgoritme) som skal brukes (bruk 2 eller 5, 1 er utdatert)

- hvilke krypteringsparametre som skal brukes for kryptering og signering (AES og SHA1 er gode valg, 3DES og MD5 er ikke direkte å anbefale, og DES er totalt utdatert)

- autentiseringsmekanisme (PSK i ditt tilfelle)

- tidspunkt for re-keying i sekunder (28800 er standard her)

- hvorvidt NAT Traversal skal støttes (kreves kun om et endepunkt er bak NAT)

 

Nå har du definert hvordan endepunktene skal nå hverandre, autentisere hverandre og kommunisere videre. Nå må selve VPN-forbindelsen defineres.

 

2. Angi parametre for med "phase 2" (IPsec Security Association):

 

- nettverk på hver side (her blir definisjonen på lokasjon 1 speilvendt av lokasjon 2)

- krypteringsparametre (AES/SHA1 om de er tilgjengelige i begge ender)

- hvorvidt du vil bruke "Perfect Forward Secrecy", og hvis ja, hvilken DH-gruppe som skal brukes til dette

- tidspunkt for re-keying i sekunder (3600 er vanlig) og/eller kilobytes (ofte ikke i bruk)

 

Når dette er gjort, må du sannsynligvis også legge inn brannmurregler som tillater den aktuelle nettverkstrafikken. Så snart de er på plass, skal tunnelen fungere.

 

Vær obs. på at testing av tunnelen vanligvis ikke kan gjøres fra selve brannmurene/endepunktene, da de vil velge sine eksterne IP-adresser som avsenderadresse, og de er ikke med i tunneldefinisjonen. (Ciscos "extended ping" kan derimot brukes, da du der kan angi den interne IP-adressen som avsenderadresse.)

 

Cisco har en side med eksempelkonfigurasjon her. Microsoft har sikkert en tilsvarende side for TMG, men jeg har den ikke for hånden sånn umiddelbart. Jeg kan derimot garentere at det vil fungere glimrende, for jeg har satt opp slike tunneler på TMG og ISA mange ganger mot utstyr fra Cisco, D-Link, ZyXEL og andre.

[HDSoftware]

En dullion takk...

 

Komplisert stoff dette her, men forstår jeg det rett så er det første jeg må gjøre å finne et annet segment. Jeg bruker nemlig 16 bit nettmaske. Men siden jeg bruker 172 nettet så kan jeg endre IP på det andre stedet. Kan jo f.ejs. bruker 172.17.0.0/16 og 172.16.0.0/16 . Dermed vil jeg jo kunne route mellom disse. Takker for infoen. Jeg må studere dette mer...

[conundrum]

Stemmer, du må først og fremst ha forskjellige nettverk på de to lokasjonene, ellers vil ingen IP-baserte VPN-systemer kunne lage en forbindelse.

 

Du kan, som du sier, endre den ene lokasjonen til 172.17.0.0/16. Alternativt kan du bytte nettmaske til et noe mindre nett (med mindre du faktisk trenger 65534 IP-adresser i hvert nettverk).

[xcomiii]

Mulig jeg er på bærtur, men mener å huske at jeg leste noe dokumentasjon fra Juniper ang VPN og to identiske subnet. De beskrev hvordan man kan sette opp NAT for å omgå problemet, er ikke det mulig da?

[conundrum]

Mulig jeg er på bærtur, men mener å huske at jeg leste noe dokumentasjon fra Juniper ang VPN og to identiske subnet. De beskrev hvordan man kan sette opp NAT for å omgå problemet, er ikke det mulig da?

Du er ikke på bærtur, dette kan gjøres med Cisco-utstyr også. Det krever at man benytter to IP-subnett som skal representere de respektive nettene når kommunikasjon kommer inn fra den andre lokasjonen. Det man gjør, er følgende:

 

- På lokasjon 1 lager man en IPsec-definisjon fra fiktivt nett #1 til fiktivt nett #2. Samtidig setter man opp 1-til-1 NAT-regler som NATer lokalnettet bak fiktivt nett #1

 

- På lokasjon 2 lager man tilsvarende IPsec-forbindelse som for lokasjon 1, men med nettdefinisjonene speilvendt. Deretter setter man opp 1-til-1 NAT-regler som NATer lokalnettet bak fiktivt nett #2

 

Hvis man gjorde det i dette konkrete tilfellet, måtte man valgt to 16-bits nettverk til NATing. Anta at man valgte 10.10.0.0/16 og 10.20.0.0/16:

 

Lok. 1 (172.16.0.0/16) <=> NAT1 (10.10.0.0/16) <=> IPsec <=> NAT2 (10.20.0.0/16) <=> Lok. 2 (172.16.0.0)

 

Ulempen er at det er unødvendig komplekst, og dersom man skal ha fungerende DNS mellom lokasjonene, må man foreta en del triksing med ekstra soner.

 

Dessuten ser det ut som galmannsverk når man dumper konfigurasjonene.

[xcomiii]

Stemmer det, var sånn det hang sammen. Mener jeg også har sett at tilsvarende problemer har vært løst med å route på VRF, men det krever cisco utstyr som støtter VRF om jeg ikke tar helt feil.

 

Hehe, litt grisete blir det jo, men alternativet er å bytte IP range på en rekke tjenester, noe som kan være mere jobb enn å sette opp NAT-NAT.

[HDSoftware]

Stemmer, du må først og fremst ha forskjellige nettverk på de to lokasjonene, ellers vil ingen IP-baserte VPN-systemer kunne lage en forbindelse.

 

Du kan, som du sier, endre den ene lokasjonen til 172.17.0.0/16. Alternativt kan du bytte nettmaske til et noe mindre nett (med mindre du faktisk trenger 65534 IP-adresser i hvert nettverk).

Hehe, nei. Trenger ikke så mange adresser, men jeg har på en måte organisert nettet litt rett og slett for å ha en viss oversikt. Bruker jo DHCP til klienter, men det er bare på 172.16.1.x og det holder lenge. SÅ har heg forskjellige VM Hoster som har sine egne adresse ranger. Eksempelvbis har VMDevHost som er vår server som hoster alt som har med utvikling å gjøre en ip 172.16.40.x. En annen host bruker f.eks. 172.16.41.x etc. etc.

 

Altså kunn for å ha en enklere og mere praktisk oversikt. Så derfor for meg at jeg kunen plasere et eksternt område på 172.16.20.x, men skjønner jo at dette blir feil. Men 172.17.x.x er jo ledig og i hvertfall ikke inblandet i mitt nett..

 

Mulig jeg driver litt overkill her, men har på følelsen av at det ikek spiller den helt store rollen..

[lhegdal]

Hvorfor kan du ikke benytte 172.16.20.x?

 

Ellers er det smart å segmentere opp nettverket ditt. Det gir som du sier bedre oversikt og det er lettere å administrere.

[HDSoftware]

Tja, du leste kansje ikek hele tråden ;-)

 

172.16.x.x/16 er hoved site. Å bruke 172.16.20.x/16 på site2 vil da feile fordi det er samme segment. 172.17.x.x/16 vil virke fordi det er et nytt segment

[lhegdal]

Tja, du leste kansje ikek hele tråden ;-)

 

172.16.x.x/16 er hoved site. Å bruke 172.16.20.x/16 på site2 vil da feile fordi det er samme segment. 172.17.x.x/16 vil virke fordi det er et nytt segment

 

Overså det punktet

Men om du benytter et helt 16 nett på hver site, hva er da hensikten med å splitte opp IP rangene til de ulike serverne/klientene? En stor ulempe med et så stort nett er broadcast trafikk.

[HDSoftware]

La merke til noe du sa tidligere:

 

"Ellers er det smart å segmentere opp nettverket ditt. Det gir som du sier bedre oversikt og det er lettere å administrere."

 

Betyr det at jeg heller burde brukt små segmenter og heller ha routint tabeller mellom disse ?

 

Eksempel:

Host1 er en stor DELL server som hoster mine produksjons VM'er. Denne har ip 172.16.0.10/16

Alle VM's som går på denne har adressene 172.16.1.X / 16

 

DevVMHost er en HP server som hoster alt som har med utvikling å gjøre. IP 172.16.0.30/16

Alle VMene som går på denne har adressene 172.16.2.X / 16

 

DHCP range for brukere er adressene 172.16.10.X / 16

 

Som du ser her er det ingen routing tabell inne i bilder. Jeg har nemlig ikke helt oversikten på hvordan dette fungerer. Derfor har jeg bare satt masken til 16 bit slik at alle ser hver andre. Er det slik å forstå at jeg kunne bruke en mye mindre nettmaske og heller satt opp en routing tabell for å ordne synbarheten ? I såfall er dette veldig interresant og antagligvis noe jeg må studere..

[HDSoftware]

bare en kommentar :

172.16.0.X er altså fysiske servere

172.16.1.X er Servere hostet på Host1

172.16.2.X er servere hostet på DevVMHost

172.16.10.X er klienter

 

172.17.X.X skulle da være forbeholdt Site 2

 

Burde jeg organisere dette annerledes ?

[conundrum]

Du bruker altså den 3. oktetten i IP-adressen for å angi at det er snakk om en virtuell maskin, og hvilken host den ligger på? Jeg synes det så svært ryddig ut.

 

Jeg hadde antakelig ikke kommet på å gjøre det slik, mest fordi jeg har en ryggmargsrefleks som vil hindre meg i å sette opp IP-nett der mesteparten av adressene vil bli stående ubrukt. Noe som i dette tilfellet er uvesentlig, siden det er snakk om RFC 1918-adresser. Jeg antar at noen år til med IPv6 vil kurere meg for dette.

 

De eneste tungtveiende grunnene til å segmentere (slik jeg ser det), er om nettverket vokser til tusenvis av maskiner, og/eller det oppstår et behov for å isolere maskinene fra hverandre på nettverket.

[HDSoftware]

Hehe... Jeg satte det opp slik rett og slett fordi jeg fant det bekvemt. Ikke noe annet. Men blir jo litt usikker når noen sier dette skaper mye ekstra trafikk på nettet. Kan dette for eksempel skape tregheter på LAN'et vårt eller har dette i praksis null å si?

[conundrum]

Det vil bare skape treghet på nettet dersom mange av adressene faktisk er i bruk. 10 maskiner i et nettverk genererer bare den trafikken 10 maskiner skal generere, selv om IP-nettet de deltar i har plass til 65000 aktive noder.

[HDSoftware]

godt å høre...