Access Server het sy binding verloor ná die hernoeming van ’n netwerkkoppelvlak: herstel die sleutels

Jy het ’n netwerkkoppelvlak hernoem, of ’n masjien herstel waarvan die adapter onder ’n ander naam teruggekom het, en nou kom die OpenVPN Access Server-daemon nie op nie. Die webkoppelvlak antwoord dalk nog, of nie, afhangend van watter komponent aan die ou naam gebind was. Die diens is nie beskadig nie en die konfigurasie is nie weg nie; een instelling wys steeds na ’n koppelvlak wat die gasheer nie meer het nie.

Die refleks is om te herinstalleer, te herinitialiseer of die databasis te wysig tot die fout verdwyn. Elkeen is ’n groter verandering as die fout, en die laaste een kan die gebruikers, regte en profielafhanklikhede uitwis wat die bediener die moeite werd gemaak het om te red. Dit is ’n bindingsprobleem met ’n genoemde oplossing.

Wat die simptoom eintlik sê

’n Daemon wat nie kan bind nie, sê dit gewoonlik in sy eie log: die adres is nie beskikbaar nie, of die koppelvlak bestaan nie. Daardie boodskap noem die adres wat die daemon probeer het; vergelyk dit met ip -br addr op die gasheer om te sien of die koppelvlak hernoem, verwyder of sonder sy ou adres opgestel is.

Hou die hele tyd ’n gemagtigde herstelkonsole oop. As die binding wat jy gaan verander jou enigste administrasiesessie dra, het jy jou weg terug afgesny. ’n Plaaslike konsole, ’n tweede bestuursadres of ’n gedokumenteerde buitebandroete maak die verandering omkeerbaar.

Vra eers die konfigurasie op

Access Server stel sy bedienerkonfigurasie deur sy eie CLI beskikbaar. Die gedokumenteerde aansig is:

sacli ConfigQuery

Voer dit uit in die administratiewe omgewing wat vir jou weergawe gedokumenteer is, nie vanuit ’n onverwante skulp op ’n ander gasheer nie. Stoor die huidige waardes op ’n beskermde plek voordat jy iets verander, en moenie die volledige uitset in ’n openbare draad plak nie.

Daardie uitset is ’n aansig van die bedienerkonfigurasie, nie ’n volledige rugsteun nie. Gebruikers- en groepeienskappe word apart opgevra, so ’n skoon binding herstel nie identiteite nie, en ’n herstelde identiteit maak nie ’n luisteraar reg nie. Neem die twee as aparte artefakte op.

Bepaal watter luisteraar stukkend is

Access Server het meer as een luisteraar. Die OpenVPN-daemons dra tonnelverkeer, die webdiens dra die admin- en kliëntportaal, en ander komponente kan hul eie poorte hê. ’n Mislukte blaaiernavraag sê nie watter een misluk het nie, en die poortnommer in ’n fout ook nie.

Die daemon-bindingsleutels word per daemon gedokumenteer, en in die amptelike tutoriaal is die waarde die koppelvlakidentifiseerder, al eindig die sleutelname op ip_address. Lees daardie sin twee keer voordat jy ’n adres daarin tik. Die tutoriaal verwag ook dat die UDP- en TCP-daemons een koppelvlak deel, so om net een sleutel reg te maak is ’n halwe herstelling.

Verander die genoemde instelling, nie rye nie

Die tutoriaal dokumenteer ConfigPut teen spesifieke sleutels, soos vpn.daemon.0.server.ip_address en vpn.daemon.0.listen.ip_address. Gebruik die produk se eie metode met die sleutelnaam en die nuwe waarde, in die sintaksis van jou weergawe, en verander net die sleutels van die luisteraar wat jy gediagnoseer het.

Moenie die databasis deursoek vir elke ry met die ou koppelvlaknaam en hulle almal vervang nie. Dit aanvaar dat die ou naam net in luisteraarinstellings voorkom, wat die skema nie belowe nie. Dit maak die verandering ook onnaspeurbaar: ’n noue instelling het ’n voor en ’n na, ’n groot vervanging het ’n diff wat niemand kan lees nie.

Twee versoekings moet jy weier. ’n Verstek wat op elke koppelvlak luister, is ’n blootstellingsbesluit, nie ’n regstelling nie; die plaaslike binding, die gepubliseerde roete en die filtering daarvoor moet saamstem. Herinitialisering hernoem die probleem eerder as om dit op te los, want ’n nuwe installasie gooi die gebruikers en regte weg wat voor die hernoeming gewerk het.

Pas dit toe en bewys die roete

Nadat die waarde reggestel is, pas dit toe deur die produk se gedokumenteerde lewensiklus ( lewensiklus ). Die tutoriaal gebruik sacli start nadat die sleutels gestel is; dit is nie ’n volledige herstart of ’n databasis-reset nie.

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

Kontroleer die luisteraar, maak een gemagtigde VPN-verbinding, bereik een private hulpbron en laai die administratiewe bladsy op sy verwagte roete. Hou die bestaande regte en intrekkings; ’n herstel wat hulle terugstel, het die binding reggemaak en die ontplooiing verloor. Die werk is klaar wanneer dieselfde diens op sy bedoelde koppelvlak werk.