Я довольно новичок в сетевом администрировании и, следовательно, уже рад, что успешно настроил запись DNS.

Теперь я немного запутался, потому что хотел бы получить этот URL:

http://www.example.org:8080/fetch/characters/

быть на самом деле достигнуто этим

http://www.example.org/fetch/characters/

Таким образом, пользователи могут обращаться к сервису через порт 8080 без необходимости явно устанавливать порт.

Как я могу это сделать? Нужно ли какое-то специальное приложение на моем сервере? Или какие-либо вещи перенаправления, которые будут применяться к запросам?

Записи DNS не могут указывать на порты (за исключением некоторых особых случаев, которые здесь не применяются).

Если у вас есть веб-сервис, прослушивающий порт 8080 и желающий подключиться к нему без указания этого порта, у вас есть 3 варианта:

• Сделайте так, чтобы он действительно прослушивал порт 80 (или 443 с https).
• Настройте все, что уже прослушивает порт 80, для пересылки запросов в службу на порт 8080 (обратный прокси-сервер).
• Если вы можете жить с перенаправлением, используйте это вместо прокси, но тогда ваши клиенты увидят :8080часть в своих адресных строках после перенаправления.

Веб-серверы прослушивают TCP-порт 80 по умолчанию. Если вы не хотите явно указывать номер порта в URL, у вас есть несколько вариантов:

• Вы можете перенастроить свой веб-сервер так, чтобы он использовал порт 80 вместо порта 8080. Это рекомендуется для веб-серверов, таких как nginx или Apache, но не для веб-серверов, таких как Gunicorn. Эта опция также не всегда возможна, так как этот порт уже может использоваться другим веб-сервером.

  Кроме того, когда ваш сервер находится за шлюзом NAT, он не владеет общедоступным IP-адресом, и комбинация этого общедоступного адреса NAT и порта 80 уже может быть перенаправлена ​​на другой веб-сервер.

• Вы можете установить обратный прокси-сервер перед вашим веб-сервером, который принимает трафик через TCP-порт 80 и отправляет его на ваш веб-сервер через TCP-порт 8080. Это также будет работать, если порт 80 уже используется. Просто установите обратный прокси-сервер перед обоими веб-серверами, чтобы они оба прослушивали порты, отличные от 80.

Чтобы предоставить более качественную и более подробную справку о том, какой вариант может быть наилучшим, а также об ограничениях и т. Д., Мы должны знать больше о вашей настройке. Надеюсь, это объяснение уже прояснило немного.

Простой ответ, связанный с уровнем вопроса

Игнорируя экзотическое использование DNS, а также обратный поиск DNS (не имеет отношения к вопросу), почти все использование DNS имеет форму:

1. Клиент отправляет доменное имя (полностью или иначе) на DNS-сервер
2. DNS-сервер возвращает информацию о домене из своих записей. Обычно запрашиваемой ключевой информацией является либо IP-адрес для связи с сетью / электронной почтой в этом домене, либо IP-адрес другого DNS-сервера, способного предоставить эту информацию.

Как только клиент связался с сервером, сам сервер вступит во владение, и система DNS выпадает из картины.

Это означает, что системе DNS не нужно предоставлять информацию о порте, и это почти никогда не происходит. Таким образом, хотя цель вопроса верна и часто выполняется, на самом деле это не система DNS. Вот почему вы не можете решить это :)

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

Например, веб-службы HTTP обычно предоставляются на порту 80. Это означает, что как только клиент узнает IP-адрес компьютера, он может предположить, что отправка сообщения на порт 80 приведет к тому, что это сообщение будет прочитано / получено ответом веб-службы этого компьютера. Но так не должно быть. Если сервер настроен на прослушивание входящих веб-запросов через порт 9000, любой клиент, способный подключиться к порту 9000, сможет получить доступ к своей веб-службе. Если сервер находится за прокси-сервером / NAT / маршрутизатором, который перенаправляет порт 10000 на порт 9000, и клиент отправляет веб-запрос на порт 10000, сервер получит его на порт 9000 и также ответит.

Перенаправление / отображение в веб-сервере

