[Løst] Problemer med toveis VPN-tunnel

[Pallantir]

Jeg driver et lite firma som frilanser, og jeg kan jobbe både hjemme og på hytta, med et oppsatt "hyttekontor" med fullt bredbånd. Jeg har satt opp identiske Windows 2003-servere der og hjemme (ja, det blir kanskje litt nerd å ha fullt serverskap med server og diverse forsterkere til multisonelyd på ei hytte, men fordømt morsomt når det fungerer!). Fordi de fleste filene jeg jobber med ligger hjemme, har jeg opprettet en VPN-tunnel fra hytta og til hjemmeserveren. Men innimellom har jeg behov for å komme til hyttenettverket hjemmefra (blant annet for å fjernstyre visse nettverksenheter der).

 

For å unnå kaos heter serveren hjemme Server (originalt, hva?), og den har IP-adressen 192.168.0.1. På hytta heter den Hytteserver (like originalt...), med 192.168.2.1. Begge kjører en VM med M0n0wall-brannmur mellom seg selv og bredbåndsmodemet, og der er det samme IP, så de to serverne har felles ekstern IP-adresse, 192.168.1.4 (hvor 1.1 er M0n0wall, mens de to andre er reservert IP-telefonen og en boks til). M0n0wallen bruker to nettverkskort i de to serverne, et USB og et PCI-E, som begge er dedikerte til den, så de deles ikke med noe annet (og alle protokoller unntatt VMware Bridge Protocol er slått av i den "fysiske" maskinen sånn at det ikke skal bli noen nettverkskrøll der). På hytteserveren har jeg satt opp en Static Route der 192.168.0.0 går gjennom VPN-tunnelen til hjemmeserveren, og det fungerer ypperlig. På hver av serverne har jeg 3-4 virtuelle maskiner til hver sin spesielle oppgaver som har med jobben å gjøre.

 

Problemet oppsto da jeg skulle opprette en VPN-tunnel tilbake. Jeg klarer bare ikke å kontakte Hytteserveren fra Serveren, verken fra Routing and Remote Access eller bare fra en opprettet kobling. Jeg klarer det bare ikke. Den står og tygger og tygger i omtrent 40 sekunder, og så spytter den ut feilmeldingen:

 

"An error occured during the connection of the interface. The connection was terminated by the remote computer before it could be completed. For furher assistance..." og så videre.

 

Det er ikke feil passord, jeg har prøvd flere kontoer. Jeg kan heller ikke koble til med noen av VM-ene på Server. En VM med Windows 7 tygger på "Godkjenner brukernavn og passord..." en stund og sier så:

 

"Feil 806: VPN-tilkoblingen mellom datamaskinen og VPN-serveren kan ikke fullføres." Så babler den i vei om GRE-pakker og brannmurer. Men jeg har nøyaktig samme oppsettet på brannmurene i begge ender.

 

Og enda merkeligere: Hvis jeg bruker en fysisk maskin som er på Serverens nettverk, får jeg VPN opp og kjøre til Hytteserveren i løpet av sånn omtrent tre sekunder! Det fungerer helt ypperlig. Og det er med den samme kontoen som ikke klarer det på RAS/VM-er.

 

Den eneste løsningen jeg har som fungerer så langt, er å kjøre VPN-tunnelen fra server til Hytteserver inni den som alt er opprettet mellom Hytteserver og Server. Men det blir vel dobbelt opp av alt, så det går vel ut over hastigheten? Er det noe jeg ikke forstår om nettverksarkitektur som gjør at dette ikke er mulig (det ville ikke være første gang...), eller er det en annen idiotfeil jeg har gjort i oppsettet på en av sidene?

 

Jeg har prøvd å bruke den samme VPN-tunnelen og kjøre static route fra Server, men det ser ikke ut til å være mulig. Eller har jeg oversett noe der?

Endret 18. april 2012 av Pallantir

[Zerge]

En VPN-tunnel er i praksis toveis, det skal altså ikke være nødvendig å opprette 2. Det du opplever er rutingproblematikk på hjemmeserveren din dersom trafikken initieres der.

 

