Hoe u de server van een OpenVPN-profiel controleert voordat u het importeert

Iemand stuurt u een profiel, u importeert het, en dertig seconden later belt een client een bestemming die niemand heeft gecontroleerd. Lees het bestand eerst in een teksteditor, want alles wat ertoe doet zit in een handvol richtlijnen: remote, proto, port, ca, cert, tls-crypt en verify-x509-name. Al het andere zijn standaardwaarden, en in de standaardwaarden zitten de verrassingen.

Elk eindpunt opsommen dat het bestand kan gebruiken

Begin bij de eindpunten, want één profiel kan er meerdere bevatten. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn drukt elke kandidaat af in bestandsvolgorde, inclusief degenen die genest zijn in inline <connection>-blokken.

Wanneer een richtlijn een poort weglaat, valt de client terug op de standaard van de listener, dus remote vpn.example.com alleen betekent poort 1194 met welke proto er ook later in het bestand verschijnt. Meerdere gewone remote-regels zijn alternatieven: de client probeert ze op volgorde, tenzij remote-random ze door elkaar gooit, en hij vervangt nooit stilzwijgend de host van een andere aanbieder. Twee remote-regels op onverwante domeinen is het punt waarop u stopt en vraagt welke bedoeld was.

Let ook op de spelling van proto. tcp wordt geaccepteerd als synoniem voor de clientzijde tcp-client, maar tcp-server in een clientprofiel is een configuratiefout die eerder blijft hangen dan netjes mislukt.

Bevestig de naam, dan de poort

dig +short vpn.example.com vertelt u of de naam bestaat en welke adressen hij teruggeeft, en een multi-homed of via proxy bereikbaar eindpunt mag er legitiem meerdere teruggeven. Resolutie is een voorwaarde, geen bewijs van eigendom; iedereen kan een naam naar een adres laten wijzen, en één adres kan voor veel namen antwoorden.

Controleer dan de listener op de poort die u hebt gevonden, in overeenstemming met het transport. Over TCP drukt openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com de keten af die de server presenteert. Over UDP hebt u DTLS nodig: openssl s_client -dtls1_2 -connect vpn.example.com:1194 voert dezelfde handshake uit over datagrammen. Een voltooide handshake bewijst dat er iets luistert en een certificaat heeft, wat meer is dan een ping laat zien en minder dan de eigen trust-instellingen van het profiel vragen.

Wanneer de handshake mislukt en de host pingt, is de poort waarschijnlijk verkeerd of gefilterd. Beschouw dat als een reden om de juiste poort te vragen, niet als een uitnodiging om de nabije poorten af te vegen. nc -vzu meldt op sommige stacks ook succes terwijl er niets luistert, dus een kale UDP-probe betekent niets zonder handshake erachter.

Lees de trust-pins apart van het adres

Het adres bepaalt waar de client naartoe gaat; het trust-blok bepaalt wie hij gelooft zodra hij aankomt. verify-x509-name "vpn.example.com" name pint de common name van het subject vast, en remote-cert-tls server vereist het uitgebreide sleutelgebruik voor serverauthenticatie. Een profiel dat u van een aanbieder krijgt, hoort beide te dragen.

Zoek naar ca, een inline <ca>-blok en ofwel tls-crypt ofwel tls-auth. Een profiel dat tls-auth gebruikt, heeft key-direction 1 aan de clientzijde nodig wanneer de serverzijde richting 0 gebruikt, en een mismatch laat de handshake mislukken met een TLS-fout die klinkt als een certificaatfout. Een inline CA die niet toebehoort aan de aanbieder wiens naam u net hebt opgelost, betekent dat het bestand uit twee bronnen is samengesteld, en dat is het geval dat u gerust ronduit mag weigeren.

verify-x509-name kent de modi name, name-prefix of subject, en de laatste verwacht een volledige distinguished name in precies de volgorde waarin de server hem afdrukt. Kies een modus die bij de vorm van de waarde past, want de client weigert elke verbinding in plaats van te waarschuwen voor een bijna-treffer. Voor een bestand dat u niet zelf hebt geschreven, is name met een gewone hostnaam de minst verrassende keuze.

Controleer de opties die stil falen

OpenVPN 2.6 onderhandelt cijfers via data-ciphers, en een profiel met alleen een oude cipher AES-256-CBC-regel kan het controlekanaal voltooien en daarna bij de data blijven steken. Die waarde lezen vertelt u of het bestand ouder is dan de server waarop u inlogt; de 2.6-manpage vermeldt de onderhandelingsorde als u die aan de aanbieder moet terugciteren.

auth-user-pass zonder bestandsnaam betekent dat de client zal vragen, dus een profiel dat zelfstandig lijkt heeft toch inloggegevens nodig. auth-user-pass credentials.txt betekent dat het een bestand verwacht dat u waarschijnlijk niet hebt gekregen. nobind en resolv-retry infinite zijn gewoon en onschadelijk, terwijl explicit-exit-notify alleen voor UDP is en zinloos over TCP.

Geen van deze verandert waar het profiel verbindt, maar elk verandert of het überhaupt verbindt, en geen ervan is zichtbaar in de importdialoog van een client.

Beslissen en dan vastleggen wat u hebt besloten

Na dit lezen bestaan er drie uitkomsten, en slechts één is import. Wanneer het eindpunt en de pins overeenkomen met instructies die u via een apart kanaal hebt gekregen, importeert u het. Wanneer het eindpunt er goed uitziet maar de pins of de CA niet kloppen, vraagt u om een gecorrigeerd bestand. Wanneer het bestand eindpunten of CA-materiaal uit verschillende bronnen mengt, verwijdert u het en vraagt u om een verse kopie.

Leg de hash vast die u hebt bekeken, zodat de volgende persoon kan zien of het bestand is veranderd: sha256sum profile.ovpn, naast het eindpunt in uw notities geplakt. Een profiel is een hele regeling, geen lijst met adressen, dus las nooit een werkende remote in iemands trust-blok terwijl u diens inloggegevens houdt.

Houd privésleutels en wachtwoorden buiten screenshots en chatthreads terwijl u notities vergelijkt. Het eindpunt en de niet-geheime opties zijn genoeg om een precieze vraag te stellen, en de rest hoort in het bestand.

Als u het wel importeert en de eerste poging mislukt, start de client dan met --verb 3 en lees de eerste tien regels: het opgeloste remote-adres, het onderhandelde proto en de TLS-fout verschijnen in die volgorde, wat u vertelt welke van de bovenstaande controles u hebt overgeslagen.