Скажіть, у мене є доменне ім’я, яке вказує на мою IP-адресу. У мене є маршрутизатор, який обробляє переадресацію портів на сервер у своїй вітальні. Якщо я, наприклад, введу домен у веб-переглядачі, він врешті-решт вкаже на "себе".

Отже, поширення було б:

сервер -> маршрутизатор -> провайдер -> (спагеті DNS) -> провайдер -> маршрутизатор -> сервер

але як тільки він знає IP-адресу (і вона зберігається в кешованому режимі), швидше за все, "система в цілому" встановлена, щоб знати, що вона може мати коротке замикання на:

сервер -> маршрутизатор -> сервер?

або навіть

server -> сервер (через "localhost" чи що завгодно?)

що робити, якщо за маршрутизатором у мене інший комп'ютер? якщо я SSH на сервер (за його доменним іменем) - це кожен натискання клавіші, яке розповсюджується як

комп'ютер -> маршрутизатор -> провайдер -> маршрутизатор -> сервер?

або це досить розумно, щоб просто піти

комп'ютер -> маршрутизатор -> сервер?

Це лише питання про те, чи повинен я мати два псевдоніми для ssh-ing на своєму домашньому сервері (sshmyserverlocal або sshmyserverremote), тож у мене буде якнайшвидше підключення, якщо локальне, або якщо DNS піклується про це для мене.

DNS і маршрутизація - це абсолютно окремі системи. Адреса, повернута вашим запитом DNS, просто призначається в якості місця призначення, коли ваша клієнтська система ініціює з'єднання з сервером. Маршрут, який буде проходити пакет, щоб дістатися до сервера, абсолютно не залежить від цього процесу. Ці системи є окремими за конструкцією, тому процес маршрутизації повинен завжди повертати найшвидший можливий маршрут до місця призначення, незалежно від того, як поводиться DNS.

@ D34DM347 вірно, DNS зазвичай не бере участь у рішеннях маршрутизації IP-пакетів.

Однак є одне невелике виняток (де може виникнути плутанина) деяких великих DNS-серверів, наданих мережами розподілу вмісту (CDN), які мають однакові сервери по всьому світу, подивіться, звідки надходив запит, і змініть відповідь виходячи з цього. Якщо ви приїжджаєте з французької IP-адреси, Akamai подасть вам відповідь, яка вказує, наприклад, на один із їхніх однакових комп'ютерів у Франції. Дивіться цю публікацію в блозі . Тут може лежати ваша плутанина, і чому ви, можливо, обґрунтовано очікували, що DNS допоможе в маршрутизації.

Що стосується маршрутизації, то деякі пристрої пропонують NAT Loopback, де вони розумно розраховують, що адреса, яку ви намагаєтеся отримати, насправді локальна, і тому не надсилайте ці пакети за межі зовнішньої мережі .. але це буде залежно від пристрою маршрутизатора.

Вам або доведеться вказати на більш локальну IP-адресу або заплутатися з таблицями маршрутизації IP .., що виходить за рамки вашого питання "Чи достатньо розумний DNS для маршрутування ..."

DNS-запит для IP-адреси, що відповідає доменному імені, перейде на той сервер імен, який ви налаштували на пристрої, де ви робите запит домену. Найчастіше це DNS-сервер вашого провайдера.

Потім IP-пакети від клієнта до сервера пройдуть через маршрутизатор, де налаштовано переадресацію портів.

Якщо ви налаштуєте внутрішній сервер імен, який повертає приватну IP-адресу сервера для запиту доменного імені, то трафік буде прямувати від клієнта до сервера за умови, що вони розташовані в одній підмережі.

Відповідь на ваше запитання залежатиме від того, що саме ви маєте на увазі, коли ви говорите "роутер".

Багато кінцевих користувачів використовують маршрутизатор слів для опису пристрою, основною функцією якого є виконання NAT ( Network Address Translation ). Однак маршрутизатори, які складають основу мережі Інтернет, рідко налаштовані на виконання NAT. Ці основні маршрутизатори базуються на мікросхемах, розроблених для ефективної маршрутизації в апаратному забезпеченні, і не багато іншого.

Ці відмінності настільки значні, що я відповім на ваше питання окремо у кожному з двох сценаріїв.

Використання NAT-пристрою між сервером та провайдером

