Używamy OpenVPN: protokół, silnik czy aplikacja? O co pytać zamiast tego

Zdanie „używamy OpenVPN” pojawia się w zgłoszeniach, formularzach zakupowych i dokumentach wdrożeniowych, a w każdym z nich odpowiada na inne pytanie. Czasem nazywa protokół transmisyjny, czasem oprogramowanie na bramie, a czasem aplikację, którą ma zainstalować nowy pracownik. Te trzy fakty prowadzą do różnych kolejnych kroków, a pytanie, o który chodzi, zajmuje mniej czasu niż zgadywanie. Reszta dochodzenia wynika z tej odpowiedzi.

Zacznij od oddzielenia roli od marki, bo marka obejmuje wszystkie trzy.

Nazwa obejmuje trzy role, które zawodzą na różne sposoby

Jako protokół OpenVPN opisuje, jak zgodni partnerzy ustanawiają tunel i chronią to, co przez niego przechodzi. Jako oprogramowanie to implementacja, która mówi tym protokołem w roli klienta lub serwera. Jako klient to aplikacja, którą ktoś instaluje, z własną wersją, własnym formatem profilu i własnymi osobliwościami platformy. Awaria w jednej roli nie oznacza awarii w innej, dlatego zdanie „OpenVPN nie działa” potrzebuje podmiotu.

Zapytaj, co zgłaszający może zobaczyć: plik profilu, zainstalowany program albo bramę, którą administruje. Ten jeden szczegół mówi, czy kolejnym krokiem jest dziennik klienta, pytanie o pakiet, czy sprawdzenie nasłuchu po stronie serwera.

OpenVPN 2 i OpenVPN 3 nie są parą aktualizacyjną

OpenVPN 2.x działa zarówno w roli serwera, jak i klienta, i właśnie jego większość wdrożeń bram nadal używa. OpenVPN 3 to osobna implementacja zorientowana na klienta, z własną konfiguracją i modelem sesji, a nie następne wydanie instalowane na serwerze 2.x. OpenVPN Connect to aplikacja kliencka zbudowana na silniku OpenVPN 3. Zainstalowanie którejkolwiek z nich nie tworzy usługi wyjścia do internetu; wyjściem jest to, co skonfigurował operator.

Zgodność na poziomie protokołu nie obejmuje dyrektyw profilu, więc profil, który importuje się czysto, nadal może zawieść na dyrektywie, której klient nie implementuje.

Transport nie jest aplikacją w jego wnętrzu

Połączenie zewnętrzne używa transportu, takiego jak UDP lub TCP, aby dotrzeć do skonfigurowanego nasłuchu, a wszystko, co niesie tunel, jedzie w jego wnętrzu. Żądanie sieciowe wykonane przez VPN nie potrzebuje własnego nasłuchu OpenVPN i nie staje się pakietem OpenVPN na drucie. W trybie TLS kanał sterujący negocjuje materiał klucza, podczas gdy kanał danych chroni ładunek, i to jest rozdzielenie, które warto utrzymać poprawnie przy czytaniu dzienników.

Mieszanie warstw daje żądania typu otwarcie portu dla witryny, która już działa przez tunel. Port należy do połączenia zewnętrznego, nie do aplikacji.

Co profil może obiecać, a czego nie

Profil mówi jednemu klientowi, jak dotrzeć do jednej usługi: punkt końcowy, transport, materiał tożsamości i często kilka preferencji trasowania i DNS. Nie mówi nic o tym, kto obsługuje tę usługę ani czy konto jest upoważnione. Trasy, ustawienia resolvera, reguły przekazywania i polityka dostępu decydują, do czego sesja faktycznie dociera. Profil, który importuje się pomyślnie, jest początkiem działającego połączenia, a nie jego dowodem.

Gdy ktoś pyta, czy zasób jest osiągalny przez VPN, odpowiedź zależy od polityki serwera, a nie od pliku konfiguracyjnego klienta.

Proś o to, co można zapewnić

Zamień szeroką nazwę na trzy konkrety: klient i jego wersja, upoważniony profil dla tego klienta oraz zasób, do którego osoba ma dotrzeć. Z nimi zapewnienie jest konkretnym zadaniem. Bez nich każda odpowiedź jest domysłem, o który OpenVPN chodziło w pytaniu.

Zapisz odpowiedź w samym żądaniu. Następne zgłoszenie zada to samo pytanie w ten sam niejednoznaczny sposób.