Вы спросили о перенаправлении сопоставления или переписать в комментарии. Это функции, которые может выполнять веб-сервер. По сути, вы можете настроить веб-сервер (или большинство / множество веб-серверов) для управления обработкой URL-адреса, полученного в запросе. Таким образом, он может внутренне изменить URL-адрес при получении, чтобы различные URL-адреса обрабатывались одинаково, или исправить общие опечатки (сопоставление), или он может фактически ответить, чтобы сам клиент запросил второй раз, используя какой-то другой заменяющий URL-адрес. (перенаправление).

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

1. Я не думаю, что картирование поможет вообще . Сопоставление почти полностью встроено в веб-сервер, оно говорит: «относитесь к этому URL-адресу как к этому URL-адресу». Например, вы можете использовать сопоставление URL-адреса веб-сервера, чтобы позволить пользователю запрашивать форум, используя очень старые, старые и текущие URL-адреса (для удобства пользователей), используя " https://example.com/index.php?area-=forum&topic = 2 ", также" https://example.com/forum.php?topic=2 ", а также" https://forum.example.com?topic=2", и обработайте это только один раз, сопоставив первые два из них внутреннему третьему URL-адресу как первый шаг в обработке запроса. Поскольку эти цели влияют на путь запроса, а не на IP / порт, отображение не очень полезно для управление портами, и в вашем случае клиент вообще никогда не запрашивает 8080.
2. Перенаправление будет работать, но может быть не то, что вы хотите . Перенаправление на веб-сервере зависит от того, получает ли веб-сервер запрос (поскольку это внутренние функции веб-сервера). Таким образом, веб-сервер должен все равно прослушивать порт 80, чтобы получить исходный запрос, чтобы ответить перенаправлением / картой. Он также должен прослушивать порт 8080. Функционально для этого потребуется правило перенаправления, чтобы сообщить клиенту, запрашивающему порт 80, запросить его снова, используя URL-адрес «: 8080», который не похож на то, что вы хотите делать. Пользователь также увидит новый URL с ": 8080", в то время как кажется, что вы хотите, чтобы он был "прозрачным" и не отображался.
3. Также перенаправление будет работать только для перенаправления стандартного порта (80 или 443) - вы не можете перенаправить порт с 2000 на 8080, скажем, потому что клиент не будет запрашивать 2000 по умолчанию, во-первых, поэтому он никогда не будет получить доступ к веб-серверу, даже если он слушал 2000. Это не может быть проблемой для вас.

Однако, если вы хотите «интеллектуальное» перенаправление, когда только определенные запросы перенаправляются на 8080, это может быть путь, потому что перенаправление может включать логику, чтобы решить, какие URL следует перенаправить, тогда как сопоставление портов (ниже) будет отображать все .

Как правильно это сделать

Ответ на ваш вопрос: вы хотите, чтобы веб-сервер отвечал на веб-запросы, которые клиент отправляет на порт по умолчанию (80/443), но которые сервер фактически получает на порт 8080.

Это означает, что, как вы можете видеть, вам нужно что-то промежуточное, что сопоставляет порты между клиентом и сервером . Таким образом, клиент отправляет через порт 80 (порт по умолчанию, используемый веб-браузерами), но на самом деле он принимается веб-сервером через порт 8080. Конечно, вам придется настроить веб-сервер для прослушивания через порт 8080, поскольку это не является стандартным, но это легко, и любой веб-сервер должен иметь возможность указывать свои порты прослушивания.

Самый обычный способ сделать это - в маршрутизаторе / брандмауэре через сопоставление портов.

Говоря простым языком, для этого маршрутизатору дается правило, согласно которому все полученное сообщение, имеющее IP-адрес назначения и порт назначения = 80, должно передаваться в ЛВС, а порт назначения был изменен на 8080. Ни веб-сервер, ни клиент не будут знать об этом изменении (оно на 100% обрабатывается маршрутизатором), поэтому оно будет на 100% прозрачным для них обоих. У клиента не будет ": 8080" в его URL, и ему не нужно будет ничего перенаправлять, поскольку он запрашивает порт 80, а веб-сервер может игнорировать порт 80 и прослушивать только 8080, поскольку он никогда не получает запросы на порт 80 ,

