Het elke OpenVPN-eweknie ’n remote-reël nodig? Nie heeltemal nie

Twee eweknie-konfigurasies word langs mekaar gestel, een het ’n remote-reël en die ander een nie, en die gevolgtrekking is dat een van hulle stukkend is. Daardie afleiding is dikwels genoeg verkeerd om te ontleed. Die richtlijn beskryf waarheen die eerste pakkie gestuur moet word. Dit kies nie of die proses as ’n inisiërende kliënt of as ’n wagende poort optree nie, en dit bepaal nie watter kant sy identiteit aan die ander bewys nie.

Wat remote eintlik spesifiseer

’n remote-inskrywing noem ’n gasheer, opsioneel ’n poort en ’n transport, en opsioneel verskeie sulke inskrywings om in volgorde te probeer.

Die afwesigheid daarvan het ’n bepaalde betekenis eerder as ’n onbepaalde een: die proses wag en reageer nie op pakkies van ’n adres nie, tensy daardie eweknie authentiseer. ’n Poort wat swerwende gebruikers bedien, het dus geen rede om enige van hulle vooraf te noem nie.

Lees die inskrywing as ’n adresverhouding. Of die ander kant vertrou word, word deur sertifikate en die verifikasie-opsies beantwoord, nie deur die feit dat ’n adres neergeskryf is nie.

Drie rangskikkings bepaal die antwoord

’n Swerwende kliënt het ’n bestemming nodig, want dit moet inisieer en het geen idee waar die poort is sonder een nie. ’n Poort vir baie kliënte het geen bestemming per gebruiker nodig nie, want kliënte kom en authentiseer. ’n Doelbewuste skakel tussen twee eweknieë met bekende eindpunte kan aan een kant, aan beide kante of aan geen kant ’n bestemming hê nie, afhangende van watter kant inisieer.

Om ’n vaste kliëntadres in ’n algemene poort te plak, is die fout wat volg uit die ignoreer van daardie kategorieë. Dit werk vir die een eweknie wie se adres aangeteken is, en mislei almal anders.

Niks aan die richtlijn maak ’n konfigurasie ’n bediener vir baie kliënte nie, en niks aan die teenwoordigheid daarvan verhoed ’n bedienerrol nie. Die OpenVPN 2.6-verwysing dokumenteer die opsionele argumente en die gedrag sonder remote afsonderlik, wat ’n wenk is oor hoe onafhanklik hulle is.

Transportrolle is ’n ander as

Vir TCP wag die een kant en die ander kant skakel. Dit is afsonderlike richtlyne van die bestemming, en om hulle te meng lewer ’n paar op wat albei wag of albei skakel.

Daar is ook ’n TCP-bronfilterrol, en daarom is die plat stelling dat ’n bediener nooit remote mag bevat nie, verkeerd.

Vir UDP is daar geen verbinding om te vestig nie, dus gebruik beide kante die ooreenstemmende UDP-transport en die richtlijn sê net waarheen om te mik. Adresveranderings deur ’n geauthentiseerde eweknie word deur toegewyde gedrag hanteer eerder as deur meer inskrywings by te voeg. Om die transport reg te kry, is ’n voorwaarde daarvoor dat die bestemming enigiets beteken, en om die twee te verwar lewer konfigurasies op wat geloofwaardig lyk en nooit ’n handskud voltooi nie.

Waarom ’n afwesige remote nie ’n oop deur is nie

’n Proses sonder ’n bestemming weier steeds verkeer van eweknieë wat nie authentiseer nie, en dit is die deel wat mense mis wanneer hulle die afwesige reël as ’n luisteraar vir enigiemand lees.

Authentisering en bestemming is onafhanklik, en die eerste is die een wat vir vertroue saak maak.

Die omgekeerde fout is gevaarliker. ’n Vaste bronadres kan soos toegangsbeheer voel omdat dit spesifiek en maklik is om te kontroleer, maar dit bewys niks oor wie aan die ander kant is nie. Hou sertifikaatverifikasie, en hou die identiteitskontroles wat ’n sertifikaat aan sy rol bind. Om hulle met ’n adresooreenkoms te vervang, ruil ’n werklike beheer vir die voorkoms daarvan.

Skryf neer wat die konfigurasie aanneem

Vir elke kant, teken drie dinge aan: hoe die eerste pakkie die eweknie bereik, watter kant die transport kan aanvaar, en wat elke kant oor die ander verifieer.

Daardie aannames is die ontwerp. Die richtlyne is net die spelling daarvan.

As die twee lêers verskil, kyk of hulle verskillende aannames uitdruk eerder as om te aanvaar dat een verkeerd is. ’n Simmetriese paar lêers is nie nodig of voldoende vir ’n werkende tonnel nie, en die asimmetrie is dikwels die deel wat ’n topologie laat werk.