For å unngå unødvendige problemer med NAPT vil jeg anbefale deg å bruke ulike subnet både foran og bak monowall hjemme og på hytta.

 

Uansett vil jeg anbefale deg å se på muligheten for å bytte til OpenVPN som er en del enklere å forholde seg til. Monowall støtter ikke OpenVPN ut av boksen, men med litt innsats kan du installere det, evt. bytte fra monowall til pfsense. Fordelen med OpenVPN er at den bruker en standard TCP/UDP port (ingen IPsec/GRE problematikk) og at det er enkelt å sette opp push-routes for at trafikk kan initieres fra begge sider.

[Pallantir]

Mange takk for svar! Det satt den pinadø! :green: Det hadde aldri falt meg inn at problemet var samme eksterne IP på serverne, altså mellom Server/Hytteserver og M0n0wall! Da jeg gikk over til 192.168.5.0-serien istedenfor 192.168.1.0-serien mellom Server hjemme og M0n0wall der, var det rett i boks på hytteserveren, og static route funket øyeblikkelig. Og da mener jeg øyeblikkelig. To sekunder etterpå kom jeg rett fra hjemmenettverket 192.168.0.0 og inn på overvåkningskameraet på hytta, som ligger på 192.168.2.201! Der reddet du meg fra masse irritasjon! Jeg bukker og takker!

[Pallantir]

Svarte... Grunnen til at det gikk nå, var at jeg hadde glemt å rette opp IP-adressen i M0n0wall for å videreføre VPN fra Hytteserveren til Serveren. Så Hytteserveren prøvde å komme inn på 192.168.1.4, mens den nye adressen var 192.168.5.4. Så det ser faktisk ut til at når jeg har en VPN fra den ene serveren til den andre, kan jeg ikke sette opp en motsatt vei. Men da vet jeg iallfall det. Spørsmålet er hvordan jeg setter opp en riktig ruting fra Serveren gjennom den VPN-tunnelen som er initiert av Hytteserveren og ut på Hytteserverens nettverk. Det gikk altså ikke å sette opp Static Route i RAS den veien, har noen en anelse om hvordan jeg gjør det?

 

Er dette noe som gjøres i DHCP options eller noe lignende, eller foregår alt innenfor RAS? For det skulle vel egentlig bare være å sende alle henvendelser til subnettet 192.168.2.0 over VPN-tunnelen, som på hjemmeserveren har adressen 192.168.0.200, på en eller annen måte, hva?

Endret 19. april 2012 av Pallantir

[Zerge]

Har du sett denne guiden?

http://www.misctechmusings.com/uncategorized/configure-m0n0wall-site-to-site-vpn/

Det viktigste du må huske på står i den nederste linjen:

"Once completed you will need to apply the same settings to the other m0n0wall system. Remote subnet, Remote gateway and My Identifier will need to be reversed."

Husk også at du fortsatt må ha ulike subnett i _alle_ ledd.

[Pallantir]

Takk, men du misforstår. Jeg kjører IKKE tunnelen M0n0wall til M0n0wall, men Windows Server 2003 til Windows Server 2003 for bare å ha de interne nettverkene knyttet sammen. Det er flere som bruker nettverket mellom serverne og M0n0wallene, og jeg vil ikke gi dem tilgang. M0n0wallene fungerer i praksis bare som rene brannmurer, ikke server eller klient for VPN.

[Zerge]

Aha, da vil jeg anbefale deg å installere OpenVPN på begge serverne og bruke det til å opprette en tunnel, den lar deg pushe routes i begge retninger.

http://www.runpcrun.com/howtoopenvpn

[arne22]

Spørsmål:

 

Hvis man setter opp en "ekstern" OpenVPN server, for eksempel på et eller annet datasenter, og så logger inn alt det andre av servere og klienter som klienter i et vituelt LAN under en felles virtuell gateway, vil ikke dette også kunne funke ? Altså, "den eksterne" OpenVPN server har en ekstern IP pluss 10.9.0.1 og det som finnes av klienter i det virtuelle lokal nettverket har 10.9.0.6, 10.9.0.9, osv. Kan problemstillingen løses så ekstremet enkelt som dette ? (Eller blir det veldig dårlig ytelse eller andre bieffekter ?)

 

Jeg satt opp en løsning som ligner på den nevnt over, men jeg har i grunnen ikke testet noe større med hensyn til hvor effektiv kommunikasjonen egentlig er "på tvers av" det virtualle lokalnettet. Har vel så vidt bare pinget og sett at det kommer svar.

[Pallantir]

Zerge, takk! Den må jeg få prøvd ut, men det må skje når jeg kommer meg til hytta. Jeg vil naturlig nok kjøre en full sikkerhetskopi av serveren før jeg tukler med nåværende VPN-oppsett og installerer et nytt program.

 

Arne22, jeg har nok ikke tilgang til noe sånt. Jeg har bare mine egne to punkter. Det måtte være hvis jeg satte opp en hos foreldrene mine (som har fibernett), men da er det enda en maskin som det kan skje noe med ved et uhell.

[Zerge]

Ja, det vil fungere helt fint å opprette et stjernenettverk basert på en eller annen VPN teknologi. Det viktige da er å konfigurere oppsettet slik at en klient-til-klient kommunikasjon blir tillatt.

Endret 30. april 2012 av Zerge

[Pallantir]

Men jeg går ut fra at sånne opplegg koster en del i nettleie, hva? Jeg tror ikke jeg ville betro nettverket mitt til en reklamefinansiert "cowboy-operatør", hvis de fins...

[arne22]

Jeg har satt opp en slik løsning (tror jeg) basert på en OpenVPN server som kjører på en VPS som rent fysisk står i Nederland. (Ca 100 kr pr mnd.)

 

Tanken var den at når jeg logger på flere klienter på denne OPenVPN serveren så skulle dette kunne fungere som et virtualt LAN med felles gateway nede i Nederland. Hvis tankegangen er riktig så skal dette fungere slik at man skal kunne logge på OpenVPN klienter rundt om i verden, samtidig så skal dette fungere som et virtualt LAN, som om alle OPenVPN klientene kjørte på det samme lokalnettet.

 

Hvis man er logget på dette "Virtuelle lanet" så vil jo all internetttrafikk kjøre via den virtuelle gatewayen i Nederland.

 

Tror dette vil fungere slik at hvis to PCer som står ved siden av hverandre, la oss si 2 meter på det fysiske nettet, så må all kommunikasjon mellom disse to kjøre via OPenVPN serveren i Nederland. Det blir jo to ganger pingtiden til Nederland tvers over rommet. For kommunikasjon mellom hytta og kontoret, eller bedrift og hjemmekontor, så skulle dette vel ikke by på de store problemer.

 

Noen stor risiko er det jo ikke ettersom OpenVPN serveren ikke lagrer noen data, det er jo bare en kommunikasjonsnode. Hvis man får et driftsavbrudd, så skjer det jo ikke noe annet enn at man får et lite avbrudd mens man setter opp kommunikasjonsnoden på nytt.

 

Fordelen med en slik løsning, det er jo at det blir nærmest ekstremt enkelt. Man logger på klientene og så kjører det. Enten man sitter på en flyplass, på en webkafe, eller på et hotell, så blir det det samme. Der man har en Internettforbindelse så får man også logget på det virtualle lokalnettet. (Jeg fortusetter jo egentlig da at OpenVPN kjører TCP 443, for at den skal komme gjennom "alle mulige" utgående brannmurer.)

 

Det var/er ikke mitt ønske å "stjele tråden", men mener at løsningen med "OpenVPN server in the middle" også er en meget bra variant. (Det håper jeg i alle fall, har som nevnt ikke fått testet så mye ennå.)

 

Er takknemlig for eventuellle tilbakemeldinger om "feil forståelse". (Det er jo slike tilbakemeldinger man lærer mest av.)

Endret 30. april 2012 av arne22

[Zerge]

Husk at OpenVPN kan settes i to forskjellige modes: 1: routed og 2: bridged. Hvis du ikke vet at du har en spesiell grunn for å kreve bridged, sett den opp i routed mode, da slipper du unødvendig broadcast.

 

Dersom du har 2 klienter som står 2 meter unna hverandre, så antar jeg at de er tilkoblet det samme subnettet. Da vil de per default kommunisere direkte med hverandre da nettverk som ikke trenger en gateway er øverst i prioritetslista. Dette avhenger naturligvis av hvilken IP/hostname du benytter for kommunikasjon.

 

TCP/443 er HTTPS porten. Denne er som oftest åpen i vanlige brannmurer. Jeg har også god erfaring med UDP/53 som er DNS, da slipper man litt ekstra overhead som oppstår når man kjører TCPiTCP.

Felles for alle kjente porter er at dersom det kjøres en L7 brannmur/IPS/IDS, så vil de enkelt filtrere ut OpenVPN.

[arne22]

Takker for info !

 

Nå har jeg omsider fått testet litt med en delt netshare på jobb og en klient hjemme, og jo, det er ikke tvil om at det kommuniserer helt greit "på tvers" av det virtuelle lokalnettet.

 

Mitt oppsett er "routed" fordi jeg antok at "bridged" ville få en dårligere ytelse.

 

Har ikke forsøkt å ping to PCer som står ved siden av hverandre, men når man kjører tracert hjemmesfra og til jobb, så kan man i alle fall se at den "hopper" via den eksterne "virtuelle gateway".

 

Kan i alle fall fall anbefale løsningen med en ekstern OpenVPN server som felles kommunikasjonsnode for et "virtuelt lan". Kun ett lite "men": Man bør vel ha litt kunnskap/erfaring om/med Linux brannmur og "natting" for å få til "den virtualle nat".

 

Kjente ikke til "L7 brannmur", men det må vel være denne ?:

http://en.wikipedia.org/wiki/L7-filter

Endret 6. mai 2012 av arne22

[Zerge]

L7 refererer til lag 7 i OSI-modellen, altså applikasjonslaget.

Kort fortalt er det språket som en server og klient snakker med hverandre.

Hvis du bruker IE for å hente www.vg.no, så skjer følgende:

1: IE oppretter en forespørsel i HTTP språket.

2: Operativsystemet ditt pakker forespørselen ned til L3/L2

(Avhengig av operativsystem og nettverkskort kan L2 pakking skje på nettverkskort).

3: Nettverkskortet tar seg av L1 og sender bitstrømmen ut via kabel.

4: Bitstrømmen vil så gå til switch/router og videre frem til mottaker.

(På veien vil de underste lagene bli fjernet slik at L3/L4 informasjonen kan leses av mellomliggende routere)

5: bitstrømmen ankommer vg, og steg 3,2,1 utføres og GET forespørselen når serveren.

 

En L7 brannmur er altså en brannmur som kan inspisere pakker helt opp til L7.

I utgangspunktet er det da feil å bruke ordet brannmur, da det primært er et ord som knyttes til filter opp til L4.

Dersom den kan inspisere på L7, så kan den altså filtrere ut OpenVPN hvis du bruker porter som er ment for andre applikasjoner.

 

Routed er å anbefale så lenge du ikke eksplisitt trenger bridged mode.

Du unngår unødvendig broadcasttrafikk via tunnelen din.Se også: http://www.hardware....i-modellen/1755

Endret 14. mai 2012 av Zerge

[Pallantir]

Zerge, jeg har endelig kommet meg til (etter konfirmasjon, diverse arbeid i huset og på bilen og masse annet ræl...) å sette i gang med OpenVPN. Etter å ha fulgt en grei veiledning (det tok en drøy time, men det er jo nytt territorium, jeg har aldri før satt mine bein i et sertifikat...) er jeg nå kommet så langt at jeg har fått kontaktet hjemmeserveren fra hytteserveren. For å rekapitulere er hjemmeserveren på 192.168.0.1, mens hytteserveren er 192.168.2.1. Den ser ut til å få kontakt, men problemet er at jeg ikke kan pinge noen veier. OpenVPN-kontakten er satt til 10.8.0.1, men jeg er ikke sikker på om den skal være på sitt helt eget område eller ikke. Kanskje det er det jeg har gjort feil? Jeg får noen feilmeldinger i loggen, som ser sånn ut (har fjernet personlig info, vær så snill å si fra hvis jeg ikke har fått bort alt...):

 

Tue May 22 11:02:32 2012 OpenVPN 2.0.9 Win32-MinGW [sSL] [LZO] built on Oct 1 2006

Tue May 22 11:02:32 2012 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.

Tue May 22 11:02:32 2012 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.

Tue May 22 11:02:32 2012 LZO compression initialized

Tue May 22 11:02:32 2012 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]

Tue May 22 11:02:32 2012 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]

Tue May 22 11:02:32 2012 Local Options hash (VER=V4): '41690919'

Tue May 22 11:02:32 2012 Expected Remote Options hash (VER=V4): '530fdded'

Tue May 22 11:02:32 2012 UDPv4 link local: [undef]

Tue May 22 11:02:32 2012 UDPv4 link remote: [VPN-serverens IP-adresse]:1194

Tue May 22 11:02:32 2012 TLS: Initial packet from [VPN-serverens IP-adresse]:1194, sid=6d294a39 b5a428b0

 

(her har jeg fjernet personlig info - trenger du å vite noe av dette?)

Tue May 22 11:02:33 2012 VERIFY OK: depth=1, /C=NO/

Tue May 22 11:02:33 2012 VERIFY OK: depth=0, /C=NO/

(her har jeg fjernet personlig info - trenger du å vite noe av dette?)

 

Tue May 22 11:02:33 2012 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

Tue May 22 11:02:33 2012 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Tue May 22 11:02:33 2012 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key

Tue May 22 11:02:33 2012 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Tue May 22 11:02:33 2012 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

Tue May 22 11:02:33 2012 [server] Peer Connection Initiated with [VPN-serverens IP-adresse]:1194

Tue May 22 11:02:34 2012 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)

Tue May 22 11:02:34 2012 PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,dhcp-option WINS 192.168.0.1,dhcp-option DNS 192.168.0.1,dhcp-option DOMAIN acme.com.local,route 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'

Tue May 22 11:02:34 2012 OPTIONS IMPORT: timers and/or timeouts modified

Tue May 22 11:02:34 2012 OPTIONS IMPORT: --ifconfig/up options modified

Tue May 22 11:02:34 2012 OPTIONS IMPORT: route options modified

Tue May 22 11:02:34 2012 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

Tue May 22 11:02:34 2012 TAP-WIN32 device [Open VPN-tilkobling] opened: \\.\Global\{D2CDEC9A-84D0-4DBC-8057-4D71469AD6E1}.tap

Tue May 22 11:02:34 2012 TAP-Win32 Driver Version 8.1

Tue May 22 11:02:34 2012 TAP-Win32 MTU=1500

Tue May 22 11:02:34 2012 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {D2CDEC9A-84D0-4DBC-8057-4D71469AD6E1} [DHCP-serv: 10.8.0.5, lease-time: 31536000]

Tue May 22 11:02:34 2012 NOTE: FlushIpNetTable failed on interface [3] {D2CDEC9A-84D0-4DBC-8057-4D71469AD6E1} (status=1413) : Invalid index.

Tue May 22 11:02:34 2012 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down

Tue May 22 11:02:34 2012 Route: Waiting for TUN/TAP interface to come up...

Tue May 22 11:02:35 2012 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down

Tue May 22 11:02:35 2012 Route: Waiting for TUN/TAP interface to come up...

Tue May 22 11:02:37 2012 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up

Tue May 22 11:02:37 2012 route ADD 192.168.0.0 MASK 255.255.255.0 10.8.0.5

Tue May 22 11:02:37 2012 ROUTE: route addition failed using CreateIpForwardEntry: The parameter is incorrect. [if_index=3]

Tue May 22 11:02:37 2012 Route addition via IPAPI failed

Tue May 22 11:02:37 2012 route ADD 10.8.0.1 MASK 255.255.255.255 10.8.0.5

Tue May 22 11:02:37 2012 ROUTE: route addition failed using CreateIpForwardEntry: The parameter is incorrect. [if_index=3]

Tue May 22 11:02:37 2012 Route addition via IPAPI failed

Tue May 22 11:02:37 2012 Initialization Sequence Completed

[/Quote]

 

Jeg har lagt til static routes i Routing and Remote Access, og jeg har lagt inn det virtuelle OpenVPN-kortet som eksternt kort koblet til internet i IP Routing, under NAT/Basic Firewall. Men jeg klarer heller ikke å pinge 10.8.0.1 fra hyttesiden, bare den sidens virtuelle OpenVPN-kort 10.8.0.6, mens jeg bare klarer å pinge 10.8.0.1 fra serversiden. Så et eller annet sted er det nok en feil innstilling eller noe sånt. Håper du kan være så snill å hjelpe meg igjen!

 

Edit: Kom på at du kanskje bør se configfilene. Serveren:

 

## server.ovpn ##

port 1194

proto udp

dev tun

ca ca.crt

cert MittFirmanavn.crt

key MittFirmanavn.key

dh dh1024.pem

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "route 192.168.0.0 255.255.255.0"

push "dhcp-option WINS 192.168.0.1"

push "dhcp-option DNS 192.168.0.1"

push "dhcp-option DOMAIN acme.com.local"

keepalive 10 120

comp-lzo

max-clients 1

persist-key

persist-tun

status openvpn-status.log

verb 3

 

Her ser jeg den med acme.com.local, men vet ikke om den skal endres.

 

## acme.ovpn ##

client

proto udp

dev tun

remote IP-adressen min 1194

resolv-retry infinite

nobind

persist-key

persist-tun

ca ca.crt

cert Hytteserver.crt

key Hytteserver.key

comp-lzo

verb 3

 

Det kan jo ikke være noe med sertifikat eller noe sånt, for den får kontakt og sier at den har kommet seg på plass. Problemet må ligge et sted i rutingen. Antakeligvis i selve OpenVPN siden jeg ikke klarer å pinge 10-serien til OpenVPN ordentlig. Eller er jeg helt på jordet nå?

Endret 22. mai 2012 av Pallantir

[Zerge]

Etter hva jeg kan se, så kobles jo tunnelen opp helt greit.

Det første du kan teste og må få til å fungere, er at klienten kan pinge 10.8.0.1. Dersom dette ikke fungerer, så er det helt sikkert en brannmur på serveren som ikke er konfigurert for tun0 interfacet som OpenVPN pakkene blir terminert på.

 

Du kan eventuelt sjekke med tcpdump/wireshark på interfacet for å spore hvor langt pakkene kommer.

"netstat -rn" i kommandolinja vil også printe ut routertabellen.

 

Husk at dersom du får tildelt 10.8.0.6 med gateway 10.8.0.5 på klienten, så er 10.8.0.5 en dummyadresse som ikke kan brukes til noe annet enn å videresende pakker til 10.8.0.1, altså vil ikke .5 svare på ping.

 

Og, hvis du bruker Windows, så kan det være en fordel å rename TAP/TUN interfacet og så bruke "dev-node " i .ovpn fila for å eksplisitt fortelle OpenVPN hvilket interface den skal bruke.

# Windows needs the TAP-Win32 adapter name

# from the Network Connections panel

# if you have more than one. On XP SP2,

# you may need to disable the firewall

# for the TAP adapter.

[Pallantir]

Zerge, takk igjen! Da har jeg endelig fått tid (vel, tatt meg tid...i 3-4 timer med eksperimentering mens kona tror jeg jobber...), og jeg har kommet så langt: Jeg får nå pinget 10.8.0.1 fra begge sider. Fra alle maskiner på klientsiden kan jeg komme til alle maskiner som er på serversiden, men fra serversiden kommer jeg ikke til noe som helst på klientsiden.

 

Jeg måtte endre "dev tun" til "dev tap" for å komme noen vei i det hele tatt. Det betyr vel at den gikk over i bridged mode, ikke sant? Jeg eksperimenterte litt mer, og denne linjen:

 

server 10.8.0.0.255.255.255.0

 

byttet jeg ut med denne linjen fra et nettsted:

 

server-bridge 192.168.0.250 255.255.255.0 192.168.0.251 192.168.0.254

 

Men da fikk ikke den som før var 10.8.0.0 noen adresse og havnet på 169. et eller annet. I tillegg prøvde jeg meg med å legge til dette på klientconfigen:

 

push "route 192.168.2.0 255.255.255.0"

push "dhcp-option WINS 192.168.2.1"

push "dhcp-option DNS 192.168.2.1"

 

Men det hjalp heller ikke med å komme fra servernettverket til klientnettverket. Den eneste måten jeg kan kjøre begge veier er ved å ha OpenVPN fra hytteserveren og til hjemmeserveren og kjøre Windows Servers innebygde PPTP-VPN motsatt vei. Men jeg håpet jeg kunne bare bruke OpenVPN.

 

Beklager at jeg er så totalt håpløs på dette, men kanskje du kan se en enkel feil jeg har gjort?

Endret 4. juni 2012 av Pallantir

[Zerge]

Hei, for å få til routing mot et nettverk bak en tilkoblet klient, se her: "http://openvpn.net/index.php/open-source/documentation/howto.html#scope",

spesielt under "Including multiple machines on the client side when using a routed VPN (dev tun)"

 

Merk at det gjelder for tun/routed mode!

 

Hvis du ikke har forstått forskjellen mellom routed og bridged mode enda, så kan jeg prøve å forklare det kjapt:

 

Bridged - brukes for å koble VPN-klienter direkte inn på et LAN bak OpenVPN serveren.

Server: eth1 og tap1 må bridges på nettverkskortene (uavhengig av OpenVPN) og "server-bridge" parameteren konfigureres i samme LAN som bak serveren.

For å få tilgang til servere bak en klient, må eth1 og tap1 på clienten også bridges og LANet utvides her og. Dvs. alle IPr i de 2 fysiske interne sonene dine ligger i samme subnet.

Det negative med bridged er at all broadcasttrafikk vil bli sendt over VPN forbindelsen, alltid. Dette gir litt overhead og er ikke alltid like hensiktsmessig.

 

Routed - brukes i alle tilfeller der det eksplisitt ikke er nødvendig med bridged. Altså anbefales dette sterkt!

Som du ser i linken øverst, må du konfigurere litt ekstra på VPN serveren din, for at den skal være klar over at en tilkoblet klient har et ekstra subnet bak seg. Den vil da også automatisk oppdatere sin routingtabell for å se til at pakker kommer riktig tilbake igjen.

[Pallantir]

Der satt den, gitt! Tusen takk for hjelpen! Med litt fikling fikk jeg også lagt inn autostart av tunnelen ved oppstart av maskinen på hytta. Det er jo fullkomment idiotisk at man ikke kan sende en --connect kommado til GUI-en hvis GUI-en allerede er åpnet, men det var mulig å omgå.

 

Det eneste jeg ikke har funnet ut av nå, er en måte å sørge for at tunnelen kommer opp igjen snarest hvis det er strømbrudd eller noe lignende som gjør at den mister forbindelsen. Vet du om et triks der? Hvis ikke, kan jeg jo sette Girder til å pinge sitt motstykke på hjemmeserveren og så tvangslukke GUI-en for OpenVPN og kjøre startkommando med --Connect hvis det ikke er kontakt. Det virker bare litt unøvendig komplisert. Vet du om noe der? Jeg prøvde å google og snuse litt, men ifølge det jeg fant, skulle det skje automatisk. Og jeg har ikke fått den til å gjøre det ennå.

 

Edit: Det er forresten en merkelig ting til: Da jeg brukte TAP som device, skjedde alltid tilkoblingen på første forsøk. Med TUN står den og tygger i et minutt uten å få kontakt og prøver på nytt minst 2-3 ganger før det går i boks. Den viser i loggvinduet at den har riktig IP-adresse, men den får ikke noe svar på første forsøk, som med TAP. Har du noen anelse om hva forskjellen der skyldes?

Endret 7. juni 2012 av Pallantir