Модуль 0.7: Що таке мережі?

Складність: [QUICK] - Абсолютний новачок

Час на виконання: 35-45 хвилин

Передумови: Модуль 0.4: Файли та каталоги - Ви повинні впевнено виконувати команди та орієнтуватися в каталогах.

Що ви зможете зробити

Після цього модуля ви зможете:

Діагностувати базові збої підключення, розмежовуючи резолвінг DNS, доступність IP-адреси, порти та статус відповіді HTTP.
Порівнювати приватні та публічні IP-адреси та визначати, коли NAT, пересилання на маршрутизаторі або публічний endpoint мають значення.
Застосовувати перевірки в терміналі за допомогою ping, curl та nslookup, щоб зібрати дані перед внесенням змін до конфігурації.
Оцінювати, як базові концепції мереж проявляються в Kubernetes Services, Pods та API-сервері Kubernetes 1.35.

Чому це важливо

Гіпотетичний сценарій: ви щойно почали допомагати з невеликим внутрішнім застосунком, і хтось каже: “Сайт не працює”. Один колега може відкрити його зі свого ноутбука, інший бачить помилку в браузері, а третій вставляє знімок екрана, на якому лише написано, що сторінку не знайдено. Якщо всі ці повідомлення потрапляють у ту саму уявну категорію, пошук несправностей перетворюється на вгадування; якщо ж ви можете відокремити пошук імені, доступність мережі, порти Service та відповіді застосунку, той самий хаотичний звіт перетворюється на послідовність перевірок.

Kubernetes робить цю навичку ще важливішою, оскільки він запускає багато частин програмного забезпечення на багатьох машинах, а потім просить ці частини знаходити одна одну за іменем. Pod отримує IP-адресу, Service надає стабільну адресу та порт, DNS зіставляє імена із Services, а kubectl спілкується з API-сервером через захищений порт. Вам не потрібно сьогодні досконало опанувати мережу, яку використовує кластер, але вам потрібна надійна базова модель того, що означає, коли один комп’ютер спілкується з іншим.

Цей модуль надає вам таку модель, починаючи з термінала й вище. Ви дізнаєтеся, що таке мережа, чому IP-адреси не те саме, що порти, чому DNS корисний, але водночас є частою точкою збою, і як коди стану HTTP доводять, що запит досяг застосунку. Потім ви попрактикуєтеся з ping, curl та nslookup — звичайними інструментами, які використовують інженери у своїй роботі, коли дашборд перевантажений інформацією і найшвидший шлях уперед — це невеликий, ретельний тест.

Що насправді з’єднує мережа

Мережа — це два або більше комп’ютерів, з’єднаних таким чином, щоб вони могли обмінюватися інформацією. Це визначення навмисно просте, оскільки його основна ідея не є якимось спеціальним хмарним терміном; це та сама ідея, незалежно від того, чи йдеться про ваш ноутбук і принтер у домашній мережі Wi-Fi, два сервери у стійці дата-центру або тисячі контейнерів, розподілених через кластер Kubernetes. Різниця полягає в масштабі, надійності та кількості систем, що допомагають переміщувати повідомлення, а не в основній меті.

Ваш домашній Wi-Fi — це локальна мережа, яку часто називають LAN, де пристрої, що перебувають поруч, спільно використовують маршрутизатор і зазвичай можуть спілкуватися один з одним безпосередньо. Інтернет — це значно більша мережа мереж, у якій беруть участь ваш маршрутизатор, ваш інтернет-провайдер, магістральні мережі, системи доменних імен і сервери призначення. Коли ви відвідуєте google.com, ваш комп’ютер не торкається вебсайту магічним чином; він надсилає пакети через ланцюг мережевого обладнання, доки сервер не отримає запит і не надішле відповідь.

Уявіть велику мережу ресторанів із системою внутрішнього зв’язку, що з’єднує кухні. Кожна кухня — це комп’ютер, кожна кінцева точка внутрішнього зв’язку — це підключення до мережі, а проводка між локаціями — це мережа. Кухарю не потрібно знати маршрут кожного дроту, щоб запитати іншу кухню про запаси, але тому, хто відповідає за експлуатацію, потрібен достатній словниковий запас, щоб відрізнити зламаний пристрій зв’язку, неправильний внутрішній номер і кухню, яка прийняла дзвінок, але не може виконати запит.

Тип	Що це таке	Приклад
Локальна мережа (LAN)	Комп’ютери, розташовані поруч, з’єднані безпосередньо	Ваш ноутбук і принтер у домашній мережі Wi-Fi
Інтернет (WAN)	Комп’ютери будь-де у світі, з’єднані через інфраструктуру	Ваш ноутбук спілкується із сервером у Токіо

Ця відмінність має значення, оскільки команда може бути успішною в одному мережевому контексті й зазнати невдачі в іншому. Ваш ноутбук може отримати доступ до принтера вдома, оскільки обидва пристрої перебувають в одній LAN, тоді як друг на іншому кінці міста не зможе отримати доступ до того самого принтера, оскільки приватні домашні адреси не маршрутизуються через публічний інтернет. У Kubernetes такий самий патерн з’являється, коли один Pod може отримати доступ до іншого всередині кластера, але браузеру за межами кластера потрібен Service, Ingress, LoadBalancer або інший опублікований шлях.

Практична звичка з пошуку несправностей починається тут: запитайте себе, який мережевий шлях ви тестуєте. Якщо ви запускаєте команду зі свого ноутбука, ви тестуєте шлях від вашого ноутбука. Якщо Pod усередині Kubernetes не може підключитися до бази даних, успіх вашого ноутбука може не довести, що шлях для Pod працює. Саме тому інженери обережно ставляться до того, звідки вони запускають тест, оскільки джерело запиту є частиною доказів.

Laptop on Wi-Fi       Home router          Internet           Public server
192.168.1.42     ->   public gateway   ->   many networks  ->  203.0.113.55
     |                    |                                      |
local address       public address                         destination address