У цьому прикладі я припускаю, що ваш сервер має IP-адресу 10.0.0.2, а ваш NAT-пристрій має IP-адресу 192.0.2.42.

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

Щоб підтримувати з'єднання з Інтернету до вашого сервера, ви налаштували переадресацію порту на вашому пристрої NAT. Це переадресація порту - це те, що дозволяє пристрою NAT знати, яку адресу призначення замінити 192.0.2.42, коли він бачить перший пакет, який встановлює нове з'єднання. Після встановлення з'єднання NAT пристрій здійснить той же переклад, що і в попередньому випадку.

Для того, щоб усе це працювало, ваше доменне ім’я доведеться дозволити до 192.0.2.42. Але це означає, що коли сам сервер вирішить доменне ім'я, він також отримає 192.0.2.42.

Коли сервер хоче підключитися до 192.0.2.42, він знайде цю адресу поза локальною мережею, оскільки локальна мережа охоплює лише 10.0.0.0/24. Таким чином, він відправить пакет на свій шлюз за замовчуванням, який був би LAN інтерфейсом пристрою NAT.

Поки NAT-пристрій досить розумний, щоб NAT один і той же пакет був двічі, він перевернеться і повернеться на ваш сервер, спочатку змінивши IP-адресу джерела з 10.0.0.2 на 192.0.2.42, а потім змінивши IP-адресу призначення з 192.0 .2.42 до 10.0.0.2. Повернення трафіку буде проходити через той же процес перекладу.

У цьому випадку відповідь буде в тому, що трафік прямує від сервера до пристрою NAT, а потім назад до сервера.

Якщо ваш NAT-пристрій трохи менш розумний, трафік може йти аж до провайдера, перш ніж він обернеться. Або NAT-пристрій може NAT пакет лише один раз і надішле пакет з вихідною адресою та адресою призначення 10.0.0.2 назад на ваш сервер, який ваш сервер мовчки скине.

Якщо у вас є власний DNS-сервер (можливо, розміщений на пристрої NAT), ви можете робити хитрощі, створюючи різні відповіді на запити в локальній мережі, з відповідей на ці запити в Інтернеті.

Тож навіть незважаючи на те, що фактична IP-адреса вашого домену становить 192.0.2.42 клієнтів у локальній мережі, сказали б, що це 10.0.0.2.

Однак цей підхід не може бути повністю автоматизованим. Уявіть, що ви переслали порт 80 на 192.0.2.42 на порт 80 на 10.0.0.2 і порт 22 на 192.0.2.42 на порт 22 на 10.0.0.3. І NAT-пристрій бачить відповідь DNS з IP-адресою 192.0.2.42. На яку IP-адресу слід замінити 192.0.2.42, перш ніж передати її клієнту в локальній мережі? Він ще не знає, чи збирається цей клієнт підключитися до порту 22 або порту 80, тому він не може знати, яку IP-адресу повернути клієнту.

Це означає, що такий DNS-горизонт розділеного горизонту завжди потребуватиме певної кількості ручної конфігурації. І це може стати безладом.

Використання маршрутизатора між сервером та провайдером

Для цього прикладу я припускаю, що ваш сервер має IP-адресу 203.0.113.2, а ваш маршрутизатор має зовнішню IP-адресу 192.0.2.42.

Коли ваш сервер підключиться до інших серверів в Інтернеті, ваш маршрутизатор буде пересилати пакет без змін, крім зниження TTL. Віддалений сервер побачить пакети, що походять з 203.0.113.2, а ваш Інтернет-провайдер матиме таблицю маршрутизації, в якій сказано, що всі пакети до 203.0.113.0/29 повинні бути переведені через 192.0.2.42, саме тому повернення трафіку повертається на ваш сервер .

У DNS IP-адреса, призначена вашому серверу, буде 203.0.113.2. І обидва клієнти у вашій локальній мережі та в Інтернеті побачать цю адресу. Клієнти в локальній мережі визнають, що 203.0.113.2 - це локальна адреса та надсилають пакети безпосередньо на сервер, не обходячи маршрутизатор. З'єднання від самого сервера навіть не дотягнуться до мережевого інтерфейсу, оскільки стек IP на сервері визнає, що адреса призначення є локальною для самого сервера.

