Гунценхаузен или почему я отказался от KeenDNS в роутерах Keenetic

С ходу заявляю, что служба динамических доменных имен KeenDNS в роутерах Keenetic работает не корректно и живите с этим теперь, как хотите. А жить с этим не получится. И как бы не пыталась техподдержка на форуме "кинетиков" убедить нас в обратном, что всё работает в штатном режиме как и задумано, я не поверю.

Собственно, динамический DNS бывает нужен только в одном случае, когда у вас нет выделенного IP адреса от провайдера и нужно попасть в сеть за роутером. Это чтобы каждый раз не пришлось менять настройки удаленного подключения, ведь собственного IP у вас нет, а провайдер может всякий раз выдавать вам новый адрес. Вроде понятно.

А хотите удивлю? Даже со статикой вам может потребоваться использовать динамический DNS. Спросите зачем? Всё предельно просто – когда у вас больше одного провайдера и вы делаете резервирование канала связи.

Внутри сети вам всё равно какой провайдер работает в данный момент времени, а вот при подключении снаружи, тут уже возникают трудности, ведь при переключении у вас меняется внешний IP адрес и тут уже становится не важно динамическим он был или статическим. Для внешних подключений, ваш адрес изменился и точка.

И тут уже всё зависит от того насколько корректно отрабатывает служба DDNS, а с этим у KeenDNS оказалась беда. Так, пока у меня работал основной канал связи, всё было хорошо и внешний IP правильно резолвился. В какой-то момент, основной провайдер лёг, роутер благополучно отработал переключение на резервный канал, но служба KeenDNS прописала у себя какой-то абсолютно рандомный IP-адрес и так я внезапно оказался в городе Гунценхаузен (Германия).

Что это? Откуда? Сервис просто приписал некий левый адрес... но зачем, в чём смысл? Если всё работает штатно, как пытаются нас убедить на форуме, то как можно объяснить этот самый "гунценхаузен"?

Тут наверное стоит прояснить, что резервный интернет-канал у меня постоянно поднят на другом роутере и мой основной роутер использует его как шлюз в критические моменты. То есть, для основного роутера интернет берётся из частной сети второго роутера (получается роутер за роутером). Естественно, тут ни о каком белом IP речи не идёт.

В то же время, если вместо службы KeenDNS, настроить к примеру другой динамический DNS сервер (сейчас юзаю No-IP), то там всё прекрасно работает. Почему-то No-IP спокойно резолвит на тот внешний IP, с которого пришёл запрос на смену адреса, а KeenDNS прописывает какую-то отсебятину.

На форуме техподдержки один парень пытался доказать ровно то же самое, но его заклеймили что он ничего не понимает, тыкая статейками про отличия белого и серого адресов и выставляя дураком. Приведу наверное самую информативную часть из ответов тому парню от техподдержки на форуме (всю ветку можно почитать по ссылке в самом начале поста):

KeenDNS это не только служба доменных имен, но и облачный сервис посредник, позволяющий получать доступ к клиентам с серым ip. У вас как раз такой случай, но не типовой, а с полной переадресацией о которой KeenDNS не знает и поэтому работает по "серой схеме", ориентируясь на серый адрес на WAN, позволяя вам получить доступ находясь за NAT. То что NAT при этом открыт и можно через него ходить напрямую KeenDNS не сообщили. Noip же обычная DynDNS служба, которая просто выдаёт ip и всё. За NAT вы или нет noip не интересует. Сравнивать эти две службы некорректно.

Вопрос остался не раскрыт. Почему некорректно сравнивать эти две службы, если по сути они выполняют одну и ту же задачу?

Это не баг, а схема работы. Белый ip - прямой доступ, серый ip - облачный доступ. ip определяется по WAN. Тут речь идёт о необходимости третьего сценария серый ip - прямой доступ с выдачей внешнего ip на DNS запросы. Этот вопрос больше для раздела "Развитие" подходит. Баг это когда всё идёт не по плану, а в данном случае KeenDNS отрабатывает штатно, как и было задумано.

Похоже моё появление в Гунценхаузене было задумано изначально. Надеюсь до технарей в keenetic как-то доберётся мой сегодняшний опус и они помогут с переездом обратно в Россию.