Hoe om die bediener van ’n OpenVPN-profiel te kontroleer voordat jy dit invoer

Iemand stuur vir jou ’n profiel, jy voer dit in, en dertig sekondes later skakel ’n kliënt na ’n bestemming wat niemand nagegaan het nie. Lees eers die lêer in ’n teksredigeerder, want alles wat saak maak sit in ’n handvol riglyne: remote, proto, port, ca, cert, tls-crypt en verify-x509-name. Alles anders is verstekwaardes, en dit is in die verstekwaardes waar die verrassings sit.

Lys elke eindpunt wat die lêer kan gebruik

Begin by die eindpunte, want een profiel kan verskeie hê. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn druk elke kandidaat in lêervolgorde, insluitend dié wat in ingeboude <connection>-blokke voorkom.

Wanneer ’n riglyn ’n poort weglaat, val die kliënt terug op die verstek van die luisteraar, so remote vpn.example.com alleen beteken poort 1194 met watter proto ook al later in die lêer voorkom. Verskeie gewone remote-reëls is alternatiewe: die kliënt probeer hulle in volgorde, tensy remote-random hulle skommel, en hy vervang nooit stilweg ’n ander operateur se gasheer nie. Twee remote-reëls op onverwante domeine is die punt waar jy stop en vra watter een bedoel is.

Let ook op die spelling van proto. tcp word aanvaar as sinoniem vir die kliëntkant se tcp-client, maar tcp-server in ’n kliëntprofiel is ’n konfigurasiefout wat geneig is om te hang eerder as om netjies te misluk.

Bevestig die naam, dan die poort

dig +short vpn.example.com vertel jou of die naam bestaan en watter adresse dit terugstuur, en ’n multi-homed of proxy-eindpunt kan wettiglik verskeie terugstuur. Resolusie is ’n voorvereiste, nie bewys van eienaarskap nie; enigiemand kan ’n naam na ’n adres laat wys, en een adres kan vir baie name antwoord.

Kontroleer dan die luisteraar op die poort wat jy gevind het, in ooreenstemming met die transport. Oor TCP druk openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com die ketting wat die bediener aanbied. Oor UDP het jy DTLS nodig: openssl s_client -dtls1_2 -connect vpn.example.com:1194 hardloop dieselfde handdruk oor datagramme. ’n Voltooide handdruk bewys dat iets luister en ’n sertifikaat hou, wat meer is as wat ’n ping wys en minder as wat die profiel se eie trust-instellings vereis.

Wanneer die handdruk misluk en die gasheer ping, is die poort waarskynlik verkeerd of gefiltreer. Beskou dit as ’n rede om die korrekte poort te vra, nie as ’n uitnodiging om die nabygeleë poorte te vee nie. nc -vzu rapporteer ook sukses op sommige stelle terwyl niks luister nie, so ’n kaal UDP-probe beteken niks sonder ’n handdruk daarby.

Lees die trust-penne apart van die adres

Die adres bepaal waar die kliënt heen gaan; die trust-blok bepaal wie hy glo sodra hy daar aankom. verify-x509-name "vpn.example.com" name pen die subjek se algemene naam vas, en remote-cert-tls server vereis die uitgebreide sleutelgebruik vir bedienerverifikasie. ’n Profiel wat ’n operateur vir jou gee, behoort albei te dra.

Soek ca, ’n ingeboude <ca>-blok, en óf tls-crypt óf tls-auth. ’n Profiel wat tls-auth gebruik, het key-direction 1 aan die kliëntkant nodig wanneer die bedienerkant rigting 0 gebruik, en ’n wanverhouding laat die handdruk misluk met ’n TLS-fout wat soos ’n sertifikaatfout lyk. ’n Ingebedde CA wat nie aan die operateur behoort wie se naam jy pas opgelos het nie, beteken die lêer is uit twee bronne saamgestel, en dit is die geval wat die moeite werd is om summier te weier.

verify-x509-name neem name, name-prefix of subject-modusse, en die laaste een verwag ’n volledige onderskeidende naam in die presiese volgorde waarin die bediener dit druk. Kies ’n modus wat by die vorm van die waarde pas, want die kliënt verwerp elke verbinding eerder as om oor ’n byna-treffer te waarsku. Vir ’n lêer wat jy nie geskryf het nie, is name met ’n gewone gasheernaam die minste verrassende keuse.

Kontroleer die opsies wat stilweg misluk

OpenVPN 2.6 onderhandel syfers deur data-ciphers, en ’n profiel met net ’n ou cipher AES-256-CBC-reël kan die beheerkanaal voltooi en dan op data vasval. Om daardie waarde te lees, vertel jou of die lêer die bediener wat jy betree voorafdateer; die 2.6-manbladsy lys die onderhandelingsorde as jy dit aan die operateur moet terugkwoteer.

auth-user-pass sonder ’n lêernaam beteken die kliënt sal vra, so ’n profiel wat selfstandig lyk, het steeds geloofsbriewe nodig. auth-user-pass credentials.txt beteken dit verwag ’n lêer wat jy waarskynlik nie gestuur is nie. nobind en resolv-retry infinite is gewoon en onskadelik, terwyl explicit-exit-notify net vir UDP is en nutteloos oor TCP.

Nie een van hierdie verander waar die profiel verbind nie, maar elkeen verander of dit hoegenaamd verbind, en nie een is in ’n kliënt se invoerdialoog sigbaar nie.

Besluit, en teken dan aan wat jy besluit het

Drie uitkomste bestaan ná hierdie lees, en net een is invoer. Wanneer die eindpunt en die penne ooreenstem met instruksies wat jy deur ’n aparte kanaal gekry het, voer dit in. Wanneer die eindpunt reg lyk maar die penne of die CA nie ooreenstem nie, vra vir ’n reggestelde lêer. Wanneer die lêer eindpunte of CA-materiaal uit verskillende bronne meng, verwyder dit en vra ’n vars kopie.

Teken die hash aan wat jy nagegaan het, sodat die volgende persoon kan sien of die lêer verander het: sha256sum profile.ovpn, langs die eindpunt in jou notas geplak. ’n Profiel is ’n hele reëling, nie ’n lys adresse nie, so moenie ’n werkende remote in iemand anders se trust-blok inlas terwyl jy hulle geloofsbriewe hou nie.

Hou private sleutels en wagwoorde uit skermkiekies en kletsdraadjies terwyl jy notas vergelyk. Die eindpunt en die nie-geheime opsies is genoeg om ’n presiese vraag te vra, en die res hoort in die lêer.

As jy dit wel invoer en die eerste poging misluk, hardloop die kliënt met --verb 3 en lees die eerste tien reëls: die opgeloste remote-adres, die onderhandelde proto en die TLS-fout verskyn in daardie orde, wat jou wys watter van die kontroles hierbo jy oorgeslaan het.