Ons gebruik OpenVPN: protokol, enjin of app? Wat om eerder te vra
Dieselfde woord benoem ’n protokol, ’n bedienerpakket en ’n selfoonapp. Skei eers die rol en vra dan vir die kliënt, die profiel en die hulpbron.
Die sin ‘ons gebruik OpenVPN’ kom in kaartjies, aankoopvorms en inlywingsdokumente voor, en dit beantwoord in elkeen ’n ander vraag. Soms noem dit ’n draadprotokol, soms die sagteware op ’n poort, en soms die app wat ’n nuwe werknemer moet installeer. Daardie drie feite lei tot verskillende volgende stappe, en om te vra watter een bedoel word neem minder tyd as om te raai. Die res van die ondersoek volg uit daardie antwoord.
Begin deur die rol van die handelsmerk te skei, want die handelsmerk dek al drie.
Die naam dek drie rolle wat op verskillende maniere misluk
As protokol beskryf OpenVPN hoe versoenbare eweknieë ’n tonnel vestig en beskerm wat daardeur gaan. As sagteware is dit ’n implementering wat daardie protokol in ’n kliënt- of bedienerrol praat. As kliënt is dit ’n toepassing wat iemand installeer, met sy eie weergawe, profielformaat en platformeienaardighede. ’n Fout in een rol beteken nie ’n fout in ’n ander nie, en daarom het ‘OpenVPN is af’ ’n onderwerp nodig.
Vra wat die aanmelder kan sien: ’n profiellêer, ’n geïnstalleerde program of ’n poort wat hy of sy bestuur. Daardie enkele besonderheid sê vir jou of die volgende stap ’n kliëntlog, ’n pakketvraag of ’n luistertoets aan die bedienerkant is.
OpenVPN 2 en OpenVPN 3 is nie ’n opgraderingspaar nie
OpenVPN 2.x werk in beide bediener- en kliëntrolle, en dit is wat die meeste poortontplooiings steeds gebruik. OpenVPN 3 is ’n aparte kliëntgerigte implementering met sy eie konfigurasie en sessiemodel, nie die volgende weergawe wat jy oor ’n 2.x-bediener installeer nie. OpenVPN Connect is ’n kliënttoepassing wat op die OpenVPN 3-enjin gebou is. Om enige van hulle te installeer skep nie ’n internetuitgangdiens nie; die uitgang is wat die operateur opgestel het.
Versoenbaarheid op protokolvlak strek nie tot profieldirektiewe nie, so ’n profiel wat skoon invoer kan steeds faal op ’n direktief wat die kliënt nie implementeer nie.
Die vervoer is nie die toepassing daarbinne nie
Die buitenste verbinding gebruik ’n vervoer soos UDP of TCP om ’n opgestelde luisteraar te bereik, en alles wat die tonnel dra ry daarbinne. ’n Webversoek wat deur die VPN gemaak word, het nie sy eie OpenVPN-luisteraar nodig nie, en dit word nie op die draad ’n OpenVPN-pakket nie. In TLS-modus onderhandel die beheerkanaal sleutelmateriaal terwyl die datakanale die nutslading beskerm, en dit is ’n skeiding wat jy reg moet hou wanneer jy logs lees.
Om die lae te verwar lewer versoeke op soos om ’n poort oop te maak vir ’n webwerf wat reeds deur die tonnel werk. Die poort behoort aan die buitenste verbinding, nie aan die toepassing nie.
Wat ’n profiel wel en nie kan belowe nie
’n Profiel vertel een kliënt hoe om een diens te bereik: eindpunt, vervoer, identiteitsmateriaal en dikwels ’n paar roeterings- en DNS-voorkeure. Dit sê niks oor wie daardie diens bedryf of of die rekening gemagtig is nie. Roetes, oplosserinstellings, deurvoerreëls en toegangsbeleid bepaal wat die sessie werklik bereik. ’n Profiel wat suksesvol invoer is die begin van ’n werkende verbinding, nie bewys daarvan nie.
Wanneer iemand vra of ’n hulpbron oor die VPN bereikbaar is, hang die antwoord van die bediener se beleid af eerder as van die kliënt se konfigurasielêer.
Vra vir die ding wat voorsien kan word
Verander die breë naam in drie besonderhede: die kliënt en sy weergawe, die gemagtigde profiel vir daardie kliënt, en die hulpbron wat die persoon moet bereik. Met dié is voorsiening ’n konkrete taak. Sonder dié is elke antwoord ’n raaiskoot oor watter OpenVPN die vraag bedoel het.
Teken die antwoord in die versoek self aan. Die volgende kaartjie sal dieselfde vraag op dieselfde dubbelsinnige manier vra.