Die VPN het geskuif: waarom jou OpenVPN-kliënt nog die ou IP skakel

Die verskaffer het jou openbare adres verander, jy het die dinamiese DNS-rekord bygewerk, en die kliënt kan steeds nie verbind nie. Van buite lyk dit of die rekord nie versprei het nie. Meestal is die rekord reg en skakel die kliënt die adres wat dit voor die skuif opgelos het, want 'n lopende tonnel en 'n gestoorde profiel het elkeen sy eie idee van waar die bediener woon. Drie lae moet saamstem, en hulle werk op verskillende skedules by.

Kyk na wat die profiel skakel, nie wat DNS sê nie

Maak die verbinding oop wat jy werklik gebruik en lees die remote-lyn. 'n Numeriese adres daar volg nooit 'n gasheernaam-opdatering nie, maak nie saak hoe korrek die rekord word nie.

Kyk dan of die profiel wat jy geredigeer het die een is wat die kliënt gelaai het. Ingevoerde profiele is algemeen: 'n bestuurder het dalk maande gelede 'n kopie geneem en sy eie weergawe gehou, so die lêer in jou aflaaigids en die inskrywing in die app kan verskil. Vergelyk die eindpunt in die kliënt se eie verbindingsbesonderhede voordat jy DNS hoegenaamd ontfout.

Twee lêers, een eindpunt, is die gewone bevinding hier.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Lees die kliënt se volgende verbindingspoging

Herbegin die verbinding met breedsprakige logboeke en lees die reël waar dit die adres noem wat dit gaan kontak. Daardie waarde is die een wat saak maak, nie wat jou blaaier opgelos het nie.

'n Oplosser-kas kan steeds die vorige antwoord hou, en sommige netwerke hou dit langer as wat die rekord se TTL vra. Vra die oplosser wat die kliënt werklik gebruik, eerder as 'n openbare een wat jy van elders getoets het.

As die log die nuwe adres wys en die verbinding steeds misluk, het die probleem geskuif: die pakkie gaan êrens heen en niemand antwoord nie. Dit is 'n luisteraar-, firewall- of poortaanstuur-vraag, en dit lê aan die bedienerkant eerder as in die kliënt se oplossingspad. Hou daardie twee mislukkings apart, want om 'n onbereikbare luisteraar as 'n DNS-probleem te behandel, stuur jou twee keer deur dieselfde lus.

Weet watter herbegin jy doen

Nie alle herbegin behou dieselfde toestand nie, daarom kan 'n adresverandering anders optree na gelang van hoe die proses herwin word. 'n Sagte herbegin wat deur 'n sein veroorsaak word, hou meer van die vorige sessie se konteks, terwyl 'n volledige stop en begin weer by die konfigurasie begin. As jy toets of die kliënt weer oplos, wil jy die pad hê wat by die konfigurasie begin.

Volhardingsinstellings maak ook saak, want hulle is ontwerp om te hou wat gemagtig is eerder as om nuwe adresse na te jaag.

Die skoonste toets is 'n vars begin vanaf die beoogde profiel, gevolg deur 'n blik op die logreël wat die eindpunt noem. Enigiets wat jy uit 'n gedeeltelik bewaarde sessie leer, is 'n stelling oor daardie sessie.

Die vier opsies en hulle afsonderlike take

remote met 'n gasheernaam is die instelling wat her-oplossing hoegenaamd moontlik maak; 'n letterlike adres op daardie lyn sluit dit uit. resolv-retry beheer wat gebeur wanneer 'n opsoek misluk, en 2.6 maak dit reeds by verstek oneindig. Om dit by te voeg verander dus niks, en dit beplan nooit 'n periodieke kontrole vir 'n ander antwoord nie. Enigiemand wat sê dit peil vir nuwe adresse, het herstel met varsheid verwar.

persist-remote-ip gaan oor kontinuïteit eerder as varsheid: dit hergebruik die eindpunt wat laas gemagtig het, oor die sagte herbeginne wat dit ondersteun. Terwyl jy 'n skuif toets, is dit die teenoorgestelde van wat jy wil hê. Deaktiveer dit vir die toets as jou bou dit aktiveer, en herstel dit sodra die nuwe eindpunt bewys is. As dit aan bly, kan 'n suksesvolle herverbinding jou niks oor DNS sê nie.

float aanvaar 'n gemagtigde eweknie wie se adres midde-sessie verander het, en net in reëlings wat dit ondersteun. Dit verfris nie DNS nie, en dit sal nie uit eie beweging 'n verskaffer-verandering volg nie. Behandel dit as 'n veerkragtigheidsfunksie vir eweknieë wat rondswerf, nie as 'n dinamiese adresmeganisme vir bedieners nie.

Bevestig die nuwe eindpunt voordat jy die kliënt blameer

Van buite jou netwerk, kyk of die nuwe adres 'n luisteraar op die gekonfigureerde poort het en of die verskaffer se aanstuur daarheen wys. 'n Korrekte A-rekord vir 'n masjien met geen oop poort nie, lewer presies die simptoom wat mense aan kaswerk toeskryf.

Herverbind dan en verifieer twee dinge: die kliënt het teen die verwagte bediener-sertifikaat gemagtig, en die sessie bereik die hulpbron wat jy bedoel het. 'n Adresverandering verlaag nie die identiteitsvereistes nie, en 'n verbinding wat na die verkeerde eindpunt slaag, is erger as een wat misluk. Die OpenVPN 2.6-handleiding lys al vier opsies met hulle eie omvang, wat die kontrolelys is om langs die profiel te hou.

Hou 'n buite-band weg na die bediener voordat jy die tonnel herbegin wat jou administrasietoegang dra. Daardie enkele voorsorgmaatreël voorkom die meeste voorvalle wat hierdie scenario oplewer.