Что значит другой сервер

Что будет, если поменять, сменить сервер в игре Genshin Impact

Смотреть видео гайд

Описание видео гайда

В этом видео гайде для новичков и опытных игроков по прохождению игры Genshin Impact рассказывается о том, что будет, если поменять сервер, можно ли вообще поменять сервер, пропадет ли полученный игровой прогресс при смене разных серверов в Геншин Импакт.

Безопасно ли менять сервер

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

Какой сервер выбрать для России

Для России рекомендуется выбирать сервер «Европа» (Europa), поскольку при игре на других серверах вы можете увидеть высокий пинг, что не позволит вам комфортно играть с другими игроками, поскольку из-за высокого пинга будет понижена отзывчивость персонажа.

Текст видео гайда (субтитры)

Всем привет, друзья, с вами реала из на моем канале есть видео, которое называется как сделать общий аккаунт или как привязать почту Геншин Импакт здесь очень много комментариев и один из самых популярных, что будет если вы на одном аккаунте будете переключаться на другие сервера, то есть пропадет ли ваш прогресс когда вы переключитесь на другой сервер, поскольку я уже не играю в ген джан импорта давайте сейчас мы это и проверим весь мой прогресс и достижения когда я играл вершин impact находится на сервере Европа давайте зайдем и посмотрим здесь находится мои персонажей, в то время я успел прокачаться до 23 уровня.

Теперь мы выходим из игры обратно в меню и давайте поменяем сервер ну, например, на азию нажимаем подтвердить и начинаем наше путешествие нас началась катсцена, где нам нужно будет определить за кого мы будем играть за парня или за девушку, то есть самое-самое начало игры на новом сервере выбираем персонажи.

Ну давайте девчонку, потому что на основном аккаунте у меня было парень пишем новое имя и вот начинается наше обучение проходить мы его, конечно, не будем.

Самое главное нам проверить.

Что же стало с нашим аккаунтом на Европе стер целей прогресс и так далее.

Также обратите внимание верхний правый угол, что выбрав Азии у нас резко поднимается pink выходим из игры и пытаемся обратно зайти на европу выбираем европам я думаю, что прогресс, в принципе должен сохраниться начинаем играть ну, а вот что и следовало доказать прогресс действительно сохранился.

Обратите внимание на верхний правый угол pink у нас резко упал, потому что мы выбрали оптимальный сервер, таким образом можно сделать заключение, что на одном аккаунте можно играть на разных серверах между ними переключаться и на каждом сервере у вас будет отдельный прогресс и предыдущий прогресс на другом сервере не пропадает надеюсь, что я ответил на ваш вопрос увидимся с вами в следующих видеороликах всем, друзья, удачи всем пока.

Источник

Давайте уже разберемся в DNS

Внимательный читатель найдет на этой картинке IPv6

Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.

Что такое DNS

DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.

Вот и все. Правда. Вы или ваш браузер запрашивает значение для ключа www.example.com , и получает в ответ 1.2.3.4 .

Базовые штуки

Большой плюс DNS в том, что это публичная услуга, и можно потыкать в сервера если хочется разобраться. Давайте попробуем. У меня есть домен petekeen.net , который хостится на машине web01.bugsplat.info . Команды, используемые ниже, можно запустить из командной строки OS X (ой, то есть macOS, — прим. пер.).

Давайте взглянем на маппинг между именем и адресом:

Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:

Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:

dig по-умолчанию запрашивает A -записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4 -адрес. Есть эквивалент для IPv6 -адресов — AAAA . Давайте взглянем на ответ:

Тут говорится, что у хоста web01.bugsplat.info. есть один адрес A : 192.241.250.244 . Число 300 это TTL , или time to live (время жизни). Столько секунд можно держать значение в кэше до повторной проверки. Слово IN означает Internet . Так сложилось исторически, это нужно для разделения типов сетей. Подробнее об этом можно почитать в документе IANA’s DNS Parameters.

Оставшаяся часть ответа описывает сам ответ:

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

Как видите, при обычном DNS-запросе происходит куча всего. Каждый раз, когда вы открываете веб-страницу, браузер делает десятки таких запросов, в том числе для загрузки всех внешних ресурсов вроде картинок и скриптов. Каждый ресурс отвечает за минимум один новый DNS-запрос, и если бы DNS не был рассчитан на сильное кэширование, то трафика генерировалось бы очень много.

Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info ?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig ‘у, если бы информация не был закэширована:

Информация выводится в иерархической последовательности. Помните как dig вставил точку . после хоста, web01.bugsplat.info ? Так вот, точка . это важная деталь, и она означает корень иерархии.

Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.

Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS- записи. NS -запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS -записи для вас.

В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A -запись для web01.bugsplat.info . Видно только IP-адрес корневого сервера ( 192.5.5.241 ). Так какой именно корневой сервер это был? Давайте узнаем!

