Короткий ответ
Нет.
Тем не менее, вы можете использовать DNS, чтобы (помочь) выполнить то, что вы хотите сделать.
Оценивая ситуацию
Это действительно похоже на проблему XY. Вы пытаетесь выяснить, как конфигурация DNS будет контролировать маршрутизацию. Проблема в том, что DNS мало влияет на маршрутизацию. Вероятно, это связано с некоторым отсутствием знаний о том, как работает маршрутизация.
Итак, я согласен с ответом D34DM347. Однако, когда возникает проблема XY, я понимаю, что иногда вам нужен не просто ответ, который пытается помочь вам найти правильное направление, потому что это направление может показаться нежелательным, если вы не поймете больше деталей о причинах этого направления. преследовало. Итак, я коснусь некоторых концепций дизайна здесь.
Обобщать это небезопасно
"система в целом" скорее всего настроена на ...
Что ж, информация о "системе в целом" может существенно различаться. Есть разные подходы, чтобы делать вещи. Некоторые могут быть более эффективными, хотя и ценой сложности в настройке.
Ваш вопрос заключается в поиске возможности сократить путь, по которому идет трафик, чтобы трафик мог использовать ваше локальное оборудование и пропустить прохождение через Интернет. Ну, возможно ли это, или нет, будет зависеть от вашего местного оборудования. Ответ будет разным для разных сетей, в зависимости от того, какое у вас локальное оборудование. Стандарты всемирной интернет-маршрутизации не будут касаться множества деталей о том, работает ли на вашем локальном оборудовании DNS-сервер.
Я не хочу быть слишком конкретным, предоставив только один ответ о том, как все работает, потому что есть несколько способов, которыми вещи могут происходить. Разные решения имеют разные возможности. Ограничения простых возможностей являются одной из причин, по которым могут быть доступны разные варианты.
Другая причина для нескольких возможных конструкций может заключаться в том, что некоторые устройства могут иметь более продвинутые возможности, чем я могу предсказать. Например, я помню, как настраивал маршрутизатор для отправки трафика на компьютер, который будет проверять исходящий трафик, и передавать проверенный трафик обратно на маршрутизатор, который имел физическое соединение с Интернетом. Моя настройка не удалась, потому что маршрутизатор был разработан для оптимизации трафика, поэтому оборудование попыталось превзойти мой дизайн, заставив трафик пропустить то, что, по его мнению, было ненужным шагом.
Поскольку существуют различные возможные ситуации, которые могут зависеть от деталей, например, от того, какое программное обеспечение для «DNS-сервера» может быть использовано, не существует только одного простого ответа, который скажет, на что способна ваша локальная сеть. (Ваш вопрос был довольно расплывчатым в отношении некоторых деталей о вашей настройке (например, какое оборудование используется и, возможно, какие операционные системы или веб-браузеры вы используете), не существует единственного простого ответа, который применим ко всем возможным ситуациям.) Итак, я просто приведу некоторые общие рекомендации относительно того, что обычно доступно.
Разрешение имени
Многие DNS-серверы поддерживают концепцию, называемую "расщепленный горизонт", что в основном означает, что ответ, полученный от DNS-сервера, будет зависеть от того, откуда поступил запрос. Например, общепринятым методом является предоставление одного ответа (который является внутренним адресом) на все запросы, которые поступают с адресов "IETF BCP 5" (более известных как адреса "RFC 1918", которые являются адресами IPv4, начинающимися с "10"). «или« 192.168. »или номер, начинающийся с« 172.16. »до« 172.31. »), будет отправлен на ваш внутренний адрес. На запросы с других адресов IPv4 будет получен другой ответ, который приведет к указанию на другой адрес, доступный из большинства мест на этой планете. (IPv6 также будет обрабатываться с использованием различных деталей конфигурации, но может быть настроен для работы аналогично IPv4. Чтобы сохранить разумность, вероятно, IPv6 должен быть настроен аналогично IPv4.)
Теперь, является ли это легкодоступным вариантом для вас или нет, может зависеть от таких факторов, как то, какой DNS-сервер используется.
Если ваш веб-браузер находится на компьютере, который перенаправляет весь трафик DNS на известный общедоступный DNS-сервер, например google-public-dns-a.google.com (8.8.8.8) или OpenDNS (208.67.222.222 и 208.67.220.220), то это, вероятно, не вариант для вас. Это распространенный сценарий.
Тем не менее, другой довольно распространенный сценарий может работать нормально. Если ваш веб-браузер использует DNS-сервер, рекомендованный вашим DHCP-сервером, и если ваш DHCP-сервер является вашим локальным маршрутизатором, и если этот рекомендуемый DNS-сервер также является вашим локальным маршрутизатором, вы можете настроить его, посмотрев в настройте маршрутизатор для функции «DNS-сервер» и найдите что-то, ссылающееся на разделение горизонта (или похожий термин, например "разделенный DNS").
Таким образом, один из вариантов может включать настройку DNS-сервера в вашем регионе. Тем не менее, даже это может быть больше работы, чем то, что вам нужно. Вы можете сделать то же самое, используя технику "разрешения имен", отличную от DNS. Большинство компьютеров будут поддерживать сначала использование "файла хостов" в качестве основного ресурса для проверки, а затем использовать DNS, если локальный "файл хостов" системы не предоставляет более конкретную информацию. Таким образом, если у вас есть только один веб-браузер, с которым вы хотите это сделать, вы можете достичь своей цели (или сократить маршрут трафика), просто отредактировав текстовый файл, который полностью обходит DNS.
SSH нажатия клавиш
если я SSH на сервер (по его доменному имени), каждое нажатие клавиши [идет к провайдеру]
В зависимости от того, будут ли нажатия клавиш обращаться к провайдеру, все будет зависеть от таких деталей, как используемый вами IP-адрес и маршрутизация IP-трафика на этот IP-адрес. (Поймите, что IP-адрес довольно числовой, например 192.168.0.10 в IPv4 или fd00::abcd в IPv6, который использует шестнадцатеричное значение. Доменное имя, используемое в DNS, например example.com, не является IP-адресом.) Когда вы «SSH подключаетесь к серверу (по его доменному имени)», на самом деле происходит то, что ваш SSH-клиент выполнит поиск "разрешения имен", который, вероятно, будет включать проверку данных в "файле хостов", а затем проверку DNS. (Могут быть и другие шаги, такие как проверка локального кэша "решателя" перед выполнением любого из этих действий, а затем, если используется DNS, сохранение результатов в кэше "решателя", чтобы ускорить процесс в следующий раз.) Ваш SSH-клиент делает это перед попыткой установить связь с удаленным компьютером. Затем, как только процесс "разрешения имен" был использован для генерации IP-адреса, клиент SSH установит SSH-соединение, используя IP-адрес, полученный в результате поиска "разрешения имен". Таким образом, способ обработки трафика будет зависеть от IP-адреса, а не от того, набрали ли вы имя домена.
Основная общая задача DNS состоит в том, чтобы просто помочь процессу "разрешения имен" преобразовать имя в IP-адрес. То, как трафик перемещается по всей системе, является концепцией, которую чаще всего называют "маршрутизацией", и которая обрабатывается другим программным обеспечением / конфигурациями, нежели "разрешение имен". Таким образом, люди, которые хорошо разбираются в этом, постараются ответить на ваши вопросы, связанные с DNS, отдельно от вопросов, связанных с маршрутизатором, потому что это действительно отдельные технологии, разработанные для разных целей, и все будет проще, если вы попытаетесь думать о том, как они разработан. В своей голове держите DNS и маршрутизацию отдельно.
Это завершает мое освещение темы DNS. Теперь позвольте мне заняться другой важной темой вашего вопроса, а именно тем, как маршрутизируется трафик.
маршрутизация
сервер -> сервер
Это также может быть вариантом. Когда компьютер пытается отправить сетевой трафик, частью процесса является создание правильного фрейма "Уровень 2". Наиболее распространенные формы фреймов "уровня 2" в домашних сетях - это фреймы Ethernet, которые будут отправляться по кабелю UTP, или фреймы Wi-Fi, которые отправляются по воздуховодам. (Коммерческие сайты могут использовать другие технологии, такие как волоконно-оптические соединения.) Типичный кадр "уровня 2" будет использовать адрес MAC-48 для идентификации получателя.
Компьютер, который отправляет трафик, проверит IP-адрес получателя. Например, предположим, что компьютер, отправляющий трафик, использует IPv4 192.168.1.205, а компьютер, который будет получать трафик, - IPv4 192.168.1.15. Если ваш компьютер использует маску подсети 255.255.255.0, это означает, что размер подсети составляет 256 адресов. (Если бы у вас была другая маска подсети, которая начинается с «255.255.255.», То это была бы меньшая подсеть.) Существует одна подсеть, которая имеет 256 адресов и содержит 192.168.1.205, и это подсеть, которая идет от 192.168.1.0 до 192.168.1.255.
Поскольку 192.168.1.15 является частью той же подсети, компьютер отправит кадр уровня 2, используя адрес MAC-48 желаемого пункта назначения (который, как показывает ваша диаграмма, является сервером). Не будет никакого трафика, отправленного на любой из адресов маршрутизатора.
Если, с другой стороны, адрес назначения был 203.0.113.6, то он не был бы частью той же подсети, что и источник (192.168.1.205). В этом случае таблица маршрутизации указывает, что трафик отправляется на устройство "шлюза". ("Шлюз по умолчанию", скорее всего, ваш маршрутизатор.) Таким образом, компьютер отправит кадр уровня 2, используя MAC-48 адрес шлюза. Цель вашего компьютера - верить, что шлюз будет знать, какое из его сетевых подключений будет полезно для получения трафика до желаемого пункта назначения. Шлюз может использовать сетевое соединение, которое обменивается данными с поставщиком услуг Интернета, или нет. Эти детали контролируются такими факторами, как то, какие IP-адреса используются, и насколько велики подсети.
Маршрутизация обрабатывается такими ключевыми сведениями о маршрутизации, как IP-адрес исходного компьютера, IP-адрес назначения, размер подсети исходного компьютера и "шлюз по умолчанию", который обрабатывает трафик, который не является частью более конкретной подсети. Компьютер в домашней сети обычно получает большинство этих данных для IPv4 с помощью DHCP. Единственным исключением является «IP-адрес назначения», и это единственная часть процесса, с которой "разрешение имен" может быть связано.
сервер -> маршрутизатор -> сервер
Вы спрашивали, если это возможно. Это может быть. Я опишу, как это может работать.
Это предпочтительнее, чем отправка трафика провайдеру. (Это совсем не беспокоит оборудование интернет-провайдера, и связь идет быстрее, чем необходимость отправки трафика на удаленный конец.)
Прежде всего, когда маршрутизатор получает трафик, он смотрит на адрес MAC-48 назначения. Если адрес назначения MAC-48, а не маршрутизатор, то маршрутизатор ничего не делает с трафиком, если только маршрутизатор не настроен на работу в качестве коммутатора. Обычно домашние маршрутизаторы маркируют некоторые из своих сетевых портов как «порт LAN», и эти порты рассматриваются как один «канал», поэтому маршрутизатор будет действовать как коммутатор для этих устройств. В этом случае маршрутизатор будет отправлять трафик через один или несколько портов, которые обрабатываются как коммутатор.
Чтобы трафик проходил от внутреннего порта LAN к провайдеру, маршрутизатор должен отправлять трафик через сетевой порт, который связывается с провайдером. Ваша типичная домашняя сеть вряд ли будет делать это, если IP-адрес назначения является одним из "частных" адресов, таких как IPv4-адреса, указанные в IETF BCP 5 (более известный как RFC 1918). Кроме того, большинство интернет-провайдеров просто блокируют трафик IETF BCP 5 в поле зрения (и не отправляют этот трафик обратно вам). Таким образом, эта настройка (сервер -> маршрутизатор -> сервер), скорее всего, будет происходить на самом деле, а не более сложным процессом с участием провайдера.
Если информация проходит через маршрутизатор, но вы просто используете адреса IETF BCP5 на внутренних портах локальной сети, я обычно не называю это использованием маршрутизатора. Вместо этого маршрутизатор обрабатывает трафик как "коммутатор", просто используя адреса MAC-48 для принятия решений, связанных с потоком трафика.
Существует еще одна возможная настройка, которая заключается в том, что вы можете использовать адрес WAN. В этом случае используются несколько подсетей, и поэтому устройство работает как маршрутизатор. Это становится более сложным, но, поскольку это возможно, что-то может работать, стоит остановиться здесь. Я приведу пример того, как это может работать успешно. Этот следующий параграф содержит несколько IP-адресов. Чтобы сохранить правильность этих адресов, основная деталь, которую необходимо отслеживать, состоит в том, что адреса, начинающиеся с «192.168.1», предназначены для IP-адресов в локальной сети, а адреса, начинающиеся с «203.0.113», являются адресами для подключения к глобальной сети. (где маршрутизатор подключается к провайдеру).
Может случиться так, что устройство шлюза у провайдера может иметь устройство шлюза, использующее адрес, такой как 203.0.113.5, и адрес IPv4 203.0.113.6, назначенный "порту WAN" вашего маршрутизатора. Если ваш компьютер в 192.168.1.200 пытается установить связь с 203.0.113.6 (порт WAN вашего маршрутизатора), то ваш маршрутизатор будет получать трафик (через порт LAN вашего маршрутизатора, возможно, в 192.168.1.15), и маршрутизатор поймет, что трафик должен взаимодействовать с использованием подсеть, которая содержит 203.0.113.5 и 203.0.113.6. Когда маршрутизатор понимает, что трафик принимается 203.0.113.6, ваш маршрутизатор может реализовать правило обработки трафика для 203.0.113.6, которое говорит, что для трафика порта TCP 80 должна применяться "трансляция сетевых адресов" (NAT). Для этого ваш маршрутизатор создает новый IP-пакет, который доставляется с 203.0.113.6 на ваш локальный веб-сервер, который может быть по адресу 192.168.1.50. Маршрутизатор понимает, что 192.168.1.50 находится в той же подсети, что и 192.168.1.15, и отправляет трафик через порт локальной сети.
Если именно так все и происходит, то у маршрутизатора никогда не будет причин отправлять трафик на 203.0.113.5, поэтому он никогда не отправляется к провайдеру.
Фактически, если провайдер получил этот трафик, он, вероятно, сказал бы: «Полученный трафик предназначен для сети этого клиента. Тем не менее, трафик пришел из сети клиента. Этот трафик был отправлен мне без необходимости. Я не хочу с этим сотрудничать. Я просто отброшу / проигнорирую трафик. "Интернет-провайдер ожидает, что если это вызовет проблемы, проблемы будут решены путем интеллектуального исправления вашей внутренней сети, чтобы он без необходимости не отправлял трафик Интернет-провайдеру.
(Это также касается понятия «компьютер -> маршрутизатор -> Интернет-провайдер -> маршрутизатор -> сервер»). Если вы хотели обратиться к одному маршрутизатору оба раза, когда вы сказали «маршрутизатор», потому что вы думали, что трафик может обернуться у провайдера, то это совершенно нежелательно и, возможно, неосуществимо из-за распространенного способа, которым провайдеры обрабатывают трафик .)
Итак, теоретически возможно ли «сервер -> маршрутизатор -> сервер»? Да. Однако не все устройства обязательно будут поддерживать NAT или поддерживать их одинаково. Некоторые устройства могут быть спроектированы так, чтобы поддерживать NAT только в определенной точке процесса обработки трафика, и это может произойти до того, как трафик переключит подсети с адресов «192.168.1» на адреса «203.0.113». Так что в некоторых случаях это может не сработать. Как объяснено в последнем параграфе, решение состоит не в том, чтобы пытаться получить трафик, отправленный провайдеру. (Решение состоит в том, чтобы не отправлять трафик на IP-адрес порта WAN маршрутизатора. Вы могли бы легко избежать этого, влияя на работу "разрешения имен".)
Это просто вопрос того, нужно ли мне иметь два псевдонима для подключения по ssh к моему домашнему серверу (sshmyserverlocal или sshmyserverremote), поэтому у меня будет самое быстрое соединение, если оно локальное, или если DNS позаботится об этом для меня.
Вы хотите, чтобы об этом позаботились, используя "разрешение имен" или IP-маршрутизацию или оба. Если у вас есть несколько имен, и вы в конечном итоге используете неправильное имя, то иногда такая деталь вообще не будет иметь значения, а иногда - и так. Например, команда "ping" использует ICMP и, вероятно, не будет затронута. Однако, если вы использовали HTTPS (вместо SSH), то имена хостов могут иметь гораздо большее значение. Что касается SSH (который был упомянут в примере), это, вероятно, не будет иметь большого значения, хотя, по крайней мере, некоторые версии sshd используют Reverse DNS, и поэтому у вас могут быть задержки, если что-то не так, как ожидалось.
Для вашего собственного спокойствия и, возможно, для надлежащей технической функциональности, вы всегда будете использовать правильное имя хоста. Например, SSL-сертификат веб-сервера должен иметь имя, совпадающее с тем, что введено в веб-браузер. Простой способ заставить все это работать, избегая связанных с этим проблем, состоит в том, чтобы просто иметь одно имя хоста (даже если у него несколько IP-адресов, благодаря использованию "файла хостов" или разделенной DNS).
