Ŝanĝi VPN-provizantojn: planu la gastigantnomon, ne nur la IP

Via DNS-rikordo estas ĝusta, la anstataŭaĵo estas sana, kaj tamen kelkaj klientoj pasigas horojn vokante la malnovan adreson. Kelkaj malsukcesas tuj kontraŭ nomo, kiu solviĝas kaj neniam respondas. Ambaŭ rezultoj venas el unu manko: gastigantnomo ŝanĝas, kion kliento serĉas, ne kiam ĝi serĉas ĝin, kaj ne kion ĝi fidas, kiam la respondo alvenas.

La simptomo: ĝusta rikordo, kadukaj tuneloj

Profilo, kiu konservas nomon, ne estas kliento, kiu daŭre solvas ĝin. La plej multaj solvas unufoje, ĉe apliko de la agordo aŭ kiam la tunelo ekfunkcias, kaj poste reuzas tiun adreson ĝis la seanco finiĝas. Longa TTL sur tio estas kial la transiro devas esti planita ĉirkaŭ rekonektoj anstataŭ ĉirkaŭ la DNS-redakto.

Neniu el la du kondutoj estas difekto, kaj ĝuste tio igas la simptomon konfuza. La kliento laboras per respondo, kiun ĝi ricevis pli frue, kaj nenio ĉe la servila flanko montras, kiu respondo ĝi estis. Planu la rekonekton en la bontenadan fenestron kaj diru al uzantoj, kion ili vidos, aŭ pasigu la fenestron respondante biletojn. Vico da identaj raportoj estas la kutima rezulto.

Kiu regas la nomon, kaj kion la kliento kontrolas

Regado de la zono decidas, kiom rapide migrado povas moviĝi. Tenu la rikordon ĉe registristo, en kiun vi povas ensaluti, kaj notu, kiu alia povas ŝanĝi ĝin.

Fido ne sekvas la nomon. Kliento bazita sur TLS povas kontroli identecon de atestilo aŭ fiksitan nomon, dum WireGuard aŭtentikigas la publikan ŝlosilon de la partnero kaj tute ignoras la gastigantnomon. Tiu diferenco decidas, ĉu DNS-redakto sufiĉas aŭ ĉu ĉiu profilo bezonas novan fingrospuron. Rikorda ŝanĝo neniam rajtigu finpunkton, kiun neniu aprobis.

Tenu administran kaj restaŭran aliron for de la publika klienta nomo. Perdi gastigadan konton ne devus ankaŭ kosti al vi la rikordon, kiu alidirektas klientojn. Konservu la restaŭran vojon ie, kio ne dependas de la provizanto, kiun vi forlasas.

Kiam ĉiu kliento relegas la nomon

Solva tempo estas propraĵo de unuopa kliento, do kontrolu la efektivigon, kiun vi efektive liveras, antaŭ ol promesi transiran fenestron. wg-quick solvas la finpunkton, kiam la interfaco ekfunkcias, kaj konservas tiun adreson ĝis la tunelo restartas. Kliento OpenVPN serĉas la nomon, kiam ĝi konektiĝas, kaj ĉu ĝi rigardos denove ĉe rekonekto dependas de ĝiaj opcioj.

Poŝtelefonaj klientoj estas la kutima surprizo, ĉar ili povas teni solvitan adreson tra dormo aŭ retŝanĝo. Publikigu rikordojn A kaj AAAA nur se la anstataŭaĵo respondas en ambaŭ familioj. Adreso, kiu respondas en unu familio, pruvas nenion pri la alia, kaj morta AAAA-rikordo aldonas tempolimon al ĉiu provo. Dokumentu la solvan konduton por ĉiu kliento, kiun vi subtenas, poste testu sur la aparatoj, kiujn homoj efektive uzas.

Rekonekto estas uzanta ago ĉe la plej multaj klientoj, kaj la servilo ne povas devigi ĝin. Metu tiun paŝon en la bontenadan noton, kun linio pri tio, kion la uzanto vidos, kiam ĝi okazos.

Transiru surbaze de pruvoj, poste retiriĝu la malnovan finpunkton

Antaŭ la ŝalto, pruvu ĉiun tavolon ĉe la anstataŭaĵo: la aŭskultanto respondas, la fajroŝirmilo trapasas la pordon, la itineraj vojoj revenas ĝuste, la nomo solviĝas al la nova adreso, kaj konata identeco estas akceptata. Aŭskultanto, kiu akceptas konekton, ne samas kiel tiu, kiu kompletigas manpremon, do testu la manpremon kaj ne la pordon. Tenu la aktualan revokan liston apud la agordo, ĉar restaŭrita savkopio rekreas la partneran liston tia, kia ĝi estis, kaj remalfermus aliron, kiun vi jam fermis. Notu, per kiu identeco vi testis, ĉar «ĝi funkcias» ne estas pruvo, kiun iu povas ripeti.

getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakes

Dum la transiro, observu konektajn provojn ĉe ambaŭ finpunktoj por la sama identeco. Kliento, kiu ankoraŭ aŭtentikigas sin kontraŭ la malnova adreso, estas profilo aŭ kaŝmemorita respondo, kiu neniam moviĝis. Retiriĝu la malnovan finpunkton laŭ datita plano, ĉar du servoj akceptantaj unu identecon lasas du pordojn malfermitaj.

La transira testo estas aplika seanco tra la nova finpunkto, ne ping. Post kiam tiu seanco funkcias kaj la malnova finpunkto registras neniujn rajtigitajn provojn dum plena rekonekta ciklo, la movo estas finita.