Access Server perdis sian ligon post renomigo de reta interfaco: riparu la ŝlosilojn

Vi renomigis retan interfacon aŭ restarigis maŝinon, kies adaptilo revenis sub alia nomo, kaj nun la demono de OpenVPN Access Server ne ekfunkcias. La reta interfaco eble ankoraŭ respondas, aŭ ne, laŭ tio, kiu komponanto estis ligita al la malnova nomo. La servo ne estas difektita kaj la agordo ne perdiĝis; unu agordo ankoraŭ montras al interfaco, kiun la gastiganto ne plu havas.

La reflekso estas reinstali, reinitialize aŭ redakti la datumbazon ĝis la eraro malaperos. Ĉiu el tiuj estas pli granda ŝanĝo ol la difekto, kaj la lasta povas forviŝi la uzantojn, permesojn kaj profilajn dependecojn, kiuj igis la servilon inda je savo. Ĝi estas liga problemo, kaj ĝi havas nomitan solvon.

Kion la simptomo vere diras

Demono, kiu ne povas ligiĝi, kutime diras tion en sia propra protokolo: la adreso ne disponeblas aŭ la interfaco ne ekzistas. La mesaĝo estas specifa: ĝi nomas la adreson, kiun la demono provis; komparu ĝin kun ip -br addr ĉe la gastiganto por vidi, ĉu la interfaco estis renomigita, forigita aŭ levita sen sia malnova adreso.

Tenu malfermitan rajtigitan restaŭran konzolon la tutan tempon. Se la ligo, kiun vi ŝanĝos, portas vian solan administran sesion, vi fortranĉis vian revenan vojon. Loka konzolo, dua administra adreso aŭ dokumentita eksterbenda vojo igas la ŝanĝon reigebla.

Pridemandu la agordon antaŭ ol redakti ĝin

Access Server montras sian agordon per sia propra CLI. La dokumentita vido estas:

sacli ConfigQuery

Rulu ĝin en la administra medio dokumentita por via versio, ne el senrilata ŝelo ĉe alia gastiganto. Konservu la nunajn valorojn en protektita loko antaŭ ol ŝanĝi ion, kaj ne algluu la plenan eligon en publikan subtenan fadenon.

Tiu eligo estas vido de la servila agordo, ne kompleta savkopio. Uzantaj kaj grupaj ecoj estas pridemandataj aparte, do pura ligo ne restaŭras identecojn, kaj restaŭrita identeco ne riparas aŭskultanton. Registru ambaŭ kiel du apartajn artefaktojn.

Determinu, kiu aŭskultanto estas rompita

Access Server funkciigas pli ol unu aŭskultanton. La demonoj OpenVPN portas tunelan trafikon, la reta servo portas la administran kaj klientan portalon, kaj aliaj komponantoj povas havi proprajn havenojn. Malsukcesa peto de retumilo ne diras, kiu el ili malsukcesis, nek la havena numero en erarmesaĝo.

La ligaj ŝlosiloj de la demono estas dokumentitaj por ĉiu demono, kaj en la oficiala lernilo la valoro estas la identigilo de la interfaco, kvankam la ŝlosilnomoj finiĝas per ip_address. Legu tiun frazon dufoje. La lernilo ankaŭ atendas, ke la demonoj UDP kaj TCP kunhavu unu interfacon, do ripari nur unu ŝlosilon estas parta riparo.

Ŝanĝu la nomitan agordon, ne la kongruajn vicojn

La lernilo dokumentas ConfigPut ĉe specifaj ŝlosiloj, kiel vpn.daemon.0.server.ip_address kaj vpn.daemon.0.listen.ip_address. Uzu la propran metodon de la produkto kun la ŝlosilnomo kaj la nova valoro, en la sintakso dokumentita por via versio, kaj ŝanĝu nur la ŝlosilojn de la aŭskultanto, kiun vi diagnozis.

Kion vi ne faru, estas serĉi en la datumbazo ĉiun vicon, kies valoro egalas la malnovan interfacan nomon, kaj anstataŭigi ilin ĉiujn. Tio supozas, ke la malnova nomo aperis nur en aŭskultantaj agordoj, kion la skemo ne promesas. Ĝi ankaŭ igas la ŝanĝon neprirevidebla.

Du pliaj tentoj indas esti rifuzitaj. Restarigi defaŭlton, kiu aŭskultas ĉe ĉiuj interfacoj, estas decido pri elmeto, ne ortografia korekto; la celata loka ligo, la publikigita vojo kaj la filtrado antaŭ ĝi devas kongrui kun tiu elekto. Reinicialigo de la agordo renomigas la problemon anstataŭ solvi ĝin, ĉar freŝa instalaĵo forĵetas ĝuste la uzantojn kaj permesojn, kiuj funkciis antaŭ la renomigo.

Apliku ĝin, poste pruvu, ke la vojo funkcias

Post kiam la valoro estas korektita, apliku ĝin per la dokumentita vivociklo de la produkto ( vivociklo ). La lernilo uzas sacli start post starigo de la ŝlosiloj; tio ne estas plena restarto de la gastiganto nek datumbaza restarigo.

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

Kontrolu la aŭskultanton, poste faru unu rajtigitan VPN-konekton, atingn unu privatan rimedon, kaj ŝargu la administran paĝon laŭ sia atendata vojo. Konservu la ekzistantajn uzantpermesojn kaj revokojn; restaŭro, kiu restarigas ilin, riparis la ligon kaj perdis la deplojon. La laboro finiĝis, kiam la sama servo funkcias ĉe sia celata interfaco.