Діаграма залишає на видноті найважливішу ідею для початківців: в одному запиті залучено кілька адрес і систем. Ваш ноутбук може знати свою локальну адресу, ваш маршрутизатор може надавати інтернету іншу публічну адресу, а сервер призначення має власну адресу. Під час діагностування несправностей, якщо розглядати всі ці елементи просто як “IP-адресу”, це приховує точне місце, де запит зазнає невдачі.

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

Мета не полягає в тому, щоб вивчити напам’ять кожен мережевий рівень сьогодні. Мета полягає в тому, щоб перестати зводити кожну проблему зі з’єднанням до “мережа зламалася”. Щойно ви зможете описати шлях частинами, ви зможете використовувати невеликі перевірки в терміналі, щоб дізнатися, чи є причиною збою локальна адресація, трансляція імені DNS, вибір порту, поведінка брандмауера чи відповідь застосунку.

У цій моделі прихована ще одна звичка: опишіть очікуваний шлях перед тим, як запустити команду. Якщо ви очікуєте, що запит вийде з вашого ноутбука, пройде через домашній Wi-Fi, перетне публічний інтернет, перетворить ім’я на адресу і потрапить на HTTPS-сервіс, тоді кожен тест може підтвердити або поставити під сумнів одну частину цього очікування. Без цього шляху у вашій голові команди перетворюються на купу виводу замість структурованого розслідування.

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

IP-адреси: пошук правильного комп’ютера

Кожному комп’ютеру в мережі потрібна IP-адреса — це числова мітка, яка допомагає іншим системам надсилати трафік у правильне місце. Найбільш знайомою формою є IPv4, що записується як чотири числа, розділені крапками. Кожне число може бути в діапазоні від 0 до 255, тому адреса, подібна до наведеної нижче, є компактним способом ідентифікації мережевого призначення.

192.168.1.42

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

Концепція	Мережа	Реальний світ
IP-адреса	`192.168.1.42`	Вулиця Головна, 123
Що вона робить	Ідентифікує один конкретний комп’ютер	Ідентифікує одну конкретну будівлю
Хто її призначає	Ваш маршрутизатор (для локальної мережі) або ваш провайдер (для інтернету)	Міське управління архітектури

Першим сюрпризом є те, що не кожна IP-адреса призначена для всього інтернету. Приватні адреси зарезервовані для локальних мереж, і маршрутизатори не публікують їх як глобально доступні пункти призначення. Це резервування стандартизовано в RFC 1918, який визначає приватні діапазони IPv4, що їх багато домашніх мереж, офісів і дата-центрів використовують внутрішньо.

192.168.x.x    (most common for home networks)
10.x.x.x       (common in offices and data centers)
172.16-31.x.x  (less common but valid)

Приватні адреси схожі на номери квартир, які мають сенс лише всередині однієї будівлі. Якщо ви стоїте у вестибюлі, інформації “Квартира 8” може бути достатньо; якщо ви перебуваєте на іншому кінці міста — ні. Подібним чином, 192.168.1.42 може ідентифікувати ваш ноутбук усередині вашого дому, але хтось в іншій мережі не може прокласти маршрут безпосередньо до нього без публічної адреси та правила маршрутизатора, яке вирішує, куди має йти вхідний трафік.

Публічні адреси відрізняються, оскільки вони маршрутизуються в інтернеті. Ваш домашній маршрутизатор зазвичай має одну публічну адресу, призначену вашим інтернет-провайдером, тоді як пристрої за маршрутизатором використовують приватні адреси. Маршрутизатор використовує трансляцію мережевих адрес, або NAT, для відстеження вихідних з’єднань, щоб багато локальних пристроїв могли спільно використовувати одну публічну адресу без необхідності кожному пристрою мати глобально унікальну адресу IPv4.

Це одна з причин, чому фраза “на моїй машині це працює” може бути правдою і все одно не допомогти іншій людині. Сервіс, прив’язаний до приватної адреси вашого ноутбука, може працювати з іншого пристрою в тій самій мережі Wi-Fi, але він не працюватиме автоматично для колеги в іншому місці. Колезі потрібен маршрут до публічної кінцевої точки, а ваш маршрутизатор повинен знати, чи пересилати цей трафік на ваш ноутбук, що рідко є налаштуванням за замовчуванням з міркувань безпеки.

У macOS локальна адреса Wi-Fi часто доступна за допомогою ipconfig. Ім’я вашого інтерфейсу може відрізнятися, якщо ви використовуєте Ethernet, VPN або новіші налаштування мережі, але en0 є достатньо поширеним для першої перевірки на багатьох комп’ютерах Mac.

$ ipconfig getifaddr en0
192.168.1.42

У Linux hostname -I виводить IP-адреси, призначені хосту. Деякі системи показують більше ніж одну адресу, оскільки вони мають кілька інтерфейсів, VPN, мостів або контейнерних мереж. Для цього модуля для початківців зверніть увагу на те, чи міститься будь-яка з повернутих адрес у межах наведених вище приватних діапазонів.

$ hostname -I
192.168.1.42

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

$ curl -s ifconfig.me
203.0.113.55

Перш ніж запустити це, який вивід ви очікуєте: ту саму адресу 192.168..., яку ваш ноутбук використовує локально, чи іншу адресу, видиму для публічного інтернету? Більшість домашніх і офісних мереж повертають іншу публічну адресу, оскільки NAT міститься між вашою машиною та рештою інтернету. Якщо ви перебуваєте на хмарній віртуальній машині або в спеціалізованій мережі, відповідь може відрізнятися, саме тому докази перевершують припущення.

IPv6 змінює формат адреси та значно розширює доступний адресний простір, але це не скасовує необхідності в тих самих звичках міркування. Пункту призначення все ще потрібна адреса, маршрутизатори все ще переміщують трафік між мережами, і робочий локальний шлях усе ще не доводить, що працює кожен віддалений шлях. Кластери Kubernetes можуть використовувати IPv4, IPv6 або мережу з подвійним стеком, тому концепція для початківців є важливішою за один конкретний стиль адреси.

Коли пізніше ви побачите IP-адресу Pod, IP-адресу Service, IP-адресу вузла та IP-адресу зовнішнього балансувальника навантаження в Kubernetes, не ставтеся до них як до взаємозамінних. Кожна адреса відповідає на інше запитання: який екземпляр робочого навантаження, який стабільний сервіс, яка машина або яка зовнішня точка входу? Модуль 0.7 призначений для того, щоб виробити рефлекс ставити це запитання перед зміною конфігурації.

