VPN-a lekuz aldatu da: zergatik zure OpenVPN bezeroak IP zaharrari deitzen dio oraindik

Hornitzaileak zure helbide publikoa aldatu du, DNS erregistro dinamikoa eguneratu duzu, eta bezeroak ezin du oraindik konektatu. Kanpotik erregistroa ez zela hedatu dirudi. Gehienetan erregistroa ondo dago eta bezeroak lekualdaketaren aurretik ebatzitako helbideari deitzen dio, martxan dagoen tunelak eta gordetako profileak bakoitzak bere ideia duelako zerbitzaria non bizi den. Hiru geruzek bat etorri behar dute, eta egutegi desberdinetan eguneratzen dira.

Begiratu profileak zer deitzen duen, ez zer dioen DNS-ak

Ireki benetan erabiltzen duzun konexioa eta irakurri remote lerroa. Han dagoen helbide numerikoak ez dio inoiz ostalari-izenaren eguneraketari jarraitzen, erregistroa zenbat eta zuzenagoa izan.

Ondoren egiaztatu editatu duzun profila bezeroak kargatu duena ote den. Inportatutako profilak ohikoak dira: kudeatzaile batek hilabeteak lehenago kopia bat har dezake eta bere bertsioa gorde, beraz zure deskarga karpetako fitxategia eta aplikazioko sarrera desberdinak izan daitezke. Konparatu amaierako puntua bezeroaren beraren konexio-xehetasunetan, DNS arazten hasi aurretik.

Bi fitxategi, amaierako puntu bat: hau da hemen ohiko aurkikuntza.

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

Irakurri bezeroaren hurrengo konexio-saioa

Berrabiarazi konexioa erregistro xehearekin eta irakurri zein helbidearekin harremanetan jarriko den adierazten duen lerroa. Balio hori da garrantzitsua, ez zure nabigatzaileak ebatzitakoa.

Resolverraren cacheak aurreko erantzuna gorde dezake oraindik, eta sare batzuek erregistroaren TTL-ak eskatzen duena baino gehiago gordetzen dute. Galdetu bezeroak benetan erabiltzen duen resolverrari, beste nonbaitetik probatu duzun publiko bati beharrean.

Erregistroak helbide berria erakusten badu eta konexioak huts egiten badu oraindik, arazoa mugitu da: paketea norabait doa eta inork ez du erantzuten. Entzule, suebaki edo ataka-birbidalketa kontua da, eta zerbitzariaren aldean dago, ez bezeroaren ebazpen-bidean. Eutsi bi hutsegite horiek bereizita, entzule iristezin bat DNS arazo gisa tratatzeak birritan eramaten baitzaitu begizta berean.

Jakin ezazu zein berrabiarazte egiten ari zaren

Berrabiarazte guztiek ez dute egoera bera gordetzen, eta horregatik helbide-aldaketak desberdin joka dezake prozesua nola birziklatzen den arabera. Seinale batek eragindako berrabiarazte bigunak aurreko saioaren testuinguru gehiago gordetzen du, eta gelditze eta abiarazte osoak konfiguraziotik hasten dira berriro. Bezeroak berriz ebazten duen probatzen ari bazara, konfiguraziotik hasten den bidea nahi duzu.

Iraunkortasun-ezarpenek ere garrantzia dute, autentifikatutakoa gordetzeko diseinatuta daudelako, helbide berrien atzetik ibiltzeko beharrean.

Probarik garbiena xede den profiletik abiarazte berri bat da, eta ondoren amaierako puntua izendatzen duen erregistro-lerroari begiratzen zaio. Partzialki gordetako saio batetik ikasten duzun edozein gauza saio hari buruzko baieztapen bat da.

Lau aukerak eta haien zeregin bereiziak

Ostalari-izenarekin remote da berriz ebaztea posible egiten duen ezarpen bakarra; lerro horretan helbide literalak hura baztertzen du. resolv-retry bilaketa batek huts egiten duenean gertatzen dena kontrolatzen du, eta 2.6-k jada infinitua jartzen du lehenespenez. Beraz, gehituz ez du ezer aldatzen, eta ez du inoiz aldiuneko egiaztapenik programatzen erantzun desberdin batentzat. Berriz esaten duenak helbide berriak inkestatzen dituela, berreskuratzea eta freskotasuna nahastu ditu.

persist-remote-ip jarraitutasunari buruzkoa da, ez freskotasunari: azken aldiz autentifikatu zuen amaierako puntua berrerabiltzen du, onartzen dituen berrabiarazte bigunetan zehar. Lekualdaketa bat probatzen ari zaren bitartean, nahi duzunaren kontrakoa da hori. Desgaitu probarako, zure eraikinak gaitzen badu, eta berrezarri amaierako puntu berria frogatu ondoren. Gaitua utzita, berriz konektatze arrakastatsuak ez dizu ezer esango DNS-ari buruz.

float saioaren erdian helbidea aldatu zaion pare autentifikatu bat onartzen du, eta hori onartzen duten konfigurazioetan soilik. Ez du DNS freskatzen, eta ez dio hornitzaile-aldaketari bere kabuz jarraituko. Erresilientzia-ezaugarri gisa tratatu, noraezean dabiltzan pareentzat, ez zerbitzarientzako helbide dinamikoen mekanismo gisa.

Berretsi amaierako puntu berria bezeroari errua bota aurretik

Zure sarera kanpotik, egiaztatu helbide berriak entzule bat duela konfiguratutako atakan eta hornitzailearen birbidalketak hara eramaten duela. Ataka irekirik ez duen makina baterako A erregistro zuzen batek jendeak cacheari egozten dion sintoma bera sortzen du.

Gero berriz konektatu eta bi gauza egiaztatu: bezeroa espero zen zerbitzari-ziurtagiriarekin autentifikatu dela, eta saioak nahi zenuen baliabidea lortzen duela. Helbide-aldaketak ez ditu identitate-baldintzak jaisten, eta amaierako puntu oker bati arrakastaz konektatzea huts egiten duena baino okerragoa da. OpenVPN 2.6 eskuliburuak lau aukera guztiak zerrendatzen ditu beren esparruarekin, eta hori da profiletatik ondoan edukitzeko kontrol-zerrenda.

Mantendu zerbitzarirako bide kanpokoa zure administrazio-sarbidea daraman tunela berrabiarazi aurretik. Kontuzko neurri bakar horrek eragozten ditu egoera honek sortzen dituen istripu gehienak.