OpenVPN v Windows: samodejni zagon tunela in ohranitev poti

Tu se prepleteta dve zahtevi: tunel bi se moral dvigniti preden se kdor koli prijavi, promet do drugega mesta pa bi mu moral slediti. To sta ločeni težavi z ločenimi mehanizmi. Zagon storitve odloči prvo, življenjska doba poti pa drugo. Rešitev ene pusti drugo točno tam, kjer je bila.

Prvi korak: postavite profil tja, kjer ga storitev išče

Storitev Windows bere profile iz stalnega imenika, GUI pa bere z istega mesta, zato je profil, ki deluje ob uvozu, ob zagonu lahko še vedno neviden. Datoteke .ovpn postavite v imenik config namestitve, ki je običajno pod Program Files. Profil, ki ostane v mapi Downloads uporabnika, sploh ni v obsegu storitve.

Starejša navodila kažejo na mapo config-auto, ki so jo nekatere gradnje iz obdobja 2.5 spoštovale, poznejše izdaje pa ne. Zato lahko posodobitev delujoč samodejni zagon spremeni v tišino, brez česar koli v dnevniku o poverilnicah. Preden premaknete katero koli datoteko, potrdite, kateri imenik nameščena gradnja v resnici bere.

Če je na enem računalniku več profilov, dajte vsakemu poimenovan vmesnik prek dev-node. Sicer tekmujejo za isti vmesnik in drugi spodleti na način, ki je videti kot težava s poverilnicami.

Drugi korak: zaženite storitev, ne ikone v sistemski vrstici

Nastavitev storitve OpenVPN na Automatic poskrbi, da se zažene ob zagonu brez prijave. To je mehanizem in ikona v vrstici ni del tega. Ko storitev poseduje povezavo, GUI morda ne prikaže ne ikone ne stanja, kar je pričakovano in ne okvara.

Posledica je, da prekinitev pomeni ustavitev storitve, ne klik na Disconnect. Povejte to tistemu, ki vzdržuje računalnik, sicer bo prvi klic v podporo o manjkajoči ikoni.

Preverite, ali lahko račun storitve bere profil in ključno gradivo. Težava z dovoljenji ob zagonu je v dnevniku videti natanko kot neuspešna overitev.

Tretji korak: povežite pot s tunelom

Trajni vnos je tu napačno orodje. Dodajanje poti z -P poskrbi, da preživi ponovne zagone in, še huje, da preživi zaprtje tunela. Ko je VPN izklopljen, predpona še vedno kaže na prehod, ki ga ni več, zato gostitelj ne doseže tega cilja, dokler nekdo ne izbriše vnosa.

Tri možnosti se obnašajo pravilno. Potisnite pot s strežnika, ki jo doda ob povezavi in odstrani ob prekinitvi. Dodajte jo v skript route-up, ki bere route_vpn_gateway, da naslednji skok pride iz dogovorjenega tunela. Ali uporabite Add-VpnConnectionRoute z izvornim profilom VPN Windows, ki predpono veže na to povezavo.

Ko strežnik ponuja več, kot to mesto potrebuje, route-nopull zavrne potisnjene poti in tabelo pusti povsem krajevno. To ustreza skupnemu profilu, katerega uporabniki ne smejo prejeti privzete poti podjetja.

Četrti korak: preživite hladen zagon

Zagon storitve, preden obstaja omrežni sklad, da en neuspešen poskus in nobene ponovitve. Nastavitev na Automatic (Delayed Start) ali dodajanje odvisnosti od omrežne storitve to tekmo odpravi. Nato ponovite test zagona in preverite, da drugi poskus ni več potreben.

Spremembe poti in vmesnika zahtevajo skrbniške pravice. Bližnjica za zagon posameznega uporabnika jih nima, zato skript, ki deluje iz povišane lupine, ob prijavi lahko tiho ne naredi ničesar. Načrtujte ga kot opravilo z najvišjimi pravicami ali prepustite spremembo storitvi. Nato ga preizkusite kot uporabnik, ki se bo res prijavil.

Preizkusite zaporedje, ki ga res uvajate, ne tistega, ki ga lahko sprožite ročno. Hladen zagon je edini test, ki preizkusi vrstni red.

Peti korak: preverite brez GUI

Po ponovnem zagonu in prijavi preverite tri stvari, ne da bi odprli GUI. Vmesnik mora imeti naslov,tabela poti mora prikazovati predpono mesta s prehodom tunela kot naslednjim skokom, ping na naslov na drugi strani pa se mora odzvati. Vsako preverjanje ustreza drugemu mehanizmu iz korakov zgoraj.

Ko se vmesnik nikoli ne pojavi, je sumljiv gonilnik, ne profil. Ti dve okvari sta v dnevniku videti povsem različno in le ena od njiju se odzove na ponovno namestitev programske opreme.