Область дії адреси також є причиною того, що в прикладах документації часто використовуються спеціальні діапазони, а не випадкові реальні адреси. Такі адреси, як 203.0.113.55 та 198.51.100.22, належать до діапазонів, зарезервованих для прикладів, тому вони безпечні для навчання, не спрямовуючи студентів на чиюсь живу систему. Коли ви пишете нотатки для себе, запозичте цю звичку: позначайте, чи є адреса приватною, публічною, лише для прикладу або внутрішньою для лабораторії, щоб майбутні читачі не переплутали заповнювач із продакшн-адресою.

У повсякденній роботі практичне питання зазвичай звучить не як “якими є всі можливі правила для IP-адрес?”. Практичне питання звучить так: “хто може прокласти маршрут до цієї адреси з того місця, де він перебуває?”. Якщо відповідь — “лише пристрої в моїй LAN”, тоді віддаленим користувачам потрібен інший шлях. Якщо відповідь — “лише Pod усередині цього кластера”, тоді зовнішнім клієнтам потрібен шаблон доступу через Service. Якщо відповідь — “будь-хто в інтернеті”, тоді засоби контролю безпеки стають такими ж важливими, як і доступність.

Порти: вибір правильного сервісу на цьому комп’ютері

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

Ця друга частина — це порт. Порт — це число від 0 до 65535, яке ідентифікує певний сервіс або кінцеву точку застосунку на машині. Якщо IP-адреса — це адреса будівлі, то порт — це номер квартири, офісного приміщення або стійки обслуговування всередині цієї будівлі.

IP Address:  192.168.1.42     = 123 Main Street
Port:        80               = Apartment 80

Full address: 192.168.1.42:80 = 123 Main Street, Apt 80

Двокрапка у 192.168.1.42:80 не є прикрасою. Вона відокремлює адресу хоста від порту сервісу, і багато інструментів використовують цю комбіновану форму, коли потрібна точність. Запит на правильну IP-адресу, але на неправильний порт, схожий на те, якби ви прибули до правильної будівлі й постукали у комірку замість служби підтримки.

Порт	Сервіс	Що він робить
80	HTTP	Звичайний вебтрафік (коли ви відвідуєте вебсайт)
443	HTTPS	Безпечний вебтрафік (замок у вашому браузері)
22	SSH	Безпечний віддалений доступ до термінала
53	DNS	Пошук доменних імен
6443	Kubernetes API	Як `kubectl` спілкується з вашим кластером

Порти також пояснюють, чому хост може бути доступним, тоді як застосунок недоступний. Машина може відповідати на базові мережеві зондування, але не мати вебсервера, який прослуховує порт 80. На іншій машині може працювати HTTPS на порту 443, тоді як SSH на порту 22 навмисно заблоковано брандмауером. Питання полягає не лише в тому, «чи можу я досягти комп’ютера?», але й у тому, «чи можу я досягти потрібного мені сервісу?».

Гіпотетичний сценарій: внутрішня інформаційна панель була перенесена на нову віртуальну машину, і хтось скопіював старе ім’я хоста, але забув, що тепер застосунок прослуховує порт 8080 за зворотним проксі-сервером. Базові перевірки за допомогою ping проходять успішно, і сервер не вимкнено, проте браузери видають помилку, коли намагаються використати стандартний шлях HTTPS. Вирішення полягає не в перезавантаженні мережі; потрібно перевірити, який процес прослуховує який порт, а потім оновити конфігурацію маршруту або проксі.

У Kubernetes порти трапляються всюди. Контейнери відкривають порти контейнерів, об’єкти Service приймають трафік на портах сервісу, Service пересилають його на цільові порти, а API-сервер зазвичай безпечно прослуховує порт 6443. Ці назви стануть зрозумілішими пізніше, але основна ідея вже закладена: Kubernetes виконує багато ретельного перетворення портів, щоб тим, хто робить запити, не потрібно було знати змінні деталі кожного контейнера.

Browser request         Kubernetes Service          Pod container
https://app.example ->  Service port 443      ->    target port 8080
      secure web              stable entry             app process

Зупиніться та подумайте: уявіть, що сервер за адресою 203.0.113.55 відповідає на ping, але curl http://203.0.113.55 завершується через тайм-аут. Який факт довів ping, а який факт залишається недоведеним? Він довів, що певний мережевий шлях до хоста відповідає на трафік ICMP. Але він не довів, що сервіс HTTP прослуховує порт 80, або що брандмауер дозволяє доступ до цього порту.

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

Для новачка експлуатаційне правило просте: називайте адресу та порт разом, коли обговорюєте мережеву залежність. Фраза «база даних доступна за адресою 10.0.5.50» є неповною, якщо застосунок очікує PostgreSQL на порту 5432. Фраза «база даних доступна за адресою 10.0.5.50:5432» дає колезі достатньо інформації, щоб протестувати той самий пункт призначення й уникнути випадкової перевірки вебпорту замість цього.

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

Kubernetes робить це конкретним за допомогою перетворення портів у Service. Service може отримувати трафік на одному порту та пересилати його на інший цільовий порт на вибраних Pod. Це не трюк; це зручність, яка дозволяє клієнтам використовувати стабільний контракт, тоді як процес застосунку прослуховує там, де йому потрібно. Компроміс полягає в тому, що фахівцям з усунення несправностей доводиться перевіряти обидві сторони цього перетворення, оскільки невідповідність може зробити Service зовні правильним, тоді як трафік потраплятиме на неправильний порт контейнера.

DNS: перетворення імен на адреси

Люди добре запам’ятовують імена на кшталт google.com, github.com та api.example.com. Комп’ютери маршрутизують трафік, використовуючи адреси, а не зручні імена, тому має бути етап трансляції між тим, що ви вводите, і тим, куди йдуть пакети. Система доменних імен, або DNS, виконує цю трансляцію, відповідаючи на такі запитання, як «яку IP-адресу мені слід використовувати для цього імені?».

You type:    google.com
DNS returns: 142.250.80.46
Your computer connects to: 142.250.80.46

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

Без DNS	З DNS
«Зателефонувати 142.250.80.46»	«Зателефонувати в Google»
Вам потрібно запам’ятовувати числа	Ви просто пам’ятаєте імена
Як у старі часи запам’ятовування телефонних номерів	Як список контактів у вашому телефоні

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

1. You type: google.com
2. Your computer asks your router: "What's the IP for google.com?"
3. Your router asks a DNS server: "What's the IP for google.com?"
4. The DNS server responds: "142.250.80.46"
5. Your computer connects to 142.250.80.46

Зазвичай це відбувається настільки швидко, що здається непомітним. Ця непомітність зручна, поки не зламається саме DNS, оскільки видимий симптом може виглядати як збій вебсайту або API. Браузер, який повідомляє, що не може знайти сервер, може означати, що застосунок не працює, але це також може означати, що ім’я просто не було перетворено на адресу.

Найкорисніше розрізнення для новачка — це відмінність між помилкою імені (name failure) та помилкою адреси (address failure). Якщо команда nslookup api.example.com каже, що ім’я не існує, ви ще не перевірили сервер; ви перевірили запис у телефонній книзі. Якщо curl http://203.0.113.100 успішно працює з відомою IP-адресою, ви маєте доказ того, що сервер і мережевий шлях можуть працювати, тоді як DNS все ще потребує ремонту.

DNS також передбачає використання кешування. Записи включають час життя (TTL), який вказує резолверам, як довго вони можуть зберігати відповідь перед повторною перевіркою. Низький TTL може полегшити заплановані міграції, оскільки клієнти оновлюватимуться швидше, тоді як високий TTL може зменшити навантаження на пошук, але спричинити затримку застарілих відповідей після зміни адреси.

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

Kubernetes інтенсивно використовує DNS всередині кластера. Об’єкти Service отримують імена, які робочі навантаження можуть використовувати замість того, щоб ганятися за окремими IP-адресами Pod, а кластерний DNS повертає поточну адресу сервісу. Ви дізнаєтесь деталі пізніше, але урок для початківців переноситься чітко: ім’я не є самим пунктом призначення; це пошук, який має дати пункт призначення.

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

Зворотна помилка також поширена: ім’я успішно перетворюється на адресу, тому хтось припускає, що DNS можна ігнорувати. Перетворення лише каже вам, що ім’я дало адресу; воно не гарантує, що адреса є актуальною, цільовою, доступною з кожного джерела або обслуговує правильний застосунок. Коли результат виглядає підозрілим, порівняйте повернуту адресу з нотатками щодо розгортання, конфігурацією балансувальника навантаження або очікуваною публічною кінцевою точкою, перш ніж рухатися далі.

HTTP-відповіді та докази в терміналі

Після того, як DNS знаходить адресу, а порт приймає з’єднання, протокол рівня застосунку все ще має відповісти. Для вебтрафіку цим протоколом є HTTP або HTTPS, і відповідь містить код стану. Код стану — це не якийсь розмитий індикатор настрою; це структурований доказ того, що саме сталося після отримання запиту сервером.

200 OK означає, що сервер отримав запит і повернув запитаний ресурс. 404 Not Found означає, що сервер був доступним, але конкретний шлях не існував. 500 Internal Server Error означає, що сервер отримав запит, але сталася помилка під час його обробки. Ці результати вказують на різних відповідальних і різні наступні перевірки, саме тому коди стану такі корисні.

Код	Значення	Аналогія
200	OK - ось те, що ви просили	«Замовлення готове! Ось ваша їжа.»
404	Not found - такої сторінки не існує	«Вибачте, у нас немає цієї страви в меню.»
500	Server error - щось зламалося з їхнього боку	«На кухні пожежа.»

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

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

1. Ви хочете надіслати листа до "Штаб-квартири Google"
   (Ви вводите google.com)

2. Ви шукаєте адресу в телефонному довіднику
   (DNS перетворює google.com -> 142.250.80.46)

3. Ви пишете адресу вулиці на конверті
   (IP-адреса: 142.250.80.46)

4. Ви пишете номер квартири/відділу
   (Порт: 443 для HTTPS)