Флаг -x заставляет dig провести обратный поиск по IP-адресу. DNS отвечает записью PTR , которая соединяет IP и хост, в данном случае — f.root-servers.net .

Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS -серверов. Он отвечает за домен верхнего уровня info . dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info , и получает в ответ еще один набор NS -серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info. . И, наконец, получает ответ!

Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» — прим. от rrrav). Домены верхнего уровня com , net , org , и т.д. тоже обычно сильно закэшированы.

Другие типы

Есть еще несколько типов, о которых стоит знать. Первый это MX . Он соединяет доменное имя с одним или несколькими почтовыми серверами. Электронная почта настолько важна, что у нее есть свой тип DNS-записи. Вот значения MX для petekeen.net :

Заметьте, что MX -запись указывает на имя, а не на IP-адрес.

Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:

Сразу видно, что мы получили два ответа. Первый говорит, что www.petekeen.net указывает на web01.bugsplat.info . Второй возвращает запись A для того сервера. Можно считать, что CNAME это псевдоним (или алиас) для другого сервера.

Что не так с CNAME

Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.

Причина в том, что DNS производит замену таким образом, что все записи того места, куда указывает CNAME , также валидны для CNAME . В нашем примере, записи у www.petekeen.net и web01.bugsplat.info будут совпадать.

Поэтому нельзя делать CNAME на корневом домене вроде petekeen.net , потому что обычно там нужны другие записи, например, MX .

Запросы к другим серверам

Давайте представим, что конфигурация DNS испорчена. Вам кажется, что вы исправили проблему, но не хотите ждать когда обновится кэш чтобы удостовериться. С помощью dig можно сделать запрос к публичному DNS-серверу вместо своего дефолтного, вот так:

Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .

Типичные ситуации

Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.

Редирект домена на www

Часто нужно сделать редирект домена iskettlemanstillopen.com на www.iskettlemanstillopen.com . Регистраторы типа Namecheap или DNSimple называют это URL Redirect. Вот пример из админки Namecheap:

Символ @ означает корневой домен iskettlemanstillopen.com . Давайте посмотрим на запись A у этого домена:

Этот IP принадлежит Namecheap’у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com :

CNAME для Heroku или Github

Взгляните на скриншот выше. На второй строке там CNAME . В этом случае www.iskettlemanstillopen.com указывает на приложение, запущенное на Heroku.

С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию.

Wildcards

Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info . Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:

Заключение

Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:

Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.

Источник

Вынос локального сервера в сеть с помощью другого внешнего сервера

Добрый день, хабровчане! История такова: сколько себя помню, всегда дома висел какой-нибудь сервер, который очень хотелось вывести во всеми нами любимый Интернет.

«Ну и что тут сложного? Практически любой провайдер предоставляет статический белый IP за небольшую плату!», – скажите Вы и будете абсолютно правы. Но это платно, да и вообще хотелось попробовать чего-нибудь более оригинального. Основная проблема доступа к моему серверу – NAT. Если вдруг кто не знает, что это, ниже оставил пояснение из Википедии.

NAT (от англ. Network Address Translation — «преобразование сетевых адресов») — это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов. Также имеет названия IP Masquerading, Network Masquerading и Native Address Translation.

Преобразование адреса методом NAT может производиться почти любым маршрутизирующим устройством — маршрутизатором, сервером доступа, межсетевым экраном. Наиболее популярным является SNAT, суть механизма которого состоит в замене адреса источника (англ. source) при прохождении пакета в одну сторону и обратной замене адреса назначения (англ. destination) в ответном пакете. Наряду с адресами источник/назначение могут также заменяться номера портов источника и назначения.

Принимая пакет от локального компьютера, роутер смотрит на IP-адрес назначения. Если это локальный адрес, то пакет пересылается другому локальному компьютеру. Если нет, то пакет надо переслать наружу в интернет. Но ведь обратным адресом в пакете указан локальный адрес компьютера, который из интернета будет недоступен. Поэтому роутер «на лету» транслирует (подменяет) обратный IP-адрес пакета на свой внешний (видимый из интернета) IP-адрес и меняет номер порта (чтобы различать ответные пакеты, адресованные разным локальным компьютерам). Комбинацию, нужную для обратной подстановки, роутер сохраняет у себя во временной таблице. Через некоторое время после того, как клиент и сервер закончат обмениваться пакетами, роутер сотрет у себя в таблице запись о n-ом порте за сроком давности.

Если своими словами, это внешний маршрутизатор, позволяющий Вам отправлять запросы в интернет, но не позволяющий Вам их получать. Ответ-то из Интернета Вы получаете, а значит уже не все потеряно. Мне вспомнилась старая программа LogMeIn Hamach, она же позволяла нам обмениваться пакетами данных при том, что ВСЕ клиенты были в закрытой NAT’ом сети. А что, если реализовать что-нибудь подобное:

Что здесь нарисовано? OPI – это моя Orange Pi PC, которая выполняет роль сервера, NAT – это, как несложно догадаться, маршрутизатор моего оператора (он может быть не один, но сути это не меняет), KVM – внешний сервер товарища, CLI – клиент. Возможно, у вас возник вопрос: «По какой причине ты не мог просто выкинуть все свои сервисы на сервер товарища?». Ответ прост: не хочу. В конце концов и дисковое пространство пришлось бы использовать чужое, а меня это не устраивает. Не говоря уже об усложнении администрирования и обслуживания сервера…

OPI подключается к KVM и между ними устанавливается VPN канал. А далее клиент подключается к KVM, и эта машина в свою очередь отправляет запрос через VPN к OPI.

Почему KVM? Сервер товарища – обычный VDS(Virtual Dedicated Server). Обычно это либо KVM (Kernel-based Virtual Machine), либо OVZ (OpenVZ). OVZ в нашем случае не подходит, так как iptables там работают как-то не так, да и вообще штука очень странная.

Настройка сервера

В теории это звучит все здорово, но теперь надо реализовывать на практике. Нужно выбрать протокол для VPN. Изначально, я был склонен к OpenVPN, но после череды проб, ошибок, неудач, пришел к выводу, что это не лучший протокол для таких действий. В конце концов он использует сложные алгоритмы шифрования, которые еще и будут неслабо грузить процессор OPI и внешнего сервера, поэтому мой выбор пал на протокол PPTP.

Первым делом надо установить сам PPTP демон на сервере:

Следующим шагом его надо настроить. Откроем его конфиг файл /etc/pptpd.conf и укажем IP адрес сервера и диапазон IP адресов клиентов:

Теперь нужно создать учетные записи VPN клиентов. Их список находится в файле /etc/ppp/chap-secrets

Мы создали клиента orange с паролем pass123 и IP адресом 10.0.0.100. Если вместо IP адреса указать *, то клиент получит любой свободный IP адрес из диапазона, указанного в remoteip. Нам рандома явно не надо. Теперь еще пару штрихов с настройками PPTPD. Добавим DNS сервера в файле /etc/ppp/pptpd-options

И перезагрузим PPTPD:

Очень важный шаг – включение IP форвардинга. Это позволит Вам пересылать пакеты между публичным IP и приватными IP, которые Вы настроили при помощи PPTP. Редактируем файл /etc/sysctl.conf и раскомментируем строку:

Отлично, теперь можно начинать колдовать с ipatables. Для начала узнаем название нашего сетевого интерфейса:

У меня он называется ens3. Однако, чаще всего он называется eth0.

Создаем правило iptables:

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

ppp0 – виртуальный интерфейс сети.

Настройка локального сервера

Далее нужно подключить нашего первого клиента – Orange PI. На этом моменте я засел надолго, так как все инструкции в интернете говорили одно и то же, и все они не работали.

Первым делом на Orange PI установим PPTP клиент:

Создадим файл /etc/ppp/peers/pptpserver и впишем следующее:

Не забудьте поменять IP адрес сервера и прочие данные на свои.

Далее закомментируем все строки в файле /etc/ppp/options вставкой символа #
Файл /etc/ppp/options.pptp нужно привести к следующему виду:

И, наконец, пробуем подключиться:

Если все получилось, попробуем посмотреть на наш виртуальный интерфейс:

Попробуем пропинговать Orange PI с внешнего сервера:

Проброс портов

Теперь самая малость: перенаправление пакетов с сервера на Orange PI. Тут уже способы могут быть разными, но так как на этом сервере 80 и 443 порт не используются вообще, мы можем просто попросить сервер все пакеты для этих портов перенаправлять на OPI

На забудьте поменять IP адреса на свои. Проверим, что все работает:

Здорово! Цель достигнута!

Маленькие доработки

Но вдруг в здании, где располагается Orange PI выключается свет и… После перезагрузки никто опять не может получить доступ к нашему апельсину. Почему? Потому что сам по себе Orange PI к VPN не подключится. Напишем простой скрипт на bash, который будет вциклически выполняться, проверяя, установлено ли соединение:

Теперь добавим его в автозагрузку. В файл /etc/rc.local впишем строку с расположением скрипта. В моем случае это:

Не забываем дать скрипту права на исполнение:

Внимательный пользователь мог заметить, что в скрипте есть команды echo, но ведь им некуда делать вывод! Изначально, я планировал сделать в виде сервиса, чтобы вывод удобно капал туда, но в итоге банально поленился, работает же. Кстати, а работает ли? Перезагружаем наш апельсин и видим, что интерфейс ppp0 успешно поднялся, а наши сервисы доступны из интернета. Цель достигнута, господа!

Все это сделано исключительно в развлекательных и учебных целях. Практической пользы это почти не несет, так как нам все равно необходим внешний сервер, да и нагрузка не его сеть удваивается, ибо ему приходиться принимать пакеты и сразу же передавать их дальше. Однако, у этого метода есть преимущества, т.к. реальный IP нашего сервера будет скрыт, этот внешний сервер сможет лучше противостоять DDoS атакам, а также сможет выводить беспокойным пользователям страницу о технических работах, если Orange PI будет недоступен. Конечно же, для этого нужно будет еще серьезно постараться, но разве не в самом пути к цели все удовольствие, товарищи?

Источник