Я досить новачок в мережевому адмініструванні, і тому вже радий, що успішно встановив запис 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частину в адресних рядках після переадресації.

Веб-сервери за замовчуванням слухають порт 80 TCP. Якщо ви не хочете чітко вводити номер порту в URL-адресі, у вас є кілька варіантів:

• Ви можете налаштувати свій веб-сервер для використання порта 80 замість порту 8080. Це рекомендується для таких веб-серверів, як nginx або Apache, але не для таких серверів, як Gunicorn. Цей параметр також не завжди можливий, оскільки цей порт вже може використовуватися іншим веб-сервером.

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

• Ви можете поставити зворотний проксі-сервер перед своїм веб-сервером, який приймає трафік на порту TCP 80 і надсилає його на ваш веб-сервер через порт 8080 TCP. Це також буде працювати, якщо порт 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-адрес (для зручності користувача) за допомогою " 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 у будь-якому випадку, щоб отримати оригінальний запит, inm для того, щоб відповісти на переадресацію / карту. Він також повинен слухати на порту 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 та деякі альтернативи, полягає в тому, щоб мати можливість відслідковувати окремі розмови. Це допомагає налагодити зв’язок із запущеними програмами. Отже, якщо машина отримує трафік на порту 80 TCP, машина буде знати, що мережевий трафік призначений для використання програмою, що є веб-сервером. Якщо веб-браузер одночасно завантажує декілька графічних зображень, комбінації номерів «вихідного порту» та номерів «порту призначення» можуть відслідковувати, які дані призначені для якої графіки, тому ці одночасні розмови можуть відбуватися без змішування даних.

Тепер я здогадуюсь, що у вас є доступ до DNS-сервера, і вам здається, ви думаєте, що адміністрація DNS була б зручною, щоб можна було трохи більше обробляти трафік трафіку. Але, схоже, DNS не може допомогти вам отримати номер порту. Що ти можеш зробити?

Розглянемо IPv6. IPv6 дозволяє мати більше IP-адрес. Крім того, на відміну від деяких реалізацій IPv4, пристрої, які використовують IPv6, зазвичай можуть легко підтримувати декілька активних IPv6 адрес одночасно. Отже, якщо ви хочете мати три різні мережеві протоколи на одному комп’ютері, ви можете призначити принаймні три різні адреси IPv6 одному і тому ж комп'ютеру. І тоді ви можете робити все, що вам подобається, з тими IPv6 адресами.

Тоді ви можете використовувати тип запису ресурсів AAAA, щоб призначити ім’я цій IPv6-адресі, яку ваша мережева конструкція може вважати ефективною присвяченою конкретній службі на конкретному комп'ютері, який ви хочете.

Валлах, тепер у вас DNS ефективно вказує на програмне забезпечення і досягли цієї мети, не намагаючись розраховувати на те, щоб DNS вказував на номер порту, який не працює добре просто тому, що така функціональність просто не буває звичайною підтримується.

Можливе заперечення:
І якщо ви застрягли в IPv4 і вважаєте, що IPv6 якось не підтримується, я б радив вам спробувати вирішити цю проблему. Цю проблему, ймовірно, буде легше виправити (можливо, використовуючи якусь тунель), і, ймовірно, буде кориснішим виправленням після того, як ви її реалізуєте.