🐧 Linux · 20 вопросов · ~45 мин · ⏱ Таймер 45:00 · Средний · 👥 1 прошёл

Сеть в Linux

Проверка сети — это последовательность от локального интерфейса и маршрута до DNS, прослушивающего сокета и ответа прикладного протокола. Тест предлагает читать вывод ip, ss, dig, curl и tcpdump так, чтобы не объявлять «сеть не работает» после одного неудачного ping.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. На 20 вопросов отведено 45 минут. Не меньше половины заданий требуют разобрать команды, сценарий Bash, конфигурацию или диагностический вывод. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и краткий разбор каждого решения.

Вопрос 1 из 20

Что показывает ip -br addr?

ip -br addr
lo       UNKNOWN 127.0.0.1/8 ::1/128
eth0     UP      192.0.2.10/24

Полную таблицу маршрутизации с метриками и правилами Список слушающих TCP- и UDP-сокетов с процессами Краткий список интерфейсов, их состояния и назначенных IP-адресов Таблицу соседей ARP/NDP для каждого интерфейса

Вопрос 2 из 20

Адрес 192.0.2.10/24 обращается к 192.0.2.80. Нужен ли обычный default gateway для доставки в той же сети?

Нет: шлюз не нужен лишь после появления статической ARP-записи Да: шлюз нужен, когда последний октет назначения больше исходного Да: любой пакет сначала отправляется на маршрут по умолчанию Нет: адрес назначения входит в тот же непосредственно подключённый префикс /24

Вопрос 3 из 20

Для чего полезна команда ip route get 203.0.113.8?

ip route get 203.0.113.8
203.0.113.8 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 1000

Показывает выбранный маршрут, интерфейс, шлюз и исходный адрес к цели Добавляет временный маршрут до указанного адреса Измеряет пропускную способность выбранного маршрута Проверяет, отвечает ли удалённый узел на ICMP Echo

Вопрос 4 из 20

Что означает строка default via 192.0.2.1 dev eth0 metric 100?

ip route
default via 192.0.2.1 dev eth0 metric 100
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.10

Шлюз используется только для пакетов с метрикой выше 100 Маршрут к сети 192.0.2.0/24 через интерфейс eth0 Адрес 192.0.2.1 назначен самому интерфейсу eth0 Маршрут по умолчанию через 192.0.2.1 на eth0 с метрикой 100

Вопрос 5 из 20

У хоста два default route с разными metric. Какой обычно предпочтительнее при прочих равных?

Маршрут с меньшей метрикой Последняя строка текстового вывода Маршрут с большим номером интерфейса Маршрут с более длинным именем шлюза

Вопрос 6 из 20

Почему getent hosts app.internal может дать результат, которого нет в dig app.internal?

grep '^hosts:' /etc/nsswitch.conf
getent ahosts app.internal
dig app.internal

getent запрашивает только mDNS, а dig читает /etc/hosts dig игнорирует записи, адрес которых находится в частной сети dig показывает только ответы авторитетных серверов getent учитывает NSS и /etc/hosts, а dig — DNS

Вопрос 7 из 20

Что означает DNS-ответ NXDOMAIN?

Авторитетный сервер не ответил до истечения тайм-аута Резолвер отказал в рекурсии для этого клиента Запрошенного доменного имени не существует Имя существует, но для него нет записи типа A

Вопрос 8 из 20

Чем timeout при dig отличается от NXDOMAIN?

dig @192.0.2.53 app.internal +time=2 +tries=1

Различия нет timeout — ответа нет; NXDOMAIN — имя не существует Timeout означает, что имя существует без адреса NXDOMAIN означает медленный сервер

Вопрос 9 из 20

Для чего служит TTL в DNS-ответе?

Срок, в течение которого резолвер может кэшировать эту запись Время жизни TCP-соединения с авторитетным сервером Максимальное число маршрутизаторов, которое может пройти DNS-пакет Период повторной передачи запроса при потере UDP-ответа

Вопрос 10 из 20

После исправления DNS часть клиентов при новых обращениях ещё видит старый адрес. Какая причина вероятна?