Если вы хотите простой, простой способ, подобный тому, что делал бы «DNS для портов», это, вероятно, самый близкий эквивалент тому, что вы запрашиваете в своем вопросе.

Ты не можешь

Я имею в виду, технически это можно сделать. DNS известен тем, что может предоставить доменное имя и получить IP-адрес. Однако я немного изучил протокол DNS, и на самом деле DNS технически способен выступать в качестве механизма запроса / ответа для гораздо большего, чем просто доменные имена и IP-адреса. Один из возможных подходов заключается в использовании записи ресурса DNS, которая не является типичным типом A или AAAA, такой как запись TXT (которая технически является просто текстом и может использоваться для чего угодно), или, возможно, запись SRV или любая другая новый тип записи ресурса вы выбираете.

Если вы создаете свое собственное программное обеспечение (как клиентское, так и серверное), то, возможно, нет технических причин не делать этого, за исключением того, что вы знаете, что некоторые люди используют DNS-хостинговые компании и ограничивают их использованием только определенных типов записей. Это прискорбно, поскольку люди, которые управляют своими собственными DNS-серверами, безусловно, обладают достаточной гибкостью для таких вещей.

Однако, если вы не создаете свой собственный сетевой протокол (например, если вы хотите использовать HTTP), вы, вероятно, столкнетесь с серьезной проблемой, заключающейся в том, что существующее программное обеспечение не будет использовать ваше собственное решение, если вы не используете решения, которые уже установлены. Это будет барьером. Не техническая невозможность. Социальный барьер: можете ли вы убедить всех поступить по-своему?

Теперь, когда я объяснил, почему вы не можете сделать это, у меня может быть решение для того, что вы ищете. Во-первых, давайте посмотрим, почему у нас даже есть IP-адреса и порты.

IP-адреса и порты делают разные вещи. Назначение IP-адреса состоит в том, чтобы выполнить цели Уровней 2 и 3 Модели OSI сетевых коммуникаций. Назначение IP-адреса состоит в том, чтобы определить, на какой компьютер должен идти трафик. Тот факт, что мы могли бы использовать номер порта для этой цели, заставляя брандмауэры / маршрутизаторы исследовать номера портов для выполнения NAPT (трансляция на основе порта сетевого адреса, также иногда называемая PNAT или просто NAT), является более новой техникой, которая использует ресурс (информация), но не был частью оригинального дизайна. Если мы на минуту отойдем от этого «злоупотребления» номерами портов и рассмотрим оригинальный дизайн, возможно, нам удастся найти более простое решение. По замыслу Интернета, машины должны были быть найдены с использованием IP-адресов.

Смысл «номера порта», используемого TCP и UDP и некоторыми альтернативами, заключается в возможности отслеживать отдельные разговоры. Это помогает выстроить связь с запущенными программами. Таким образом, если машина получает трафик через порт TCP 80, она будет знать, что сетевой трафик предназначен для использования программой, которая является веб-сервером. Если веб-браузер загружает несколько графических изображений одновременно, комбинации номеров «исходного порта» и «номера порта назначения» могут отслеживать, какие данные предназначены для какого графического объекта, поэтому эти одновременные разговоры могут происходить без смешения данных.

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

Рассмотрим IPv6. IPv6 позволяет вам иметь больше IP-адресов. Кроме того, в отличие от некоторых реализаций IPv4, устройства, использующие IPv6, обычно могут легко поддерживать несколько активных адресов IPv6 одновременно. Итак, если вы хотите иметь три разных сетевых протокола на одном компьютере, вы можете назначить как минимум три разных адреса IPv6 одному и тому же компьютеру. И тогда вы можете делать все, что вам угодно, с этими IPv6-адресами.

Затем вы можете использовать тип записи ресурса AAAA, чтобы назначить имя этому IPv6-адресу, который ваш сетевой дизайн может рассматривать как эффективно выделенный для конкретной службы на конкретном компьютере, который вы хотите.

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

Возможное возражение:
если вы чувствуете, что IPv4 застряли и считаете, что IPv6 каким-то образом не поддерживается, я бы посоветовал вам попытаться решить эту проблему. Эту проблему, вероятно, будет легче решить (возможно, с использованием какого-либо туннелирования), и, возможно, она станет более полезным решением после ее реализации.