Plej multaj homoj supozas, ke .ovpn-dosiero agordas VPN. Ĝi ne faras tion: ĝi agordas unu klienton, kaj ĉio, kion ĝi petas, jam devas ekzisti ĉe la alia flanko. Ŝanĝi linion en la dosiero povas ŝanĝi tion, kion via maŝino provas, neniam tion, kion la servilo proponas. Tiu distingo klarigas plejparton de la konfuzo pri profiloj, kiuj malsukcesas importi aŭ konekti.

Legu la dosieron kiel liston da petoj adresitaj al via kliento, kaj plej multaj el ĝiaj linioj fariĝos evidentaj.

La dosiero priskribas vian klienton, ne la servilon

Profilo kunigas la remote-finpunkton, transporton, interfacan tipon, identecan materialon kaj ajnan klientflankan konduton, kiun la operatoro volas. Ĉiun linion plenumas la kliento ĉe starto. Neniu el ili atingas la servilon kiel agordan ŝanĝon, kaj neniu el ili povas krei aŭskultanton, kiu jam ne funkcias. Profilo, kiu nomas TCP 443 kontraŭ servilo aŭskultanta nur per UDP 1194 malsukcesas ĉe la unua pako.

Tial ankaŭ la sama dosiero kondutas malsame ĉe du klientoj: la dosiero petas, kaj la kliento decidas, kiom el la peto ĝi povas plenumi.

Transportaj linioj devas kongrui kun aŭskultanto, kiu jam ekzistas

proto kaj remote linioj devas kongrui kun tio, kion la servilo efektive ligas. UDP estas la kutima elekto, ĉar perdita datagramo ne haltigas la tunelon, dum TCP povas postvivi restriktivajn retojn je la kosto de blokado de la kapo de la vico ene de la tunelo. Ŝanĝi profilon de UDP al TCP ne igas la servilon akcepti TCP; ĝi nur igas la klienton sendi al pordo, kiun neniu legas.

Pordo 443 estas populara, ĉar ĝi trapasas retojn, kiuj permesas preskaŭ nenion alian, kaj ĝi restas OpenVPN seanco anstataŭ HTTPS-peto. Se la operatoro publikigas plurajn remote liniojn, la kliento provas ilin laŭ ordo, kio estas listo por malsukcesa transiro, ne decido pri ŝarĝegaligo. Konservu la kombinaĵojn, kiujn la operatoro liveris, anstataŭ miksi gastigan servilon el unu enskribo kun pordo el alia.

Enkonstruitaj ŝlosiloj ŝanĝas, kiel vi traktas la dosieron

Atestiloj kaj ŝlosiloj povas esti enkonstruitaj inter la etikedoj <ca>, <cert> kaj <key>, aŭ referencataj kiel apartaj dosieroj. Enkonstruita materialo faras la profilon memstara kaj ankaŭ faras ĝin sekreto, ĉar la privata ŝlosilo de la kliento vojaĝas interne. CA-atestilo estas publika fida materialo kaj sekure dividebla; privata ŝlosilo ne estas, eĉ kiam ĝi aspektas kiel nelegebla teksta bloko.

La pasfazo protektanta ŝlosilon estas aparta sekreto disde la konta pasvorto, kaj ilia intermiksado produktas aŭtentigadan fiaskon, kiu aspektas kiel malĝustaj legitimajoj.

Itinereroj kaj DNS eble tute ne venas el la dosiero

Enkursigadon povas puŝi la servilo, starigi la profilo per redirect-gateway, aŭ ĝi povas resti laŭ la propraj normoj de la kliento. La elŝutita dosiero do ne plene difinas, kien la trafiko iras post kiam la tunelo staras. Kiam internaj nomoj solviĝas kaj publikaj retejoj ne, la politiko de dividita tunelo faras tion, por kio ĝi estis desegnita, ne malsukcesas.

DNS sekvas la saman ŝablonon: puŝita dhcp-option DNS povas esti aplikata de la kliento, ignorata aŭ anstataŭigata de loka solvila administrilo. Kontrolu la staton de la solvilo post konekto anstataŭ relegi la profilon.

Nesubtenataj opcioj estas demando pri klienta versio

Importaj avertoj kutime signifas, ke la kliento ne realigas direktivon, ne ke la dosiero estas difektita. Labortablaj klientoj povas ruli skriptojn kaj kromaĵojn sub dokumentitaj kontroloj, dum poŝtelefonaj klientoj akceptas pli mallarĝan aron kaj povas silente forlasi liniojn, kiujn ili ne komprenas. Ĉifra aŭ TLS-agordo, kiun malnova kliento rifuzas, estas versia problemo solvenda kun la operatoro. Ŝalti nekonatajn privilegiojn por devigi importon interŝanĝas averton kontraŭ pli vasta ataka surfaco.

Konservu la originalan dosieron por komparo, notu la ĝustan nesubtenatan direktivon en via peto, kaj petu profilon konstruita por la kliento, kiun vi efektive rulas.

Post ajna anstataŭigo, konfirmu, kiun profilan enskribon la apo uzas, ĉar importi novan dosieron ne ĉiam anstataŭigas la malnovan.

Rilataj artikoloj