https://www.rapidtables.com/convert/number/hex-to-ascii.html
HEX to Win-1251
Спасибо, чем то подобным и пользуюсь предварительно распарсив вручную, хочется красивого оффлайн решения, наверное как всегда проще написать самому 😅
Dasty
Максим
Dasty
проще не использовать русские буквы)
Для технарей да, для гуманитариев нет, а иногда им приходится взаимодействовать 😆
Rustem
Максим
Для технарей да, для гуманитариев нет, а иногда им приходится взаимодействовать 😆
гуманитариев на управляемых железках быть недолжно. потом плачевные последствия могут быть...
Антон
Rustem
Вот к примеру есть следующая задача у меня. Требуется развернуть на DigitalOcean 6 интернет-магазинов в 6 разных географических регионах. Если я переведу на IPv6 скорость загрузки сайта качественным образом сократится? Проект не боевой пока, тестируем.
Cumberbatch
Dasty
гуманитариев на управляемых железках быть недолжно. потом плачевные последствия могут быть...
Экспорт и конвертация как раз и призваны не пускать, а отдать часть инфы в удобочитаемом виде. Ну и это уже оффтоп, давайте заканчивать и не примерять свой опыт друг на друга, ок? 🙃
Cumberbatch
Вот к примеру есть следующая задача у меня. Требуется развернуть на DigitalOcean 6 интернет-магазинов в 6 разных географических регионах. Если я переведу на IPv6 скорость загрузки сайта качественным образом сократится? Проект не боевой пока, тестируем.
IPv6 в большинстве работает быстрее если нет узких каналов последней мили
Innokentiy
Innokentiy
Михаил
Оттуда же. Просто если явно днс сервер не указан берутся системные
Благодарю.
Как-то запретить можно выдачу системных настроек, в частности адресов DNS-серверов самого микрота?
Innokentiy
потому что время загрузки у большинства клиентов складывается из времени прохождения пакета по трассе туда-сюда (оно слабо зависит от протокола), и времени генерации ответа сервером (оно не зависит от протокола никак)
Innokentiy
Благодарю.
Как-то запретить можно выдачу системных настроек, в частности адресов DNS-серверов самого микрота?
попробуйте выдать 0.0.0.0, лет 10 назад это работало, мб и сейчас сработает
Rustem
потому что время загрузки у большинства клиентов складывается из времени прохождения пакета по трассе туда-сюда (оно слабо зависит от протокола), и времени генерации ответа сервером (оно не зависит от протокола никак)
понял, благодарю за ответ! А в каких случаях рекомендован переход на IPv6?
Innokentiy
во всех, когда у вас есть силы и компетенции его поддерживать
Innokentiy
потому что есть некоторое (незначительное) количество клиентов, которые по в6 будут работать быстрее
Innokentiy
в будущем их число будет только расти
Innokentiy
пока что, если желания морочиться с ними нет, их можно смело игнорировать
Михаил
попробуйте выдать 0.0.0.0, лет 10 назад это работало, мб и сейчас сработает
сейчас попробую, спасибо
Rustem
я просто предположил, что мобильные операторы Европы например уже массово переходят на IPv6 и клиент, который использует мобильный интернет тоже будет использовать IPv6, но это мои догадки всего лишь
Innokentiy
догадка правильная, но лишь отчасти
Innokentiy
мобильные операторы обеспечивают доступ и в в4-интернет
Innokentiy
если мобильный клиент получает доступ в6-онли, то где-то в сети оператора будет выполняться nat64
Innokentiy
и для таких клиентов нативный доступ по в6 будет чууууточку быстрее
Rustem
Благодарю за информацию
Rustem
Кстати, вот что выдается абонентам в Польше
Rustem
Innokentiy
это дуалстек
Innokentiy
(там под капотом в сети оператора может быть в6-онли, оставим это за скобками)
Innokentiy
если клиенту доступны и в4 и в6, он сам должен предпочесть, что использовать
Cumberbatch
Innokentiy
https://www.google.com/intl/en/ipv6/statistics.html вот тут можно посмотреть стату по гуглу
Innokentiy
по клику по стране показывается latency/impact
Innokentiy
это тот самый средний выигрыш за счет использования нативного в6
Innokentiy
если значение отрицательное - в6 быстрее, если положительное - в4 быстрее, и показывает, сколько вы миллисекунд потенциально выиграете
Rustem
Innokentiy
по китаю карта гугла врет, пушо в китае гугл забанен
Innokentiy
ну и, возвращаясь к вопросу о веб-серверах, даже если ваш сервер генерит ответ за 100мс (что почти нереально в условиях интернет-магазина, если вы не упарываетесь по хайлоаду специально), плюс 30мс ртт, даже 10мс выигрыша за счет в6 вам погоду не сделают
Rustem
Innokentiy
Innokentiy
трафика в6 в интернете намного меньше
Innokentiy
вот по амстердамской точке обмена трафиком, например: https://stats.ams-ix.net/sflow/ether_type.html
Innokentiy
порядка 4.5%
Rustem
https://www.ipv6-test.com/stats/
Антон
Не показательно.
Innokentiy
для того, чтобы пошел трафик в6, необходимы условия:
- провайдер клиента умеет в в6 (многим провайдерам лень поддерживать второй протокол, потому что на это нужно вдвое больше сил, а денег оно не принесет ни копейки)
- сам клиент умеет в в6 (часто в6 выключают по рекомендациям из интернета, либо он вовсе не поддерживается)
- провайдер интернет-ресурса умеет в в6 (а ему лень, см. п1)
- администратор интернет-ресурса умеет в в6 (а ему тоже лень, см. п1)
Innokentiy
потому фактически стата гугла измеряет первые 2 пункта совокупно
Innokentiy
а данные амс-их - все 4
Innokentiy
можно померять и отдельные показатели, в принципе, но незачем, и так довольно показательно
Innokentiy
самые ленивые - администраторы веб-ресурсов, есличо)
Innokentiy
не всегда
Innokentiy
nslookup -q=aaaa mikrotik-courses.ru
Server: UnKnown
Address: 192.168.110.1
*** No IPv6 address (AAAA) records available for mikrotik-courses.ru
Innokentiy
вряд ли тут постарались инфобезы, например)
Innokentiy
у меня, например, тоже есть парочка подконтрольных ресурсов, и смысла топорщиться и поддерживать их по в6 я пока не вижу никакого
Михаил
попробуйте выдать 0.0.0.0, лет 10 назад это работало, мб и сейчас сработает
прописал все нули.
вообще ничего в маршрутах не поменялось, всё так же "подцепились" маршруты до системных DNS.
сейчас прописал в настройках ppp-профиля в качестве DNS адрес самого микротика.
пусть клиент отправляет в поднятый впн-туннель пакеты, адресованные этому микроту, если им так хочется.
Volodymyr
прописал все нули.
вообще ничего в маршрутах не поменялось, всё так же "подцепились" маршруты до системных DNS.
сейчас прописал в настройках ppp-профиля в качестве DNS адрес самого микротика.
пусть клиент отправляет в поднятый впн-туннель пакеты, адресованные этому микроту, если им так хочется.
Попробуте линклокал адреса прописать.
Cumberbatch
Не очень понял, про какой конкретно адрес идёт речь
На сервере же какой то адрес при подключение назначается. Вот его
Михаил
На сервере же какой то адрес при подключение назначается. Вот его
Адрес устройства внутри впн-туннеля, это я понял.
Речь про адрес "серверного" микротика или клиентского устройства?
Mikе
Коллеги, подскажите как реализовать. Два узла. В одном статика в другом динамика. Нужно со стороны узла с динамикой, сделать проброс на внутренний ресурс через ip статического узла. Раньше помогал банальный маскарад l2tp туннеля. Какие есть варианты?
Volodymyr
Коллеги, подскажите как реализовать. Два узла. В одном статика в другом динамика. Нужно со стороны узла с динамикой, сделать проброс на внутренний ресурс через ip статического узла. Раньше помогал банальный маскарад l2tp туннеля. Какие есть варианты?
Обычный НАТ. К чему тут в условии l2tp и маскарад через него?
Mikе
Обычный НАТ. К чему тут в условии l2tp и маскарад через него?
Как вы получите "чужую" статику между узлами?
Mikе
Узлы это филиалы.
Volodymyr
Как вы получите "чужую" статику между узлами?
Зачем что-то где-то получать? Не понимаю Вашу терминологию. Вам нужно проброс сделать или что?
Mikе
Зачем что-то где-то получать? Не понимаю Вашу терминологию. Вам нужно проброс сделать или что?
Все верно, проброс. Там где он нужен, нет статического адреса. Нужно воспользоваться статикой с другого объекта. Так понятней?
Volodymyr
Cumberbatch
Все верно, проброс. Там где он нужен, нет статического адреса. Нужно воспользоваться статикой с другого объекта. Так понятней?
Получаете запрос на статику. Делаете первый дстнат на внутренний адрес в сторону динамики. На динамике еще один дстнат в локалку.
Что не так то?
Михаил
127... или 169.254...
Яснее не стало.
127.0.0.1 - это localhost, адрес перенаправления "на себя".
169.254.х.х - это адрес APIPA, который присваивается хосту в случаях, когда он не получил данные по DHCP.
Адреса внутри vpn-туннеля "сервера" и клиента уже указаны в профиле pptp-учетки на микротике, а заодно и адрес сети, которая будет на стороне клиента за vpn-туннелем.
Лично я не очень понимаю, что даст указание в качестве DNS-сервера какого-либо из перечисленных выше адресов.
Подскажите пожалуйста, какой именно адрес Вы предлагаете указать в ppp-профиле в качестве DNS-сервера и что это даст.
Volodymyr
Яснее не стало.
127.0.0.1 - это localhost, адрес перенаправления "на себя".
169.254.х.х - это адрес APIPA, который присваивается хосту в случаях, когда он не получил данные по DHCP.
Адреса внутри vpn-туннеля "сервера" и клиента уже указаны в профиле pptp-учетки на микротике, а заодно и адрес сети, которая будет на стороне клиента за vpn-туннелем.
Лично я не очень понимаю, что даст указание в качестве DNS-сервера какого-либо из перечисленных выше адресов.
Подскажите пожалуйста, какой именно адрес Вы предлагаете указать в ppp-профиле в качестве DNS-сервера и что это даст.
Даст то, что клиент не будет ходить за разрешением имен в туннель. Вы же этого хотите? Хотя на мой взгляд, проще отключить на клиенте получение ДНС с пира.