Hoe't jo de tsjinner fan in OpenVPN-profil kontrolearje foar't jo it ymportearje

Immen stjoert jo in profyl, jo ymportearje it, en tritich sekonden letter skillet in klient in bestimming oan dy't nimmen kontrolearre hat. Lês it bestân earst yn in tekstbewurker, want alles wat fan belang is sit in hânfol rjochtlinen: remote, proto, port, ca, cert, tls-crypt en verify-x509-name. Al it oare binne standertwearden, en it is yn 'e standertwearden dat de ferrassingen sitte.

Lis elk einpunt op dat it bestân brûke kin

Begjin by de einpunten, want ien profyl kin der ferskate hawwe. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn prints elk kandidaat yn bestânsfolchoarder, ynklusyf dy't yn ynbêde <connection>-blokken ferskûle sitte.

As in rjochtline in poarte weilitten, falt de klient werom op 'e standert fan 'e listener, dus remote vpn.example.com allinnich betsjut poarte 1194 mei hokker proto dan ek letter yn it bestân ferskynt. Ferskate gewoane remote-regels binne alternativen: de klient besiket se yn folchoarder, útsein as remote-random se trochinoar smyt, en hy ferfangt nea stilwei de host fan in oare oanbieder. Twa remote-regels op net besibbe domeinen is it punt wêr't jo stopje en freegje hokker bedoeld wie.

Let ek op 'e stavering fan proto. tcp wurdt akseptearre as synoniem foar de kliïntkant tcp-client, mar tcp-server yn in kliïntprofyl is in konfiguraasjeflater dy't earder hinget as dat er skjin mislearret.

Befêstigje de namme, dan de poarte

dig +short vpn.example.com fertelt jo oft de namme bestiet en hokker adressen er weromjout, en in multi-homed of proxy-einpunt mei legitimerwei ferskate weromjaan. Resolúsje is in betingst, gjin bewiis fan eigendom; elkenien kin in namme nei in adres wize litte, en ien adres kin foar in soad nammen antwurdzje.

Kontrolearje dan de listener op 'e poarte dy't jo fûn hawwe, yn oerienstimming mei it transport. Oer TCP prints openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com de keatling dy't de tsjinner presintearret. Oer UDP hawwe jo DTLS nedich: openssl s_client -dtls1_2 -connect vpn.example.com:1194 rint deselde hânjouwing oer datagrammen. In foltôge hânjouwing bewiist dat der wat harket en in sertifikaat hat, wat mear is as in ping sjen lit en minder as wat de eigen trust-ynstellingen fan it profyl easkje.

As de hânjouwing mislearret en de host pingt, is de poarte wierskynlik ferkeard of filtere. Beskôgje dat as in reden om de juste poarte te freegjen, net as in útnûging om de tichtby lizzende poarten te feien. nc -vzu meldt op guon steapels ek sukses wylst der neat harket, dus in keale UDP-probe betsjut neat sûnder in hânjouwing derachter.

Lês de trust-pinnen apart fan it adres

It adres beslút wêr't de klient hinne giet; it trust-blok beslút wa't er leaut as er ienris oankommen is. verify-x509-name "vpn.example.com" name pint de common name fan it ûnderwerp fêst, en remote-cert-tls server freget it útwreide kaai-gebrûk foar tsjinnerferifikaasje. In profyl dat in oanbieder jo jout heart beide te dragen.

Sykje nei ca, in ynbêde <ca>-blok en itsij tls-crypt itsij tls-auth. In profyl dat tls-auth brûkt hat key-direction 1 oan 'e kliïntkant nedich as de tsjinnerkant rjochting 0 brûkt, en in misferhâld lit de hânjouwing mislearje mei in TLS-flater dy't as in sertifikaatflater klinkt. In ynbêde CA dy't net ta de oanbieder heart waans namme jo krekt oplost hawwe, betsjut dat it bestân út twa boarnen gearstald is, en dat is it gefal dat it wurdich is om daliks te wegerjen.

verify-x509-name nimt name, name-prefix of subject-modi, en de lêste ferwachtet in folsleine ûnderskiedende namme yn krekt de folchoarder dy't de tsjinner prints. Kies in modus dy't by de foarm fan 'e wearde past, want de klient wegeret elke ferbining ynstee fan te warnen oer in hast-treffer. Foar in bestân dat jo net sels skreaun hawwe, is name mei in gewoane hostnamme de minst ferrassende kar.

Kontrolearje de opsjes dy't stil mislearje

OpenVPN 2.6 ûnderhannelt sjifers fia data-ciphers, en in profyl dat allinnich in âlde cipher AES-256-CBC-rige draacht kin it kontrôlekanaal foltôgje en dan op 'e gegevens fêstrinne. It lêzen fan dy wearde fertelt jo oft it bestân âlder is as de tsjinner dêr't jo by oanslute; de 2.6-man-side lit de ûnderhannelingsfolchoarder sjen as jo dy oan 'e oanbieder sitearje moatte.

auth-user-pass sûnder bestânsnamme betsjut dat de klient freegje sil, dus in profyl dat selsstannich liket hat dochs oanmeldgegevens nedich. auth-user-pass credentials.txt betsjut dat it in bestân ferwachtet dat jo wierskynlik net krigen hawwe. nobind en resolv-retry infinite binne gewoan en ûnskealik, wylst explicit-exit-notify allinnich foar UDP is en sinleas oer TCP.

Gjin fan dizze feroaret wêr't it profyl ferbynt, mar elk feroaret oft it oeral ferbynt, en gjinien is sichtber yn 'e ymportdialooch fan in klient.

Beslút, en skriuw dan op wat jo besletten hawwe

Der binne trije útkomsten nei dit lêzen, en mar ien is ymport. As it einpunt en de pinnen oerienkomme mei ynstruksjes dy't jo fia in apart kanaal krigen hawwe, ymportearje it dan. As it einpunt der goed útsjocht mar de pinnen of it CA net oerienkomme, freegje dan om in korrizjearre bestân. As it bestân einpunten of CA-materiaal út ferskate boarnen mingt, smyt it dan fuort en freegje in nij kopy.

Skriuw de hash op dy't jo besjoen hawwe, sadat de folgjende persoan sjen kin oft it bestân feroare is: sha256sum profile.ovpn, njonken it einpunt yn jo notysjes plakt. In profyl is in hiele regeling, gjin list fan adressen, dus las nea in wurkjende remote yn 'e trust-blok fan in oar wylst jo harren oanmeldgegevens hâlde.

Hâld privee kaaien en wachtwurden bûten skermôfbyldings en petearrieden wylst jo notysjes fergelykje. It einpunt en de net-geheime opsjes binne genôch om in krekte fraach te stellen, en de rest heart yn it bestân.

As jo it wol ymportearje en de earste poging mislearret, rin dan de klient mei --verb 3 en lês de earste tsien rigels: it oploste remote-adres, it ûnderhannele proto en de TLS-flater ferskine yn dy folchoarder, wat jo fertelt hokker fan 'e kontrôles hjirboppe jo oerslein hawwe.