Elavult DDNS-rekord vagy törött VPN-végpont: hogyan különböztessük meg

Kívülről egy elavult hosztnév és egy törött VPN egyformán néz ki. A kliens felold egy nevet, a név valahová mutat, és a kapcsolat vagy lejár, vagy elutasítják. Az egyik DNS-frissítési probléma, a másik hitelesítési vagy továbbítási probléma, és a különbség csak akkor válik nyilvánvalóvá, amikor összehasonlítja a közzétett címet azzal a címmel, amely a vonalán valójában van.

Két hiba, amely ugyanúgy jelenik meg

Az első hiba, hogy a rekord még mindig a tegnapi WAN-címet listázza. A második, hogy a rekord helyes, és az alagút a saját okai miatt utasítja el. Mindkettő ugyanazt az üzenetet adja a kliensen, és a kísértés az, hogy elkezdjük újragenerálni a tanúsítványokat.

Itt a sorrend számít. A DNS ellenőrzése egy percig tart, és visszafordítható. A CA újragenerálása egyik sem.

Hasonlítsa össze a címeket mindenek előtt

Kérdezze meg a hálózat tulajdonosát, milyen címe van most a vonalnak, majd kérdezze meg a DNS-t, mit tesz közzé. A dig +short vpn.example.com adja azt a választ, amelyet a kliense kapni fog, a dig @1.1.1.1 vpn.example.com pedig megmutatja, hogy egy másik feloldó lát-e mást. Ha ez a kettő nem egyezik, gyorsítótár-viselkedést lát, nem pedig törött frissítőt.

A rekurzív válasz a TTL-jével lemaradhat egy frissítés mögött, ezért tartsa külön dobozban az authoritative rekordot és azt, amit a laptopja gyorsítótárazott.

Mi is valójában a frissítő hitelesítő adata

A régebbi DDNS-eszközök gyakran magával a fiók jelszavával hitelesítenek, ezért a jelszó megváltoztatása csendben elrontja őket. Továbbra is a régi értékkel próbálkoznak, és semmi hasznosat nem jelentenek. A No-IP eszközjelszó-útmutatója pontosan ezt a kompatibilitási problémát dokumentálja régebbi hardveren, és az ésszerű válasz egy szűk hatókörű frissítési hitelesítő adat, nem pedig egy gyengébb fiókjelszó.

Az újabb mechanizmusok külön frissítési tokent vagy kulcsot adnak ki saját életciklussal. Ezt az értéket kell a routerbe forgatni, és ezt kell a hitelesítőadat-nyilvántartásában rögzíteni. Ez azonban nem az az érték, amelyet hibakeresés közben egy csevegőszálba kell illeszteni.

Vizsgálja meg a frissítő nem titkos állapotát: az utolsó siker idejét, a válaszkategóriát és azt a hosztnevet, amelyet sajátjának hisz. A hitelesítő adat elutasítása és a kapcsolódási hiba különböző javításokat igényel.

Mit nem tud megtenni egy DNS-javítás

A rekord kijavítása nem hoz létre bejövő elérhetőséget. Ha a vonal operátori szintű NAT mögött van, semmilyen hosztnév nem teszi működőképessé a bejövő kapcsolatot. Az sem nyit tűzfal-szabályt, és nem továbbít portot. És soha nem ok arra, hogy kikapcsolja a kiszolgáló ellenőrzését a kliensen, ami az a lépés, amelyet az emberek tesznek, amikor úgy döntenek, hogy a tanúsítványban kell lennie a hibának.

Fordítva, a VPN-jelszó megváltoztatása nem javítás az elavult DNS-re. Csak egy második hibát ad ugyanahhoz a jegyhez.

Csatlakozzon újra, és bizonyítsa végponttól végpontig

Amint az authoritative rekord rendben van, a kliens még tarthat egy régi lekérdezést. Használja a támogatott újracsatlakozást vagy végpont-frissítést, és adjon neki egy pillanatot ahelyett, hogy folyton a csatlakozásra kattintana. Ezután négy lépésben bizonyítsa az útvonalat: oldja fel a nevet, erősítse meg a címet, ellenőrizze, hogy a figyelő elérhető-e, és hitelesítsen. Négy külön eredmény, négy külön válasz.

Tartsa a frissítőt a rotációs ellenőrzőlistán a VPN-fiók mellett. Egy szándékolt rekordtulajdonos, egy érvényes hitelesítő adat és egy megfigyelhető siker az, ami megakadályozza a jegy következő változatát.