dig app.example A +noall +answer
# app.example. 300 IN A 192.0.2.20

Клиент сравнивает новый адрес со старым и выбирает меньший Кэширующий резолвер обязан хранить любую A-запись минимум сутки Авторитетный сервер ещё не применил новую зону, хотя TTL уже истёк Ранее полученная запись остаётся в кэше до истечения её TTL

Вопрос 11 из 20

Служба должна принимать TCP-соединения на 127.0.0.1:8080. Какую часть состояния подтверждает вывод ss -lntp?

sudo ss -lntp
LISTEN 0 4096 127.0.0.1:8080 0.0.0.0:* users:(("app",pid=1200,fd=7))

Удалённый клиент успешно завершает TCP-рукопожатие DNS-имя службы разрешается в 127.0.0.1 На адресе уже слушает TCP-сокет процесса app Пакеты к порту проходят через все правила брандмауэра

Вопрос 12 из 20

Служба слушает 127.0.0.1:8080. Почему с другой машины соединение не проходит?

Приложение принимает только IPv6-соединения на этом числовом порту Сокет привязан к loopback и не принимает пакеты внешнего интерфейса Серверное имя не опубликовано в DNS, хотя клиент обращается по IP Маршрут к удалённому клиенту отсутствует, поэтому SYN не попадает в LISTEN

Вопрос 13 из 20

Что означает состояние ESTAB в ss для TCP?

ss -tn state established '( sport = :443 or dport = :443 )'

Соединение установлено и может передавать данные Сокет обязательно завис Соединение уже полностью удалено Порт только ожидает входящие соединения

Вопрос 14 из 20

Почему проверка nc -zv host 53 по TCP не доказывает доступность обычных DNS-запросов по UDP?

Открытый TCP-порт означает, что то же правило firewall пропускает UDP Порт 53 используется только HTTP TCP-проверка не подтверждает доступность UDP Без ключа -u nc проверяет UDP-порт 53

Вопрос 15 из 20

Процесс слушает 0.0.0.0:8443, маршрут есть, но извне timeout. Что ещё нужно проверить?

sudo nft list ruleset
sudo tcpdump -ni any 'tcp port 8443'

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

Вопрос 16 из 20

Почему успешный ping не доказывает работу HTTPS?

Ping проверяет тот же TCP-порт, но не выполняет TLS-рукопожатие HTTPS отвечает лишь тогда, когда ICMP Echo заблокирован на сервере ICMP Echo и HTTPS используют разные протоколы, порты и правила фильтрации Успешный ICMP-ответ подтверждает только DNS и маршрут до веб-сервера

Вопрос 17 из 20

Как одним curl увидеть DNS/соединение/TLS/HTTP без загрузки тела?

curl -vI --connect-timeout 3 https://app.example/

curl --trace-time https://app.example/ openssl s_client -connect app.example:443 </dev/null curl -sS -o /dev/null https://app.example/ curl -vI --connect-timeout 3 https://app.example/

Вопрос 18 из 20

Что показывает отсутствие SYN на сервере в tcpdump во время попытки клиента?

sudo tcpdump -ni any 'tcp port 8443 and tcp[tcpflags] & tcp-syn != 0'

Приложение приняло соединение и закрыло его без HTTP-ответа SYN не дошёл до наблюдаемого интерфейса сервера Сервер получил SYN и отказал приложению в accept TLS-рукопожатие завершилось до начала захвата пакетов

Вопрос 19 из 20

Маленький ping проходит, а крупные HTTPS-ответы зависают. Что стоит проверить?

Порядок A- и AAAA-записей без проверки рабочего маршрута Число локальных соединений в TIME_WAIT на клиенте PMTU, MTU и прохождение ICMP Packet Too Big Размер TLS-сертификата и число промежуточных сертификатов

Вопрос 20 из 20

Для чего полезен tracepath target?

tracepath -n 203.0.113.8

Изменяет запись маршрута до цели на найденный кратчайший путь Измеряет пропускную способность каждого перехода без отправки нагрузки Проверяет доступность всех TCP-портов на каждом промежуточном узле Показывает маршрут и оценивает path MTU без привилегий root

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу