Zerge Skrevet 7. juni 2012 Del Skrevet 7. juni 2012 Dersom du installerte OpenVPN, så har det som standard blitt installert en service. Hvis du kun har en config fil i riktig katalog, så kan du bare aktivere servicen under services.msc, og vips vil den alltid starte, selv før pålogging på serveren, men du vil ikke se noe statusvindu. Det høres merkelig ut at den står og tygger, selv opplever jeg at det kan ta litt tid før tunnelen kommer opp, men det hører til sjeldenhetene at den får timeout og prøver igjen. Der har jeg ingen forslag. Lenke til kommentar
Pallantir Skrevet 7. juni 2012 Forfatter Del Skrevet 7. juni 2012 (endret) Jeg har den som service, ja. Men snakker ikke du nå om å kjøre opp serveren automatisk? For jeg mente å få klienten/hytteserveren til å koble seg automatisk til når klienten/hytteserveren den starter. Det varierer vaktisk litt innimellom om den må tygge eller ikke. Men jeg har også oppdaget hvorfor jeg trodde at den ikke koblet seg automatisk til igjen ved droppet linje: Noen ganger vil ikke rutingen fra serveren til klienten fungere riktig. Jeg får ping fra klientens nettverk til serverens nettverk, men ikke omvendt. Aner ikke hvorfor, men jeg tipper at det krever så mye tid å finne ut av akkurat det at det er enkelere å basere seg på å ta en omstart av forbindelsen når den svikter. Forhåpentligvis blir det ikke så ofte. Edit: Nå har den stått og prøvde å koble seg til igjen (gult ikon) etter et avbrudd i fem minutter. Merkelige greier. Den viser i loggen at den ikke får forbindelse og prøver på nytt hvert minutt. Snåle greier. Det er nok det den av og til bruker mange flere ganger på å koble seg til som gjør at jeg ikke trodde den gjorde det automatisk. Edit 2: Glem den. Det viste seg at tjenesten på serveren ikke hadde startet. Jeg hadde en batchfil til å stoppe og starte tjenesten, men den hadde bare stoppet den fordi det gikk for kort tid mellom de to kommandoene. Jeg måtte legge inn en 5 sekunders pause for å få den til å starte hver eneste gang: PING 1.1.1.1 -n 1 -w 000 &--#62;NUL Så hvis jeg nå bare kan finne ut hvordan jeg får klienten til å oppdage litt raskere at det ikke er kontakt, tror jeg faktisk at jeg er i boks! Prøvde med keepalive 10 10 på klienten, men klienter skal visst ikke ha den parameteren. Vet du om det fins noe tilsvarende for klienter? Jeg fant det ikke ved googling. Endret 7. juni 2012 av Pallantir Lenke til kommentar
Zerge Skrevet 10. juni 2012 Del Skrevet 10. juni 2012 Du kan sette opp klienten som en service og. Dette med keep-alive har jeg faktisk aldri hatt behov for å tune, men du kan jo se om du får til en bedre ytelse på det. Lenke til kommentar
Pallantir Skrevet 11. juni 2012 Forfatter Del Skrevet 11. juni 2012 (endret) Takk, men service tror jeg ikke går, for idet serveren starter opp, starter den en virtuell maskin med M0n0wall, og det er gjennom den Internett kommer. Jeg har fem ekstra nettverkskort i serveren til forskjellige VM'er, både PCI-E og USB. To av disse er til M0n0wall, så nettlinjen går inn på det ene, gjennom M0n0wallen, ut fra det andre og så en kort kabel inn til det nettverkskortet serveren bruker som egen internettlinje inn - smått innviklet for en privat server, men sparer meg for en ekstra, ekstern maskin med M0n0wall på. Dermed er det ikke mulig å kjøre opp internettlinjen før M0n0wall-VM-en har startet, så jeg regnet med at OpenVPN som service vil bli stående og tygge enda lenger før den oppdager at Internett er tilgjengelig. Eller vil det gå ganske kjapt? Men hvis det fungerer greit, er det vel bare å laste ned Desktop Client Package og følge denne rettledningen, ikke sant: http://openvpn.net/i...rvice-mode.html Litt vanskelig å teste det nå, for jeg er ikke i samme fylke som klientmaskinen/hytteserveren engang, så hvis den skulle låse seg, måtte jeg fjernstyrt faren min for å få startet pc-en om igjen. Det er ikke helt lett... Og ikke minst vil jeg ta en full imagebackup av operativsystemet på hytteserveren før jeg gjør noe som helst mer, etter så lang tid for å få ting til å fungere, tar jeg ikke sjansen på å miste det! Endret 11. juni 2012 av Pallantir Lenke til kommentar
Zerge Skrevet 12. juni 2012 Del Skrevet 12. juni 2012 Nå kom jeg på noe, du har kanskje ikke brukt Community (gratis) utgaven av OpenVPN? http://openvpn.net/index.php/open-source/downloads.html Å sette opp som en service gjør at den bare prøver å reconnecte helt til den får kontakt. Her kan man selv sette innstillinger for hvor ofte den skal prøve, og når den får Internett vil da tunnelen komme oppe Lenke til kommentar
Pallantir Skrevet 12. juni 2012 Forfatter Del Skrevet 12. juni 2012 Jo da, det er 2.2.2. som er i drift her, takk. Setter jeg de innstillingene i configfila på klienten? Den har for øvrig surret og gått uten å miste en pakke (iallfall som jeg har merket) siden forrige torsdag. Akkurat like pålitelig som den innebygde i Windows Server 2003, virker det som! Lenke til kommentar
Zerge Skrevet 12. juni 2012 Del Skrevet 12. juni 2012 Innstillinger i configfilen ja. Jeg har brukt OpenVPN på Window, Linux, *BSD, OSX siden en gang i 2004 og har aldri opplevd noen problemer med stabiliteten. Fordelen med å kunne sette opp tunneler via en valgfri TCP/UDP port vinner over de fleste andre løsninger jeg har jobbet med. Lenke til kommentar
Pallantir Skrevet 12. juni 2012 Forfatter Del Skrevet 12. juni 2012 Takk igjen! Ja, jeg har brukt en helt annen port enn den som var standard, for jeg så at da jeg åpnet den, var det en del bots eller script kiddies som sto og stanget mot den konstant. Og sånt vil vi ikke ha noe av. Lenke til kommentar
Pallantir Skrevet 7. august 2012 Forfatter Del Skrevet 7. august 2012 Etter snart to måneders kjøring må jeg bare anbefale denne løsningen til alle som trenger VPN! Funker helt ypperlig, ingen som helst problemer. Tok ned hytteserveren for å bytte en harddisk i dag (mer plass til filmer...), og da hadde tunnelen vært i konstant drift, uten avbrudd så vidt jeg har sett, siden juni. Windows 2003 Server og OpenVPN er en ufattelig stabil løsning. Igjen takk for hjelpen, Zerge! Lenke til kommentar
Pallantir Skrevet 20. februar 2014 Forfatter Del Skrevet 20. februar 2014 Snakker om å gjenopplive en zombietråd. Jeg har byttet server hjemme, installert OpenVPN på den og regnet med at det var bare å tute og kjøre med samme konfigurasjon, ved å kopiere alt sammen over til der det lå. Selvsagt fikk jeg en på trynet... Jeg får kontakt, men kan ikke pinge noe som helst. Jeg får en del feilmeldinger på klienten: Thu Feb 20 23:06:18 2014 TAP-WIN32 device [OpenVPN] opened: \\.\Global\{F7485E98-BED7-4A0C-A3FF-9EA38B4F8BBC}.tapThu Feb 20 23:06:18 2014 TAP-Win32 Driver Version 9.9Thu Feb 20 23:06:18 2014 TAP-Win32 MTU=1500Thu Feb 20 23:06:18 2014 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {F7485E98-BED7-4A0C-A3FF-9EA38B4F8BBC} [DHCP-serv: 10.8.0.5, lease-time: 31536000]Thu Feb 20 23:06:18 2014 NOTE: FlushIpNetTable failed on interface [262147] {F7485E98-BED7-4A0C-A3FF-9EA38B4F8BBC} (status=259) : No more data is available. Thu Feb 20 23:06:23 2014 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=upThu Feb 20 23:06:23 2014 C:\WINDOWS\system32\route.exe ADD 192.168.0.0 MASK 255.255.255.0 10.8.0.5Thu Feb 20 23:06:23 2014 ROUTE: route addition failed using CreateIpForwardEntry: The parameter is incorrect. [status=87 if_index=262147]Thu Feb 20 23:06:23 2014 Route addition via IPAPI failed [adaptive]Thu Feb 20 23:06:23 2014 Route addition fallback to route.exeThe route addition failed: The parameter is incorrect.Thu Feb 20 23:06:23 2014 C:\WINDOWS\system32\route.exe ADD 10.8.0.1 MASK 255.255.255.255 10.8.0.5Thu Feb 20 23:06:23 2014 ROUTE: route addition failed using CreateIpForwardEntry: The parameter is incorrect. [status=87 if_index=262147]Thu Feb 20 23:06:23 2014 Route addition via IPAPI failed [adaptive]Thu Feb 20 23:06:23 2014 Route addition fallback to route.exeThe route addition failed: The parameter is incorrect.Thu Feb 20 23:06:23 2014 Initialization Sequence Completed Nå har jeg prøvd meg selv halve dagen, og googlet til øyet ble stort og vått, men jeg kommer bare ikke videre! Ville sette stor pris på hjelp! Lenke til kommentar
Zerge Skrevet 22. februar 2014 Del Skrevet 22. februar 2014 Har du husket at programfilene må kjøres som administrator for å kunne opprette routes riktig? Høyreklikk på openvpn.exe og openvpn-gui.exe og velg egenskaper, kompabilitet og huk av for "kjør dette programmet som administrator" eller tilsvarende oversettelse Lenke til kommentar
Pallantir Skrevet 23. februar 2014 Forfatter Del Skrevet 23. februar 2014 (endret) Takk for at du har tid til å prøve å hjelpe meg igjen! Det må være smått frustrerende for en IT-proff å skulle holde hånden til en glad amatør. Jeg antar at du føler det omtrent som jeg føler det når jeg hjelper alle kjente, familie og venner med forskjellige datagreier! Jeg håpet virkelig at det var så enkelt... Men dessverre. Jeg hadde riktignok ikke kjørt dem som administrator før, men jeg har brukt en administratorkonto på serveren. Jeg så fremdeles de samme feilene på klienten, og jeg klarte ikke å pinge noe som helst. Men med nye krefter og våkent sinn (og femmila på tv-en, selv om jeg ikke vet om det hjalp så mye, det blir ingen gjentakelse av tremila i går) fant jeg fram til noe som hjalp meg et stykke. Jeg la til dette i klienten etter å ha funnet et Google-resultat jeg ikke så forrige gang jeg lette: route-method exeroute-delay 10 Dermed er klientens fulle config sånn (address has been changed to protect the...guilty): ## Pallantir.ovpn ##clientproto udpdev tunremote <ip-adresse> <port> resolv-retry infinitenobindpush "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"persist-keypersist-tunns-cert-type serverca ca.crtcert Hytteserver.crtkey Hytteserver.keycomp-lzoverb 3route-method exeroute-delay 10 Dermed kom jeg hakket videre, for jeg har full tilgang til alle maskiner på nettverket hjemme fra hytteserveren, men bare med IP-adresse. Jeg har ikke tilgang med datamaskinnavn, som jeg har hatt før. Og jeg får fremdeles ikke tilgang fra klientmaskiner på hyttenettet. Og jeg har altså egentlig ikke endret noe der. I tillegg får jeg ikke engang pinget hytteserveren fra hjemmeserveren, så den veien går det ikke neo som helst. Jeg får fremdeles en feil som jeg tror kan være årsaken til det siste, selv om jeg ikke er sikker: NOTE: FlushIpNetTable failed on interface [3] {F7485E98-BED7-4A0C-A3FF-9EA38B4F8BBC} (status=1413) : Invalid index. Har du noen anelse om hva det er snakk om? Hvis det har noe å si, er serverkonfigurasjonen her: ## server.ovpn ##port XXXXXproto udpdev tunca ca.crtcert Pallantir.crtkey Pallantir.keydh dh1024.pemserver 10.8.0.0 255.255.255.0ifconfig-pool-persist ipp.txtpush "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 megaboff.no"keepalive 5 10comp-lzomax-clients 1persist-keypersist-tunstatus openvpn-status.logverb 3 Endret 23. februar 2014 av Pallantir Lenke til kommentar
Zerge Skrevet 24. februar 2014 Del Skrevet 24. februar 2014 (endret) Det virker som om du konfigurerer opp klienten din feil i forhold til å få routes til å fungere riktig. Se her for en fin guide: http://community.openvpn.net/openvpn/wiki/RoutedLans I tillegg må du huske at IP Routing må være aktivert på alle maskiner. For Windows, skriv ipconfig /all i kommandolinja og sjekk om den er aktivert: Windows IP Configuration Host Name . . . . . . . . . . . . : XXXXXXX Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : contoso.com Til slutt kan det jo være at du har en brannmur som filtrerer i den ene eller andre retningen? Husk at TAP/TUN interface også blir filtrert. Endret 24. februar 2014 av Zerge Lenke til kommentar
Pallantir Skrevet 24. februar 2014 Forfatter Del Skrevet 24. februar 2014 Det er det siste som er så snålt her. For jeg har ikke endret OpenVPN-klienten (altså hytteserveren) i det hele tatt, bare OpenVPN-serveren (altså hjemmeserveren). Og før jeg byttet hjemmeserver, fungerte det prikkfritt i to år. Serveren kjører Server 2008 R2, med Windows Firewall. Det hjelper ikke å skru av den. Klienten kjører Server 2003 R2, uten noen form for brannmur. Utenfor disse maskinene (mellom de to maskinene og Internett) er det M0n0wall-brannmurer, men siden tunnelen jo går til maskiner som er på innsiden av disse brannmurene, bør ikke det ha noe å si. ipconfig /all for klienten ga (noe jeg for så vidt alt viste siden RAS kjører på begge maskinene) som resultat at både IP Routing og WINS proxy var i drift. Eneste rare var at den var Node Type unknown, men det tror jeg som sagt ikke har noe å si fordi rutingen funket perfekt før. På OpenVPN-serveren (altså den nye maskinen) var det type hybrid, men der var det av en eller annen grunn no på WINS proxy. Kanskje det kan ha noe med saken å gjøre? Jeg skal sjekke oppsettet på den gamle serveren og se om WINS proxy var på der. Det kan sikkert være en ørliten forskjell i innstillingene som er hele årsaken. Lenke til kommentar
Pallantir Skrevet 24. februar 2014 Forfatter Del Skrevet 24. februar 2014 Det hjalp ikke å endre registersettingen for WINS proxy, det ga meg ikke Yes på WINS proxy i 2008. Jeg hadde en feil i static route på serveren (altså hjemmeserveren/OpenVPN-serveren), og det fikk meg et lite hakk lenger å rette på den. Jeg kan pinge den andre enden av tunnelen fra både klient og server, men bare pinge maskiner bak tunnelen (altså på LAN) fra klient til server. Og da bare med IP-adresse, ikke med datamaskinnavn. Før jeg byttet hjemmeserveren hadde jeg full tilgang begge veier. Lenke til kommentar
Pallantir Skrevet 24. februar 2014 Forfatter Del Skrevet 24. februar 2014 (endret) Koblet opp den gamle serveren igjen og testet, og den gikk akkurat som den skulle med de innstillingene jeg har hatt til nå. Så fiklet jeg litt med tun/tap med den nye serveren, og satte begge to på tap. Da kom jeg et stykke videre. Endret til dev tap på begge pc-ene, og da kan jeg komme fra alle pc-er bak server til alt på hyttenettverket med datamaskinnavn, men motsatt vei må jeg bruke IP-adresser på alt unntatt selve serveren. Da var heller ikke route-method exe nødvendig. Lurer på om det enkleste da blir å sette opp NAME i DNS? Forresten snålt at det ikke funket på dev tun, som før. Men det går iallfall framover... Lurer på om det kan være noen endringer i opplegget for RAS fra 2003 R2 til 2008 R2 som er årsaken til at det knoter seg? Endret 24. februar 2014 av Pallantir Lenke til kommentar
Zerge Skrevet 24. februar 2014 Del Skrevet 24. februar 2014 Får du ikke pinget 10.8.0.1 fra klienten? det burde du få til, men så lenge tunnelen fungerer så er vi vel i mål med OpenVPN? Navneoppslag er naturlig nok noe annet. benytter du både WINS og DNS? Jeg har kun erfaring med DNS og da er nslookup gull verdt. Jeg ser du har satt push dhcp-option i client config, men dette er kun støttet i server config. I tillegg ser jeg at du definerer 2 ulike DNS servere. Her har du nok noe du kan se nærmere på og rydde opp:) Lenke til kommentar
Pallantir Skrevet 24. februar 2014 Forfatter Del Skrevet 24. februar 2014 Sånn, satte -- foran de to push dhcp i klienten, det var tydeligvis ingen vits i å ha dem here, for det endret seg ikke. Det samme gjaldt WINS på serveren. Men hvor er det to DNS-serrvere? Den er jeg ikke helt med på, er jeg redd... Hvis du da ikke mente den som var i kliente, som nå er fjernet. Men jeg kommer iallfall begge veier ved å bruke IP-addresser, og da kan jeg jo legge inn ha A-host-oppføringer for alt som er på de to nettverkene. Litt irriterende at det fungerte uten før, men vi får se hva som skjer når jeg bytter ut serveren på hytta også (altså OpenVPN-kliente) om en drøy uke med tvillingen til den nye hjemmeserveren. Takk igjen for hjelpen, jeg tror jeg gir meg mens leken er god og bruker A-hoster som krykker! Lenke til kommentar
Zerge Skrevet 24. februar 2014 Del Skrevet 24. februar 2014 Da høres det veldig ut som om din forrige server hadde WINS installert. navneoppslag uten WINS/DNS vil kun fungere i et og samme LAN, da det brukes broadcast. Med WINS eller DNS m/dynamiske oppdateringer, så vil klientene oppdatere serverdatabasene jevnlig med sine IP-addresser, noe som gjør at navneoppslag kan fungere mellom subnet også. Lenke til kommentar
Pallantir Skrevet 25. februar 2014 Forfatter Del Skrevet 25. februar 2014 Ja, jeg tror også det kan ligge noe der. Som sagt er det ganske snålt at den gamle 2003 R2-serveren sto oppført som WINS-proxy (uten å ha lagt til WINS-serverrollen), mens den nye 2008 R2-serveren ikke gjør det. Men med det jeg har lest om proxy-funksjonen virker ikke det som om den skal spille inn, siden den ser ut til å være for å få ikke-Windows-klienter til å dukke opp i WINS. Kanskje jeg etter hvert gjør et forsøk (etter et image-backup, så klart) på å installere WINS og se om det hjelper. Men først skal jeg altså bytte ut hytteserveren. Det kan jo hende at alt løser seg som ved trolldom da... Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå