Waarom die kopiëring van die OpenVPN-bedienerkonfigurasie na 'n tak misluk

Om die werkende bedienerkonfigurasie te kopieer, 'n paar adresse om te ruil en dit dan 'n takprofiel te noem, lewer gewoonlik 'n verbinding. Dit is die slegste uitkoms, want die tak werk dan met die verkeerde rol, stel materiaal bloot wat nie die hub mag verlaat nie, en laat 'n roete-assosiasie agter wat niemand onthou hulle gemaak het. Die verbinding verberg drie probleme tegelyk, en die tonnel kom op voordat iemand dit nagaan.

Om die tak te behandel as 'n eweknie met sy eie identiteit en netwerkrol is wat die profiel korrek maak. Die oplossing is nie 'n beter kopie nie, en die res van hierdie bladsy gaan oor wat 'n kliënt werklik behoort te hou.

Twee rolle wat soos een lêer lyk

In TLS-modus het die twee eweknieë aanvullende take. Die een kant luister, hou die bediener se sertifikaat en sleutel, en besluit watter kliënte mag koppel. Die ander kant begin die verbinding, verifieer die luisteraar en wys sy eie identiteit.

'n Bedienerlêer bevat opdragte wat op 'n kliënt geen sin maak nie: 'n bindadres en poort om op te luister, 'n poel adresse om uit te deel, en dikwels 'n stootlys vir instellings wat die kliënte moet ontvang. Om dit na 'n tak te kopieer, lewer 'n toestel wat terselfdertyd 'n luisteraar en 'n kliënt probeer wees.

Die privaatsleutel is die deel wat die meeste saak maak. 'n Kliënt mag nooit die bediener se privaatsleutel dra nie, en hy het ook nie die CA se ondertekeningsleutel nodig nie. 'n CA-sertifikaat is openbare vertrouensmateriaal; die ondertekeningsleutel hoort waar sertifikate uitgereik word.

Wat 'n takprofiel moet bevat

'n Takprofiel het die afgeleë eindpunt en vervoer nodig, die vertroude bedieneridentiteit, die tak se eie sertifikaat en sleutel, en die roetes en DNS-instellings wat die tak werklik vereis. Niks anders is verpligtend nie.

Hou die takidentiteit apart per terrein. Twee takke wat een sertifikaat deel, beteken dat die herroeping van een die ander uitskakel, en die hub se logboeke kan hulle nie onderskei nie. 'n Identiteit per terrein is wat beide die ouditspoor en die herroepingsverhaal laat werk.

Wees versigtig met toestelwerkswyses. pfSense se Client Export-pakket lewer profiele vir geskikte Remote Access-kontekste, en sy bedienerlys sluit net bedieners in wat in 'n Remote Access-modus opgestel is. 'n Werf-tot-werf-bediener van 'n ander modus verskyn nie, en daardie afwesigheid is inligting, nie 'n uitnodiging om die bediener se geheime te kopieer nie.

As die toestel nie die profiel uitvoer wat jy nodig het nie, gebruik sy gedokumenteerde werf-tot-werf-kliëntwerkswyse of bou die profiel uit die ondersteunde voorbeeld van die geïnstalleerde weergawe. Voer 'n bedienerrugsteun na die tak uit net as die plan is om 'n bediener te herstel, wat dit nie is nie. 'n Rugsteun dra ook die hub se private materiaal, so om een na 'n tak te skuif is 'n sleutelhanteringsbesluit, nie 'n lêeroordrag nie. Hou dit op die hub en genereer die kliëntidentiteit waar sertifikate uitgereik word.

Die eweknie-tot-netwerk-assosiasie is apart

'n Takkliënt wat suksesvol koppel, kan steeds nie verkeer vir sy LAN deurlaat voordat die hub weet dat hierdie eweknie daardie voorvoegsel besit nie. Daardie assosiasie woon op die hub, gekoppel aan die kliënt se identiteit, en dit is apart van die tak se eie roete na die afgeleë netwerke. Sonder dit lyk die tak se gashere bereikbaar in die tonnel se statistieke en onbereikbaar in die praktyk. Die hub-logboek is die plek om te bevestig of die assosiasie toegepas is.

Om 'n roete op die hub se bedryfstelsel by te voeg, is nie dieselfde as om vir OpenVPN te sê watter kliënt die voorvoegsel besit nie. Sonder die assosiasie per kliënt bereik die pakkie die tonnelkoppelvlak en word dit laat val omdat geen eweknie die bestemming opeis nie.

Aan die takkant is die ooreenstemmende behoefte 'n roete na die netwerke wat dit moet bereik, plus 'n LAN-roeteerder wat weet hoe om verkeer na die tak terug te stuur. Eienaarskap aan die bedienerkant en bestemmingsroetes aan die kliëntkant is aparte objekte, en 'n werkende tonnel bewys net die eerste sprong. Skryf albei neer in die tak se oorgangsnotas, want die volgende ingenieur sal net een van hulle vind.

Bewys dat die tak die eweknie is wat jy dink

Verifieer identiteit voordat jy verkeer verifieer. Die hub se logboek behoort die tak se sertifikaat se algemene naam te wys, en die adres wat die kliënt ontvang het, behoort te pas by die poel of vaste toewysing wat jy bedoel het. As die logboek 'n ander naam wys, dra die profiel iemand anders se identiteit.

Verifieer dan die assosiasie deur een versoek van 'n gasheer in die tak na 'n hulpbron aan die hubkant te stuur, en bevestig dat dit met die verwagte bronadres slaag. Toets 'n bestemming wat die tak nie mag bereik nie en bevestig dat dit misluk, want 'n toegeeflike roete wat toevallig werk is nie dieselfde as 'n korrekte beleid nie.

Herroep laastens die takidentiteit en bevestig dat die verbinding misluk terwyl die hub se eie sertifikaat en ander terreine aanhou werk. As herroeping die hub breek, is rolle en identiteite ergens gedeel, en dit is die bevinding wat werd is om na die ontwerp terug te neem.

'n Voltooide tak is een met 'n gedokumenteerde identiteit, 'n slegs-kliënt-profiel, 'n eweknie-tot-netwerk-assosiasie op die hub, en 'n getoetsde terugpad. Om teks in 'n bedienerlêer om te keer, gee jou nie een daarvan nie.