OpenVPN en Windows: aŭtomate startigi la tunelon kaj konservi la vojojn

Ĉi tie interplektiĝas du postuloj: la tunelo devas leviĝi antaŭ ol iu ajn ensalutas, kaj trafiko al dua retejo devas sekvi ĝin. Temas pri apartaj problemoj kun apartaj mekanismoj. La servo-startigo decidas la unuan, kaj la vivdaŭro de la vojo la duan. Solvi unu lasas la alian ĝuste tie, kie ĝi estis.

Unua paŝo: metu la profilon tien, kie la servo serĉas ĝin

La Windows-servo legas profilojn el fiksa dosierujo, kaj la GUI legas el la sama loko, do profilo, kiu funkcias kiam vi importas ĝin, povas resti nevidebla ĉe starto. Metu la dosierojn .ovpn en la config-dosierujon de la instalado, kiu kutime troviĝas sub Program Files. Profilo lasita en la Downloads-dosierujo de uzanto tute ne estas en la amplekso de la servo.

Pli malnovaj gvidlinioj montras al dosierujo config-auto, kiun respektis iuj konstruoj de la 2.5-epoko kaj postaj eldonoj ne. Tial ĝisdatigo povas ŝanĝi funkciantan aŭtomatan starton en silenton, sen io ajn en la protokolo pri akreditiloj. Konfirmu, kiun dosierujon la instalita konstruo efektive legas, antaŭ ol movi iujn ajn dosierojn.

Se estas pluraj profiloj sur unu maŝino, donu al ĉiu nomitan adaptilon per dev-node. Alie ili konkuras pri la sama interfaco kaj la dua malsukcesas tiel, ke ĝi aspektas kiel problemo pri akreditilo.

Dua paŝo: startigu la servon anstataŭ la pleto-ikonon

Meti la servon OpenVPN al Automatic igas ĝin starti ĉe la lanĉo sen ensaluto. Tio estas la mekanismo, kaj la pleto-ikono ne estas parto de ĝi. Kiam la servo posedas la konekton, la GUI eble montras neniun ikonon kaj neniun staton, kio estas atendita, ne difekto.

La sekvo estas, ke malkonekti signifas haltigi la servon, ne klaki Disconnect. Diru tion al kiu ajn subtenas la maŝinon, alie la unua subtena alvoko temas pri mankanta ikono.

Kontrolu, ĉu la servokonto povas legi la profilon kaj la ŝlosilan materialon. Permesa problemo ĉe lanĉo aspektas en la protokolo ĝuste kiel malsukcesa aŭtentigo.

Tria paŝo: ligu la vojon al la tunelo

Daŭra enskribo estas la malĝusta ilo ĉi tie. Aldoni vojon per -P igas ĝin postvivi restartigojn kaj, pli malbone, postvivi la fermon de la tunelo. Kun la VPN malsupre, la antaŭsigno ankoraŭ montras al enirejo, kiu ne plu ekzistas, do la gastiganto ne povas atingi tiun celon ĝis iu forigos la enskribon.

Tri alternativoj kondutas ĝuste. Puŝu la vojon de la servilo, kiu aldonas ĝin ĉe konekto kaj forigas ĝin ĉe malkonekto. Aldonu ĝin en route-up-skripto, kiu legas route_vpn_gateway, por ke la sekva salto venu el la intertraktita tunelo. Aŭ uzu Add-VpnConnectionRoute kun denaska Windows-VPN-profilo, kiu ligas la antaŭsignon al tiu konekto.

Kiam la servilo proponas pli ol ĉi tiu retejo bezonas, route-nopull rifuzas la puŝitajn vojojn kaj lasas la tabelon tute loka. Tio taŭgas por komuna profilo, kies uzantoj ne rajtas ricevi korporacian defaŭltan vojon.

Kvara paŝo: postvivu malvarman lanĉon

Startigi la servon antaŭ ol ekzistas la reta stako produktas unu malsukcesan provon kaj neniun ripeton. Meti ĝin al Automatic (Delayed Start), aŭ aldoni dependecon de la retservo, forigas tiun vetkuron. Poste ripetu la lanĉan teston kaj kontrolu, ke dua provo ne plu necesas.

Ŝanĝoj de vojoj kaj adaptiloj bezonas administrajn rajtojn. Lanĉa ŝparvojo por unu uzanto ne havas ilin, do skripto, kiu funkcias el altigita ŝelo, povas ĉe ensaluto silente fari nenion. Planu ĝin kiel taskon kun la plej altaj privilegioj, aŭ lasu la servon transpreni la ŝanĝon. Poste testu ĝin kiel la uzanto, kiu efektive ensalutos.

Testu la sekvencon, kiun vi efektive lanĉas, ne tiun, kiun vi povas ekigi permane. Malvarma lanĉo estas la sola testo, kiu ekzercas la ordon.

Kvina paŝo: kontrolu sen la GUI

Post restartigo kaj ensaluto, kontrolu tri aferojn sen malfermi la GUI. La adaptilo devas teni adreson,la vojotabelo devas montri la antaŭsignon de la retejo kun la tunela enirejo kiel sekva salto, kaj ping al adreso ĉe la malproksima flanko devas respondi. Ĉiu kontrolo mapas al malsama mekanismo el la paŝoj supre.

Kiam la adaptilo neniam aperas, la pelilo estas la suspektato, ne la profilo. Tiuj du fiaskoj aspektas tute malsame en la protokolo, kaj nur unu el ili respondas al reinstalado de programaro.