Access Server förlorade sin bindning efter att ett nätverksgränssnitt bytt namn: rätta nycklarna

Du har bytt namn på ett nätverksgränssnitt, eller återställt en maskin vars adapter kom tillbaka under ett annat namn, och nu startar inte OpenVPN Access Server-daemonen. Webbgränssnittet svarar kanske fortfarande, eller inte, beroende på vilken komponent som var bunden till det gamla namnet. Tjänsten är inte skadad och konfigurationen är inte borta; en inställning pekar fortfarande på ett gränssnitt som värden inte längre har.

Reflexen är att installera om, initiera om eller redigera databasen tills felet försvinner. Var och en är en större ändring än felet, och den sista kan radera de användare, behörigheter och profilberoenden som gjorde servern värd att rädda. Detta är ett bindningsproblem, och det har en namngiven lösning.

Vad symptomet egentligen säger

En daemon som inte kan binda säger det vanligtvis i sin egen logg: adressen är inte tillgänglig eller gränssnittet finns inte. Meddelandet är konkret: det namnger adressen daemonen försökte; jämför den med ip -br addr på värden för att se om gränssnittet bytte namn, togs bort eller restes utan sin gamla adress.

Håll en auktoriserad återställningskonsol öppen hela tiden. Om bindningen du ska ändra bär din enda administrativa session har du skurit av dig reträtten. En lokal konsol, en andra hanteringsadress eller en dokumenterad out-of-band-väg gör ändringen reversibel.

Fråga efter konfigurationen innan du redigerar den

Access Server exponerar serverkonfigurationen via sitt eget CLI. Den dokumenterade vyn är:

sacli ConfigQuery

Kör den i den administrativa miljö som är dokumenterad för din version, inte från ett främmande skal på en annan värd. Spara de aktuella värdena på en skyddad plats innan du ändrar något, och klistra inte in hela utdata i en offentlig supporttråd.

Utdata är en vy av serverkonfigurationen, inte en fullständig säkerhetskopia. Användar- och gruppegenskaper frågas separat, så en ren bindning återställer inte identiteter, och en återställd identitet reparerar inte en lyssnare. Registrera båda som två separata artefakter.

Avgör vilken lyssnare som är trasig

Access Server kör mer än en lyssnare. OpenVPN-daemonerna bär tunneltrafik, webbtjänsten bär admin- och kundportalen, och andra komponenter kan ha egna portar. En misslyckad webbläsarförfrågan säger inte vilken av dem som misslyckades, och portnumret i ett felmeddelande gör det inte heller.

Daemonens bindningsnycklar är dokumenterade per daemon, och i den officiella handledningen är värdet gränssnittets identifierare även om nyckelnamnen slutar på ip_address. Läs den meningen två gånger. Handledningen förväntar sig också att UDP- och TCP-daemonerna delar ett gränssnitt, så att rätta bara en nyckel är en partiell reparation.

Ändra den namngivna inställningen, inte matchande rader

Handledningen dokumenterar ConfigPut mot specifika nycklar, som vpn.daemon.0.server.ip_address och vpn.daemon.0.listen.ip_address. Använd produktens egen metod med nyckelnamnet och det nya värdet, i den syntax din version dokumenterar, och ändra bara nycklarna för den lyssnare du diagnostiserade.

Det du inte bör göra är att söka igenom databasen efter varje rad vars värde är det gamla gränssnittsnamnet och ersätta dem alla. Det förutsätter att det gamla namnet bara förekom i lyssnarinställningar, vilket schemat inte lovar. Det gör också ändringen omöjlig att granska.

Två ytterligare frestelser bör avvisas. Att återställa en standard som lyssnar på alla gränssnitt är ett beslut om exponering, inte en stavfelrättning; den avsedda lokala bindningen, den publicerade vägen och filtreringen framför måste stämma med det valet. Att initiera om konfigurationen byter namn på problemet i stället för att lösa det, eftersom en ny installation kastar bort just de användare och behörigheter som fungerade före namnbytet.

Tillämpa det och bevisa att vägen fungerar

När värdet är rättat tillämpar du det via produktens dokumenterade livscykel ( livscykel ). Handledningen använder sacli start efter att nycklarna satts; det är inte en fullständig omstart av värden och inte en återställning av databasen.

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

Kontrollera lyssnaren, upprätta sedan en auktoriserad VPN-anslutning, nå en privat resurs och läs in admin-sidan via dess förväntade väg. Behåll befintliga användarbehörigheter och återkallelser; en återställning som nollställer dem har rättat bindningen och förlorat driftsättningen. Arbetet är klart när samma tjänst fungerar på sitt avsedda gränssnitt.