Якщо ви хочете підключитися зовні до порту 80 на одному сервері з IP-адресою 203.0.113.2 та портом 22 на іншому сервері з IP-адресою 203.0.113.3, ви просто зробите це. Не потрібен переклад, а трафік ззовні прямо вказує, якій IP-адресі призначено.

Ваш маршрутизатор може мати функцію брандмауера таким чином, що вам доведеться налаштувати відкриті порти, перш ніж дозволено з'єднання, розпочате з Інтернету до вашої локальної мережі. Але не потрібен переклад, це означає, що він буде швидшим та надійнішим.

Навіщо навіть використовувати NAT?

З різниці між цими двома сценаріями ми бачимо, що уникнення NAT є найбільш ефективним із двох методів. Причиною використання NAT є зменшення кількості необхідних IP-адрес.

У першому прикладі вам було б призначено лише 1 IP-адресу від вашого провайдера. У другому прикладі вам було б виділено 9 IP-адрес. І це найменша кількість IP-адрес, які провайдер може уникнути, передаючи вам, не вимагаючи жодних злому.

Якщо наш Інтернет-провайдер має сучасну мережу з підтримкою як IPv4, так і IPv6, то речі могли б виглядати краще. У цьому випадку можна використовувати NAT лише для IPv4 та маршрутизації для IPv6.

Ваш сервер може мати IP-адреси 10.0.0.2 та 2001: db8: 42: cafe :: 2, ваш NAT / роутер може мати IP-адреси 192.0.2.42 та 2001: db8: 42 :: 2. У цьому випадку ваш домен мав би IP-адреси 192.0.2.42 та 2001: db8: 42: cafe :: 2.

Зауважте, що домен вирішує IPv4-адресу маршрутизатора та IPv6-адресу сервера.

Підключення від Інтернету до сервера будуть проходити через маршрутизатор незалежно від того, використовує клієнт IPv4 або IPv6. Підключення від сервера до самого себе можуть спробувати паралельно IPv4 та IPv6 і використовувати найшвидший, який буде IPv6, оскільки для з'єднання IPv4 доведеться проїхати через NAT / маршрутизатор.

Коротка відповідь

Однак ви можете використовувати 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. (Можуть бути й інші кроки, наприклад, перевірка локального кешу "Resolver" перед тим, як виконати будь-яку з цих речей, а потім, якщо використовується DNS, зберігання результатів у кеш "Resoluver", щоб прискорити роботу наступного разу. ) Ваш клієнт SSH робить це перед тим, як спробувати зв’язатися з віддаленою машиною. Потім, після того, як процес "вирішення імені" буде використаний для генерування IP-адреси, клієнт SSH здійснить з'єднання SSH, використовуючи IP-адресу, яка була результатом пошуку "роздільної здатності імені". Тож спосіб обробки трафіку залежатиме від IP-адреси, а не від того, чи введено ви доменне ім’я.

Основна загальна робота DNS - це, по суті, лише допомога в процесі "вирішення імені" перетворити ім'я в IP-адресу. Те, як рухається трафік по всій системі, - це концепція, яку найчастіше називають "маршрутизацією", і якою керують різні програми / конфігурації, ніж "роздільна здатність імені". Тож люди, які добре розуміють цей матеріал, спробують відповісти на ваші запитання, пов’язані з DNS, окремо від питань, пов’язаних із вашим маршрутизатором, адже це дійсно окремі технології, розроблені для окремих цілей, а речі найпростіші, якщо ви спробуєте подумати над тим, як вони були розроблений. В голові тримайте окремо DNS та маршрутизацію.

Це завершує моє висвітлення теми DNS. Тепер дозвольте мені вирішити інший великий фокус вашого питання, який полягає в тому, як трафік направляється.

Маршрутизація

server -> сервер

Це також може бути варіантом. Коли комп'ютер намагається надсилати мережевий трафік, частиною процесу є створення належного кадру "Шар 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", і ці порти трактуються як єдине "посилання", тому маршрутизатор буде діяти як комутатор для цих пристроїв. У такому випадку маршрутизатор відправлятиме трафік з одного або декількох портів, які обробляються як комутатор.