5. Ви кладете лист у поштову скриньку
   (Ваш комп'ютер надсилає запит через мережу)

6. Google отримує його та надсилає відповідь
   (Вебсторінка повертається до вашого браузера)

Команди в цьому модулі надають вам докази на різних етапах цього ланцюжка. nslookup перевіряє, чи перетворюється назва на адресу. ping може показати, чи відповідає хост на ICMP-зонди, хоча не кожен хост їх дозволяє. curl тестує вебпротоколи та може показати заголовки відповіді, коди стану, перенаправлення та необроблений вміст.

ping надсилає невеликі діагностичні повідомлення та чекає на відповіді. Це схоже на стукіт у двері, щоб перевірити, чи хтось відгукнеться, але це не те саме, що запитувати сторінку у вебзастосунку. Багато систем навмисно ігнорують ping-трафік, тому невдалий ping — це лише підказка, а не остаточний вирок.

$ ping -c 4 google.com
PING google.com (142.250.80.46): 56 data bytes
64 bytes from 142.250.80.46: icmp_seq=0 ttl=118 time=11.4 ms
64 bytes from 142.250.80.46: icmp_seq=1 ttl=118 time=10.8 ms
64 bytes from 142.250.80.46: icmp_seq=2 ttl=118 time=11.2 ms
64 bytes from 142.250.80.46: icmp_seq=3 ttl=118 time=10.9 ms

Прапорець -c 4 означає «надіслати чотири зонди, а потім зупинитися». Без вказівки кількості ping у Linux та macOS зазвичай продовжує працювати, доки ви не натиснете Ctrl+C. Значення time=11.4 ms — це час проходження сигналу туди й назад для одного зонда, що може допомогти вам приблизно порівняти затримку, але це не слід розглядати як повноцінний тест продуктивності.

curl — це вебклієнт для вашого термінала. Він може завантажити сторінку, запитати лише заголовки, слідувати за перенаправленнями за потреби, відображати помилки та надсилати дані для тестування API. Для цього модуля ключовою ідеєю є те, що curl використовує HTTP або HTTPS, тому він може довести те, чого ping довести не може.

$ curl -s example.com

Прапорець -s означає тихий режим (silent mode), який приховує індикатор прогресу, щоб уміст сторінки було легше оглядати. Якщо запит успішний, ви можете побачити необроблений HTML замість відрендереної сторінки, яку показав би браузер. Цей необроблений вивід є корисним, оскільки він доводить, що сервер повернув контент термінальному клієнту.

<!doctype html>
<html>
<head>
    <title>Example Domain</title>
...

Отримання лише заголовків часто є зручнішим, коли вам потрібні тільки стан і метадані. Запит заголовків дозволяє уникнути виведення повної сторінки у ваш термінал, і він показує рядок стану HTTP ближче до верху. Це робить його швидкою перевіркою під час процесу усунення несправностей.

$ curl -I example.com
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
...

nslookup звертається до DNS для перетворення назви вручну. Точний вивід відрізняється залежно від операційної системи та резолвера, але форма є незмінною: ви бачите, який DNS-сервер відповів і яку адресу чи адреси він повернув. Якщо назва не працює на цьому етапі, виправте назву або DNS-запис, перш ніж звинувачувати вебзастосунок.

$ nslookup google.com
Server:    192.168.1.1
Address:   192.168.1.1#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.80.46

Ретельна перевірка зазвичай поєднує кілька команд, а не покладається лише на одну. Якщо DNS не працює, скористайтеся nslookup, щоб підтвердити проблему з назвою. Якщо DNS працює, але HTTP дає збій, використайте curl -I, щоб перевірити стан або тайм-аут. Якщо ping не проходить, але curl завершується успішно, пам’ятайте, що ICMP може бути заблоковано, тоді як звичайний вебтрафік дозволено.

Який підхід ви б обрали тут і чому: користувач повідомляє, що api.example.com не працює, але ви знаєте IP-адресу сервера із записів про розгортання. Перевірка DNS спочатку скаже вам, чи перетворюється назва на адресу; перевірка curl за відомою IP-адресою може відокремити проблему з DNS від проблеми із застосунком. Правильна послідовність залежить від симптому, але звичка залишається тією самою: ізолюйте по одному рівню за раз.

Існує корисний спосіб читати вивід команд під тиском: перекладіть його в речення, що починається словами «це доводить». Те, що nslookup повертає адресу, доводить, що резолвер має певне зіставлення для цієї назви. Відповіді ping доводять, що ICMP-трафік отримав відповіді від хоста або кінцевої точки мережі. Те, що curl -I повертає 200 OK, доводить, що HTTP-сервер успішно відповів на цей запит. Кожен доказ є вузьким, і саме в цій вузькості полягає суть.

Протилежне речення є настільки ж важливим: «це не доводить». Відповідь DNS не доводить, що вебзастосунок є справним. Відповіді ping не доводять, що HTTPS працює. Помилка 404 не доводить, що маршрутизація зламана. Помилка 500 не доводить, що клієнт ввів неправильну URL-адресу. Початківці часто хочуть отримати одну команду, яка оголосить усю систему повністю справною або несправною, але справжнє усунення несправностей — це зазвичай ланцюжок менших, чесних тверджень.

Коли ви пишете нотатку для передачі зміни, додавайте і команду, і вашу інтерпретацію. Наприклад: «nslookup api.example.com повернув 203.0.113.100, отже DNS надав адресу від резолвера мого ноутбука; curl -I до цієї назви повернув 500, отже запит досяг HTTP-сервера, який зазнав внутрішнього збою». Така нотатка набагато корисніша, ніж просто «мережу перевірено», оскільки вона дозволяє наступному інженеру побачити, які саме докази існують, а які питання залишаються відкритими.

Коли це не застосовується

Ця модель для початківців не замінює глибшої мережевої інженерії. Вона не навчить вас обчислювати підмережі, перехоплювати пакети, налаштовувати BGP-маршрутизацію, перевіряти сертифікати TLS, створювати політики service mesh або розбиратися у внутрішній роботі Kubernetes Container Network Interface. Ці теми будуть важливими пізніше, але початок з них приховав би найпоширенішу потребу початківців: вирішити, чи належить збій до пошуку назви, досяжності адреси, вибору порту або ж до відповіді застосунку.

Ця модель також не означає, що кожен інструмент є беззаперечно авторитетним у будь-якому середовищі. Корпоративні мережі, VPN, проксі-сервери, фаєрволи та хмарні балансувальники навантаження можуть навмисно змінювати те, що бачить команда. Проксі може дозволяти трафік браузера, тоді як прямі запити curl не проходять, або фаєрвол може дозволяти HTTPS, блокуючи при цьому ping. Урок полягає в тому, щоб інтерпретувати кожну команду відповідно до того, що вона насправді тестує.

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

Шаблон	Коли його використовувати	Чому це працює
Тестування з місця збою	Звіт надходить з одного ноутбука, Pod-а або сервера	Вихідний мережевий шлях є частиною помилки
Відокремлення назви від адреси	Ім’я хоста не працює або повертає неочікувану кінцеву точку	DNS може дати збій, тоді як цільовий сервер є справним
Явна вказівка порту	Сервіс доступний в одному інструменті, але не в іншому	Порти ідентифікують конкретну програму, а не лише хост
Перевага доказам перед ярликами	Хтось каже «проблема з мережею» або «сайт не працює»	Одна й та сама фраза може описувати кілька непов’язаних збоїв

Антипатерн, на який варто звернути увагу на ранньому етапі — це сприйняття успішного ping як доказу того, що застосунок є справним. Ping може показати, що один вид мережевого зонда отримав відповідь, але він не доводить, що працює HTTP, що база даних приймає з’єднання, що DNS вказує на потрібний хост, або що Kubernetes направив трафік до справних Pod-ів. Це корисний стукіт у двері, але не повна перевірка працездатності.

Ще один антипатерн — розцінювати помилку 404 як збій мережі. Помилка 404 означає, що серверу вдалося досягти, і застосунок вирішив, що запитаний шлях не існує. Це часто є проблемою маршруту, URL-адреси, розгортання або контенту. Якщо ви скажете команді мережевиків, що DNS не працює, коли сервер повертає 404, ви спрямуєте розслідування в хибному напрямку.

Для коротких модулів розділ «коли це не застосовується» є навмисно скромним, але ця звичка масштабується. Коли в наступних модулях з’являться SSH, сервери, Kubernetes Services та Ingress-контролери, ви продовжуватимете ставити ту саму послідовність запитань із ширшим контекстом. Яку назву використовував клієнт? Яку адресу дала ця назва? До якого порту була спроба підключитися? Яка відповідь протоколу повернулася? Словниковий запас розширюється, але шаблон міркувань залишається знайомим.

Коли використовувати це замість альтернатив

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

Використовуйте глибші інструменти, коли перші перевірки звужують проблему, але не пояснюють її. Перехоплення пакетів може виявити трафік низького рівня, хмарні журнали можуть показати рішення балансувальника навантаження, події Kubernetes можуть показати зміни Service та Endpoint, а журнали застосунку можуть пояснити відповіді 500. Ці інструменти є потужнішими, але вони не замінюють першого запитання: який рівень ми тестуємо просто зараз?

Ситуація	Перший інструмент	Що він може вам сказати	Кращий наступний крок за потреби
Ім’я хоста виглядає неправильним	`nslookup`	Чи повертає DNS адресу	Перевірте DNS-записи провайдера та TTL
Хост може бути недоступним	`ping -c 4`	Чи надходять відповіді ICMP	Протестуйте фактичний порт застосунку
Вебсайт або API працює неправильно	`curl -I`	Статус та заголовки HTTP	Перевірте журнали застосунку, проксі-сервера або маршрути
Локальні та публічні адреси відрізняються	`curl -s ifconfig.me`	Яку публічну адресу бачить інтернет	Перегляньте правила NAT, фаєрволу або балансувальника навантаження
Kubernetes API недоступний	Повний вивід команди `kubectl`	Чи може клієнт досягти сервера API	Перевірте кінцеву точку кластера, облікові дані та порт 6443

Для Kubernetes 1.35 і новіших версій пам’ятайте про ту саму логіку під час читання документації кластера. Назва Service залежить від DNS, порт Service залежить від відображення портів, а kubectl залежить від доступу до кінцевої точки сервера API з правильними обліковими даними. Мережеві проблеми в Kubernetes можуть стати складними, але до них все одно легше підступитися, якщо ви зберігаєте розмежування між назвою, адресою, портом та відповіддю протоколу.

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

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

Зберігайте цю систему прийняття рішень у своїх нотатках як невеликий контрольний список, а не як сценарій, якого ви повинні сліпо дотримуватися. Реальні системи іноді пропускають видимий симптом, ховаються за проксі-сервером або повертають оманливу сторінку помилки, але контрольний список усе одно допомагає вам ставити одне контрольоване запитання за раз. Саме ця дисципліна перетворює команди для початківців на професійні докази у процесі усунення несправностей.

Чи знали ви?

DNS замінив список хостів, що підтримувався вручну. До того, як DNS став стандартом у 1983 році, ранні інтернет-хости покладалися на централізовано розповсюджуваний файл HOSTS.TXT; у міру зростання мережі цей підхід з одним файлом перестав масштабуватися. DNS був представлений у 1983 році, а знайома ієрархічна структура, яку використовує більшість сучасних систем, була задокументована в 1987 році (RFC 1034).
IPv4 має близько 4,3 мільярда можливих адрес. Колись це здавалося величезною кількістю, але публічний інтернет, мобільні пристрої, хмарні платформи та постійно підключені системи зробили необхідними спільне використання адрес і впровадження IPv6.
Порти мають стандартизований реєстр. RFC 6335 описує, як управляються назви сервісів та номери портів, саме тому знайомі сервіси, такі як HTTP, HTTPS, DNS та SSH, мають загальновизнані порти за замовчуванням.
Kubernetes має власний порт API за замовчуванням. Сервер Kubernetes API зазвичай використовує безпечний порт 6443, тому міркування щодо портів для початківців застосовуються безпосередньо тоді, коли kubectl не може отримати доступ до кластера.

Типові помилки

Помилка	Чому це трапляється	Як виправити
Забули `-c` з ping	У Linux та macOS `ping` часто продовжує працювати до переривання	Використовуйте `ping -c 4 host.example` або натисніть Ctrl+C, щоб зупинити тривалу перевірку
Пінг сайту, який блокує ICMP	Багато серверів і брандмауерів відкидають діагностичний трафік ping, дозволяючи веб-трафік	Сприймайте невдалий ping як підказку, а потім перевірте справжній сервіс за допомогою `curl -I`
Плутання IP-адреси та порту	В рядках підключення вони часто містяться поруч, тому новачки подумки їх об’єднують	Вказуйте повну адресу призначення як `адреса:порт`, наприклад `192.168.1.42:80`
Сприйняття приватної IP-адреси як публічно доступної	Адреси на кшталт `192.168.x.x` працюють усередині локальної мережі, а не через інтернет	Використовуйте публічну кінцеву точку, VPN, тунель або явне переспрямування маршрутизатора, коли потрібен віддалений доступ
Забули схему URL-адреси з curl	`curl example.com` може перевіряти не той самий шлях протоколу, що й браузер, який використовує HTTPS	Вказуйте явно `curl http://example.com` або `curl https://example.com`
Припущення, що помилка DNS означає, що сервер не працює	Відсутній або застарілий запис DNS може спричинити збій до того, як трафік досягне сервера	Перевірте відому IP-адресу, коли це доречно, а потім виправте запис DNS або політику кешування
Називати кожну `404` помилкою мережі	Сервер відповів, але запитуваний шлях не знайдено	Перевірте шлях URL-адреси, конфігурацію маршрутів, deployment або логи застосунку
Зміна кількох рівнів одночасно	Тиск під час збою створює відчуття, що випадкові редагування продуктивні	Змінюйте одну річ за раз і повторно запускайте ту саму команду для збору доказів

Контрольні запитання

Запитання 1: Ваш друг каже, що адреса його нового ноутбука — `192.168.1.42`, і просить вас підключитися до нього з вашого дому. Ви пробуєте, але спроба невдала. Виходячи з наданого типу адреси, чому це не спрацювало?

192.168.1.42 — це приватна адреса IPv4, тому вона має значення лише в межах локальної мережі, де її було призначено. Ваш дім і дім вашого друга — це різні мережі, і публічний інтернет не маршрутизуватиме трафік безпосередньо на цю приватну адресу. Щоб зробити ноутбук доступним віддалено, вашому другу потрібна публічна кінцева точка, як-от VPN, тунель, хмарний хост або правило переспрямування маршрутизатора, яке спрямовує публічний трафік на ноутбук. Це діагностує проблему області видимості адреси, а не доказ того, що сам ноутбук зламаний.

Запитання 2: Ви можете успішно виконати `ping 203.0.113.55` і отримати відповіді, але під час виконання `curl http://203.0.113.55` час очікування вичерпується. На якому рівні, найімовірніше, все ще відбувається збій?

Результат ping свідчить про те, що принаймні один мережевий шлях до хоста відповідає на ICMP-трафік, але це не доводить, що вебсервіс доступний. curl http://203.0.113.55 робить спробу підключення через HTTP до порту 80, тому решта збоїв імовірно криється на рівні порту, брандмауера чи вебсервера. Хост може бути в мережі, тоді як жоден процес не прослуховує порт 80, або брандмауер може дозволяти ping, відкидаючи HTTP. Наступна перевірка повинна бути зосереджена на потрібному порту застосунку та конфігурації сервісу.

Запитання 3: Користувач не може отримати доступ до `api.example.com`. `nslookup api.example.com` каже, що ім'я неможливо розпізнати, але `curl http://203.0.113.100` повертає `200 OK`. Що слід діагностувати насамперед?

Докази насамперед вказують на розпізнавання DNS. Прямий запит за IP-адресою доводить, що сервер може відповідати через HTTP, тому застосунок і принаймні один мережевий шлях працюють. Невдалий пошук імені означає, що клієнти не можуть перетворити api.example.com на потрібну їм адресу перед підключенням. Слід перевірити запис DNS, зону DNS, останні зміни та поведінку кешування перед тим, як змінювати код застосунку.

Запитання 4: Клієнт повідомляє, що вебсайт не працює. Ви запускаєте `curl -I https://example.com` і отримуєте `500 Internal Server Error`. Чи є першим підозрюваним DNS, інтернет клієнта або шлях серверного застосунку?

Перший підозрюваний — це шлях серверного застосунку. Відповідь 500 означає, що ім’я розпізнано в DNS, мережеве з’єднання досягло сервера або шлюзу, і HTTP-запит було оброблено настільки, що сервер повернув статус помилки. Це не гарантує, що шлях кожного клієнта ідеальний, але доводить, що цей тест досяг сторони застосунку. Наступні докази слід брати з логів застосунку, перевірок висхідних залежностей або логів шлюзу, а не з записів DNS.

Запитання 5: Молодший розробник запускає `ping -c 4 api.example.com`, бачить лише вичерпання часу очікування запитів і заявляє, що сервер API повністю не працює. Ви виконуєте `curl -I https://api.example.com` і отримуєте `HTTP/1.1 200 OK`. Чому цей висновок був помилковим?

Висновок розглядав ping як повну перевірку працездатності застосунку, що не відповідає дійсності. Ping використовує ICMP, а багато продакшен-систем ігнорують або блокують ICMP, усе ще дозволяючи HTTPS на порту 443. Успішний результат curl доводить, що ім’я хоста API було розпізнано, шлях HTTPS досяг сервера, і сервер повернув успішну відповідь HTTP. Точним діагнозом є те, що трафік ping блокується або ігнорується, а не те, що API не працює.

Запитання 6: Застосунок повинен підключатися до бази даних на `10.0.5.50:5432`, але в логах зазначено `Connection refused to 10.0.5.50 on port 80`. Яка найімовірніша помилка конфігурації?

Застосунок використовує правильну адресу хоста, але неправильний порт. Порт 80 — це стандартний HTTP-порт, тоді як очікувана кінцева точка бази даних у сценарії — це порт 5432. Помилка відхиленого підключення часто означає, що пункт призначення відхилив спробу, оскільки жоден сервіс не прослуховує цей порт. Виправте рядок підключення або конфігурацію середовища, щоб застосунок націлювався на 10.0.5.50:5432.

Запитання 7: Ваша команда запустила `promo.company.com`, але `nslookup promo.company.com` повертає `NXDOMAIN`. Провідний інженер стверджує, що сервер працює на `198.51.100.22`. На яку систему потрібно звернути увагу?

Потрібно звернути увагу на записи DNS для домену. NXDOMAIN означає, що запитуваного імені не існує в DNS з точки зору резолвера, тому клієнти не можуть виявити адресу сервера за допомогою імені хоста. Сервер може бути справним за адресою 198.51.100.22, але публічне ім’я ще не має робочого зіставлення. Створіть або виправте запис DNS, а потім врахуйте час TTL і кешування резолвера.

Практична вправа: Дослідження мережі

Мета

Використовуйте мережеві команди для дослідження підключень, пошуку адрес, отримання вебконтенту та запису того, що доводить кожна команда. Сенс полягає не в тому, щоб ідеально запам’ятати вивід, оскільки мережі відрізняються. Суть у тому, щоб попрактикуватися читати кожен результат як доказ про DNS, доступність адрес, порти або поведінку HTTP-відповідей.

Налаштування

Створіть невеликий каталог для практики, щоб будь-які файли з вправи було легко знайти згодом. Наведена нижче команда — це навмисне звичайна практика використання оболонки, а не практика Kubernetes, оскільки цей модуль присвячений основам мереж у вашому терміналі.

$ mkdir -p ~/kubedojo-practice
$ cd ~/kubedojo-practice

Завдання

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

$ ping -c 4 google.com

Примітки до рішення

Зверніть увагу на рядок, який починається з PING і містить адресу в дужках, а потім подивіться на рядки відповідей зі значеннями time=. Якщо час очікування всіх перевірок вичерпується, не поспішайте робити висновок, що Google не працює; ваша мережа, резолвер DNS або політика ICMP можуть впливати на тест. Ви зберете вагоміші докази HTTP на наступному кроці.

Порівняйте затримку з іншим сервісом. Запустіть таку саму перевірку для cloudflare.com. Час відповіді може бути швидшим або повільнішим залежно від вашого місцезнаходження, маршрутизації, якості Wi-Fi і того, чи обробляють ICMP-трафік однаково обидва пункти призначення.

$ ping -c 4 cloudflare.com

Примітки до рішення

Порівняйте значення time=, але уникайте надмірної інтерпретації одного короткого зразка. Кілька відповідей ping можуть показати приблизну доступність і затримку, а не повну продуктивність застосунку. Якщо один хост відповідає, а інший ні, продовжуйте перевірки DNS і HTTP, перш ніж вирішити, чому так сталося.

Знайдіть свою локальну IP-адресу. Скористайтеся командою, що відповідає вашій операційній системі, а потім вирішіть, чи виглядає результат приватним. Приватна адреса зазвичай починається з 192.168., 10. або діапазону від 172.16 до 172.31.

На macOS спершу виконайте цю команду, якщо вашим активним мережевим інтерфейсом є звичайний інтерфейс Wi-Fi:

$ ipconfig getifaddr en0

У Linux виконайте цю команду, а потім виберіть адресу, пов’язану з вашим звичайним мережевим шляхом:

$ hostname -I

Примітки до рішення

Запишіть локальну адресу та позначте її як локальну, а не публічну. Якщо ви бачите кілька адрес, можливо, на машині є кілька мережевих інтерфейсів, VPN або контейнерна мережа. Для цієї вправи визначте адресу, пов’язану з вашим звичайним підключенням до інтернету.

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

$ curl -s ifconfig.me

Примітки до рішення

Публічний результат — це адреса, яку зовнішній сервіс бачить для вашого запиту. У багатьох мережах це адреса вашого маршрутизатора, брандмауера, VPN або гранична адреса провайдера, а не приватна адреса вашого ноутбука. Якщо значення збігається з вашою локальною адресою, можливо, ви перебуваєте в мережі, яка безпосередньо надає вашій машині публічну адресу.

Розпізнайте доменне ім’я вручну. Використовуйте nslookup, щоб знайти адресу для github.com. Знайдіть розділ із відповіддю та запишіть одну повернуту IP-адресу, знаючи, що великі сайти можуть повертати різні дійсні відповіді залежно від географії та поведінки резолвера.

$ nslookup github.com

Примітки до рішення

Важливим результатом є не конкретна адреса GitHub; це бачення того, як DNS перетворює зрозуміле людині ім’я на одну або кілька адрес. Якщо пошук не вдається, перевірте підключення до інтернету або конфігурацію резолвера, перш ніж намагатися діагностувати сам GitHub.

Отримайте вебсторінку. Використовуйте curl для запиту example.com і спостерігайте сирий HTML. Це доводить, що термінальний вебклієнт може отримувати вміст, навіть якщо він не рендерить сторінку як браузер.

$ curl -s example.com

Примітки до рішення

Ви повинні побачити HTML, який містить заголовок сторінки для Example Domain. Якщо ви бачите переспрямування, повідомлення проксі-сервера або сторінку продукту безпеки, запишіть, що повернуло ваше середовище. Доказ усе ще має значення, оскільки він описує ваш фактичний шлях.

Вивчіть заголовки відповідей сервера. Запитайте лише метадані відповіді з example.com. Подивіться на рядок статусу HTTP, а потім вирішіть, чи доводить результат, що DNS, мережевий шлях і сервіс HTTP працювали для цього запиту.

$ curl -I example.com

Примітки до рішення

Статус 200 OK означає, що запит досяг сервера, який успішно повернув запитаний ресурс. Якщо натомість ви бачите статус переспрямування, це все одно корисний доказ HTTP; це означає, що сервер відповів інструкціями щодо використання іншого розташування.

Спровокуйте певний код помилки HTTP. Запитайте заголовки для шляху, який не повинен існувати на example.com. Ваша мета — побачити, що 404 — це відповідь на рівні застосунку, а не збій DNS.

$ curl -I example.com/this-page-does-not-exist

Примітки до рішення

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

Поєднайте роботу з мережею та навички роботи з файлами. Отримайте сирий HTML example.com у тихому режимі, перенаправте його у файл під назвою my-first-webpage.html, а потім виведіть вміст файлу, щоб переконатися, що він містить тіло відповіді.

$ curl -s example.com > my-first-webpage.html
$ cat my-first-webpage.html

Примітки до рішення

Цей крок поєднує мережеве підключення в терміналі з перенаправленням у файл. Команда записує тіло відповіді HTTP у локальний файл, а cat підтверджує, що файл містить HTML. Якщо файл порожній, виконайте команду повторно без -s або перевірте статус виходу та мережеву відповідь.

Критерії успіху

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

Виконати ping вебсайту та визначити, чи містять відповіді час відгуку.
Знайти свою локальну IP-адресу та позначити її як приватну чи публічну.
Знайти свою публічну IP-адресу, як її бачить зовнішній сервіс.
Знайти доменне ім’я за допомогою nslookup та ідентифікувати повернуту адресу.
Отримати вебсторінку за допомогою curl та розпізнати сирий HTML вивід.
Розпізнати 200 OK і 404 Not Found як різні відповіді HTTP.
Зберегти вебсторінку у файл і прочитати цей файл із термінала.
Пояснити, чи перевіряла кожна команда DNS, доступність адреси, порт або поведінку HTTP.
Пояснити, як імена Kubernetes Service, IP-адреси Pod’ів і порт 6443 API-сервера зіставляються з DNS, адресою, портом і відповіддю протоколу.

Джерела

Наступний модуль

Наступний модуль: Модуль 0.8: Сервери та SSH - Дізнайтеся, що таке сервер, де розташовані сервери та як підключатися до них віддалено.