Застарен DDNS запис наспроти расипан VPN краен пункт: како да се разликува

Однадвор, застарено име на домаќин и расипан VPN изгледаат идентично. Клиентот решава име, името покажува некаде, и врската или истекува, или се одбива. Едното е проблем со ажурирање на DNS, а другото е проблем со автентикација или препраќање, и разликата станува очигледна само кога ќе ја споредите објавената адреса со адресата што вашата линија навистина ја има.

Два дефекти што изгледаат исто

Првиот дефект е што записот сѐ уште ја наведува вчерашната WAN адреса. Вториот е што записот е точен и тунелот ве одбива од свои причини. Двата ја даваат истата порака на клиентот, и искушението е да почнете повторно да генерирате сертификати.

Редоследот е важен овде. Проверката на DNS трае една минута и е повратна. Повторното генерирање на CA не е ниту едното ниту другото.

Споредете ги адресите пред сѐ друго

Прашајте го сопственикот на мрежата која адреса ја има линијата во моментов, потоа прашајте го DNS што објавува. dig +short vpn.example.com дава одговор што ќе го добие вашиот клиент, а dig @1.1.1.1 vpn.example.com покажува дали друг решавач гледа нешто друго. Ако овие две не се совпаѓаат, гледате однесување на кешот, а не расипан ажурирач.

Рекурзивниот одговор може да заостане зад ажурирањето за својот TTL, затоа држете го авторитативниот запис и она што вашиот лаптоп го кеширал во одделни кутии.

Што е всушност веродостојницата на ажурирачот

Постарите DDNS уреди често се автентицираат со самата лозинка на сметката, поради што менувањето на таа лозинка тивко ги расипува. Тие продолжуваат да обидуваат со старата вредност и не известуваат ништо корисно. Упатството на No-IP за лозинка на уред документира токму овој проблем со компатибилност на постар хардвер, а разумниот одговор е веродостојница за ажурирање со ограничен опсег, а не послаба лозинка на сметка.

Поновите механизми издаваат одделен токен или клуч за ажурирање со сопствен животен циклус. Тоа е вредноста што треба да се ротира во рутерот, и онаа што треба да се запише во вашиот инвентар на веродостојници. Таа исто така не е вредноста што треба да се залепи во чет-нишка додека отстранувате грешки.

Прегледајте го не-тајниот статус на ажурирачот: времето на последниот успех, категоријата на одговорот и името на домаќинот што смета дека го поседува. Одбивањето на веродостојница и дефектот во поврзувањето бараат различни поправки.

Што не може да направи поправка на DNS

Поправката на записот не создава влезна достапност. Ако линијата е зад NAT на операторско ниво, ниту едно име на домаќин нема да направи влезна врска да работи. Таа исто така не отвора правило на огнен ѕид и не препраќа порт. И никогаш не е причина да ја исклучите проверката на серверот на клиентот, што е потегот што луѓето го прават кога ќе одлучат дека сертификатот мора да е проблемот.

Обратно, промената на VPN лозинката не е поправка за застарен DNS. Таа само додава втор дефект на истиот тикет.

Поврзете се повторно и докажете го од почеток до крај

Откако авторитативниот запис ќе биде точен, клиентот може сѐ уште да држи старо пребарување. Користете го неговото поддржано повторно поврзување или освежување на крајниот пункт и дајте му момент наместо постојано да притискате поврзи. Потоа докажете ја патеката во четири чекори: решете го името, потврдете ја адресата, проверете дали слушателот е достапен и автентицирајте се. Четири одделни резултати, четири одделни одговори.

Држете го ажурирачот на контролната листа за ротација до VPN сметката. Еден предвиден сопственик на записот, валидна веродостојница и забележлив успех се она што ја спречува следната верзија на овој тикет.