Для того, щоб трафік переходив з внутрішнього порту локальної мережі до провайдера, маршрутизатор повинен відправляти трафік з мережевого порту, який повідомляє провайдеру. Ваша типова домашня мережа, ймовірно, не зробить цього, якщо IP адреса призначення є однією з "приватних" адрес, таких як адреси IPv4, зазначені в IETF BCP 5 (більш відомий як RFC 1918). Крім того, більшість провайдерів просто заблокує трафік IETF BCP 5 на виду (і не передасть цей трафік вам назад). Отже, ця налаштування (сервер -> маршрутизатор -> сервер) швидше є тим, що відбувається насправді, а не складнішим процесом із залученням провайдера.

Якщо інформація проходить через маршрутизатор, але ви просто використовуєте IETF BCP5 адреси у внутрішніх портах локальної мережі, я зазвичай не посилаюся на це як на залучення маршрутизатора. Натомість маршрутизатор обробляє трафік так само, як "комутатор", просто використовуючи адреси MAC-48 для прийняття рішень, пов'язаних з потоком трафіку.

Можлива інша установка, яка полягає в тому, що ви можете використовувати WAN-адресу. У цьому випадку використовується кілька підмереж, і тому пристрій діє як маршрутизатор. Це стає складнішим, але, оскільки це може бути можливим, що все може працювати, варто тут висвітлитись. Я надам приклад того, як це може успішно працювати. Цей наступний параграф містить кілька IP-адрес. Щоб зберегти ці адреси прямо, головна деталь, яку слід відстежувати, полягає в тому, що адреси, що починаються з "192.168.1", призначені для IP-адрес у локальній мережі, тоді як адреси, що починаються з "203.0.113", є адресами для підключення до WAN. (де маршрутизатор підключається до провайдера).

Що може статися, це те, що пристрій шлюзу в ISP може мати шлюзовий пристрій, використовуючи адресу, наприклад 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, яке говорить, що для трафіку порту 80 TCP повинен бути застосований "трансляція мережевих адрес" (NAT). Для цього ваш маршрутизатор створює новий IP-пакет, який доставляється з 203.0.113.6 на ваш локальний веб-сервер, що може бути в 192.168.1.50. Маршрутизатор розуміє, що 192.168.1.50 знаходиться в тій же підмережі, що і 192.168.1.15, і відправляє трафік з локального порту LAN.

Якщо так відбувається все, то маршрутизатор ніколи не буде причин відправляти трафік на 203.0.113.5, тому він ніколи не переходить до провайдера.

Насправді, якщо провайдер отримав цей трафік, провайдер, ймовірно, сказав би: "Отриманий трафік призначений для мережі цього клієнта. Однак трафік надходить із мережі клієнта. Цей трафік мені надсилався без потреби. Я не хочу співпрацюйте з цим. Я просто скину / ігнорую трафік ". Інтернет-провайдер очікує, що якщо це спричинить проблеми, проблеми будуть вирішені розумним шляхом фіксації вашої внутрішньої мережі, щоб вона не надмірно відправляла трафік до провайдера.

(Це також стосується поняття "комп'ютер -> маршрутизатор -> ISP -> маршрутизатор -> сервер". Якщо ви мали намір посилатися на один маршрутизатор обидва рази, коли ви говорили "маршрутизатор", тому що ви думали, що трафік може обернутися у провайдера, то це дуже небажано і цілком можливо неможливо через загальний спосіб, яким провайдери звертаються з трафіком.)

Отже, чи теоретично можливий «сервер -> маршрутизатор -> сервер»? Так. Однак не всі пристрої обов'язково підтримують NAT або підтримують їх однаково. Деякі пристрої можуть бути розроблені таким чином, щоб підтримувати NAT лише в певній точці процесу обробки трафіку, і це може бути раніше, ніж трафік перемикає підмережі з адрес "192.168.1" на адреси "203.0.113". Так, у деяких випадках це може не спрацювати. Як пояснено в останньому абзаці, рішення не полягає в тому, щоб не намагатися надсилати трафік до провайдера. (Рішення полягає в тому, щоб не надсилати трафік до IP-адреси на порту WAN маршрутизатора. Ви можете найбільш уникнути цього, впливаючи на те, як працює "роздільна здатність імені".)

Це лише питання про те, чи повинен я мати два псевдоніми для ssh-ing на своєму домашньому сервері (sshmyserverlocal або sshmyserverremote), тож у мене буде якнайшвидше підключення, якщо локальне, або якщо DNS піклується про це для мене.

