Folosim OpenVPN: protocol, motor sau aplicație? Ce ar trebui întrebat în schimb

Fraza «folosim OpenVPN» ajunge în tichete, în formulare de achiziție și în documentele pentru angajații noi, iar în fiecare dintre ele răspunde la o altă întrebare. Uneori numește un protocol de transport, uneori software-ul de pe un gateway, iar uneori aplicația pe care trebuie să o instaleze un angajat nou. Aceste trei fapte duc la pași următori diferiți, iar întrebarea la care dintre ele se referă ia mai puțin timp decât ghicitul. Restul investigației decurge din acel răspuns.

Începeți prin a separa rolul de marcă, pentru că marca le acoperă pe toate trei.

Numele acoperă trei roluri care eșuează în moduri diferite

Ca protocol, OpenVPN descrie cum partenerii compatibili stabilesc un tunel și protejează ce trece prin el. Ca software, este o implementare care vorbește acel protocol într-un rol de client sau de server. Ca client, este o aplicație pe care cineva o instalează, cu propria versiune, propriul format de profil și propriile particularități de platformă. O defecțiune într-un rol nu implică o defecțiune în altul, de aceea «OpenVPN este picat» are nevoie de un subiect.

Întrebați ce poate vedea cel care raportează: un fișier de profil, un program instalat sau un gateway pe care îl administrează. Acest singur detaliu vă spune dacă pasul următor este un jurnal de client, o întrebare despre pachet sau o verificare a ascultătorului pe partea de server.

OpenVPN 2 și OpenVPN 3 nu sunt o pereche de actualizare

OpenVPN 2.x rulează atât în rol de server, cât și de client, și este ceea ce folosesc încă majoritatea implementărilor de gateway. OpenVPN 3 este o implementare separată orientată spre client, cu propria configurație și propriul model de sesiune, nu următoarea versiune pe care o instalați peste un server 2.x. OpenVPN Connect este o aplicație de client construită pe motorul OpenVPN 3. Instalarea oricăreia dintre ele nu creează un serviciu de ieșire în internet; ieșirea este ceea ce a configurat operatorul.

Compatibilitatea la nivel de protocol nu se extinde la directivele profilului, așa că un profil care se importă curat poate eșua în continuare pe o directivă pe care clientul nu o implementează.

Transportul nu este aplicația din interiorul lui

Conexiunea exterioară folosește un transport precum UDP sau TCP pentru a ajunge la un ascultător configurat, iar tot ce transportă tunelul circulă în interiorul ei. O cerere web făcută prin VPN nu are nevoie de propriul ascultător OpenVPN și nu devine un pachet OpenVPN pe fir. În modul TLS canalul de control negociază materialul de chei, în timp ce canalul de date protejează sarcina utilă, iar aceasta este o separare pe care merită să o păstrați corectă când citiți jurnale.

Confundarea straturilor produce cereri precum deschiderea unui port pentru un site care funcționează deja prin tunel. Portul aparține conexiunii exterioare, nu aplicației.

Ce poate promite un profil și ce nu

Un profil îi spune unui client cum să ajungă la un serviciu: punct final, transport, material de identitate și adesea câteva preferințe de rutare și DNS. Nu spune nimic despre cine operează acel serviciu sau dacă contul este autorizat. Rutele, setările resolverului, regulile de redirecționare și politica de acces decid la ce ajunge de fapt sesiunea. Un profil care se importă cu succes este începutul unei conexiuni funcționale, nu dovada ei.

Când cineva întreabă dacă o resursă este accesibilă prin VPN, răspunsul depinde de politica serverului, nu de fișierul de configurare al clientului.

Cereți ceea ce poate fi furnizat

Transformați numele larg în trei lucruri concrete: clientul și versiunea lui, profilul autorizat pentru acel client și resursa la care persoana trebuie să ajungă. Cu acestea, furnizarea este o sarcină concretă. Fără ele, fiecare răspuns este o presupunere despre care OpenVPN a fost vizat de întrebare.

Notați răspunsul în cererea însăși. Următorul tichet va pune aceeași întrebare în același mod ambiguu.