Ви хочете, щоб це вирішили, використовуючи "дозвіл на ім'я" або маршрутизацію IP або те і інше. Якщо у вас є кілька імен, і ви в кінцевому підсумку використовуєте неправильне ім’я, то іноді така деталь взагалі не має значення, а іноді вони будуть. Наприклад, команда "ping" використовує ICMP, і, ймовірно, це не вплине. Однак якщо ви використовували HTTPS (замість SSH), то імена хостів можуть мати значення дещо більше. Що стосується SSH (про який згадувалося в прикладі), це, мабуть, мало би мало значення, хоча принаймні деякі версії sshd використовували зворотний DNS, і тому у вас можуть виникнути затримки, якщо речі не збігаються, як очікувалося.

З метою душевного спокою та можливої ​​належної технічної функціональності завжди потрібно використовувати правильне ім’я хоста. Наприклад, сертифікат SSL веб-сервера повинен мати ім’я, яке відповідає тому, що вводиться у веб-браузер. Найпростіший спосіб зробити цю роботу, уникаючи пов'язаних з цим проблем, - це просто мати одне ім’я хоста (навіть якщо воно має кілька IP-адрес, завдяки використанню "хост-файлу" або за допомогою розділеного DNS).

Ви можете налаштувати деякі DNS форвардер , такі як Unbound (я відповів не так давно тут , як це зробити) , де ви можете змінити будь-які записи публічних DNS, або простий спосіб, щоб додати в свій hostsфайл

your.tld ip.of.local.machine

але вам потрібно прокоментувати це, коли ви виходите з локальної мережі, тому деякий шанобливий брандмауер, наприклад PFsense якогось експедитора DNS, встановленого локально у вашій локальній мережі, був би набагато зручнішим способом

У вашому першому сценарії це відбувається, якщо припустити, що браузер працює на одному сервері:

1. Сервер контактів DNS-сервер за допомогою маршрутизатора для вирішення імені хоста
2. DNS-сервер відповідає IP-адресою імені хоста (що вказує на маршрутизатор)
3. IP-адреса сервера IP-адреси маршрутизатора та порту маршрутизатора направляється назад в локальну мережу

IP-адреса буде кешована протягом наступних 86 400 секунд (1 день) у Windows, тому протягом цього часу слід виконати лише крок 3 вище. Після закінчення терміну дії кеш-пам'яті він почнеться з кроку 1.

Так, так, маршрутизатор досить розумний, щоб знати, яка його власна зовнішня адреса, і не направляти вас в Інтернет, щоб знайти його. Ви перенаправлені до Інтернету лише для вирішення імені хоста, якщо воно не відомо (якщо ваш маршрутизатор не є вашим DNS, він вирішить це для вас).

Ця ж серія кроків буде застосована і до вашого сценарію SSH, хоча ви можете обійти маршрутизатор і перейти прямо від хоста до хоста, якщо ви використовуєте внутрішню адресацію за IP-адресою або додаванням у hostsфайл (це я і роблю).

В іншому, але подібному сценарії, маршрутизатор може надати ICMP перенаправлення на фактичну внутрішню адресу сервера, щоб ви обійшли маршрутизатор. Цілком ймовірно, що маршрутизатор переадресації портів зробив би це.

Вашу проблему можна вирішити шляхом маршрутизації або DNS (принаймні, з PFSense). PFSense називає це відповідно відбиттям NAT (трафік переадресації, призначений для інтерфейсу WAN до внутрішнього хоста) та розділення DNS (внутрішні та зовнішні хости вирішують адресу по-різному).
Поза визначеннями я не маю великого досвіду роботи з цими функціями, ви повинні прочитати цю статтю на вікі PFSense для отримання більш детальної інформації. Це в значній мірі залежить від постачальника, тому мало сподівань, що інші маршрутизатори, програмне забезпечення або обладнання також поводяться так само.

Найкращий варіант - налаштувати проксі-сервер DNS, який, ймовірно, вже працює на вашому маршрутизаторі. Для цього вам може знадобитися консольний доступ до маршрутизатора. Швидше за все, ваш проксі - це програмне забезпечення під назвою dnsmasq ви повинні тримати його весь час! Початкова конфігурація потребує ознайомлення з документацією, але оновлення (додавання додаткових серверів дуже просто).