Введение
В Lantern Festival уже подготовлен прямой маршрут от Main Stage к Workshop, но ответ не может вернуться. Вы понаблюдаете за настоящими пакетами установления соединения и исправите обратный путь, сохранив существующие службы.
Сначала выполните «Получить доступ к другой зоне фестиваля» или освойте её процедуру запросов маршрутизации, добавления, замены и восстановления ограниченных маршрутов. Вы должны распознавать IPv4-адреса, простой диапазон /24, роли клиента и сервера и порты, уметь вводить команды и смотреть адреса через ip addr. Подготовленные узлы Linux используют общее ядро: это сетевые пространства имён, а не отдельные физические машины. Программирование, межсетевые экраны, динамическая маршрутизация и вычисление подсетей не требуются.
Используйте Area Plan для настоящих запросов программ, Area A и Area B для их клиентов, а West Router и East Router для изменения маршрутов. Каждый терминал сохраняет свой каталог и сетевое состояние. Открытие вкладки не сбрасывает прогресс. Эта работа начинается независимо. Время оценено автором с учётом чтения и обычных ошибок; исследования времени выполнения начинающими не проводилось.
Восстановить обратный путь и сохранить сеть фестиваля
В этом шаге вы понаблюдаете за обоими направлениями соединения до изменения маршрута. В этой независимой среде путь West Router к Workshop уже подготовлен. Начните в Area Plan: запросите Main Stage из Area A и Workshop из Area B. Обе локальные программы работают. Запросите также Broadcast Room из Area A. Workshop из Area A всё ещё недоступен.
TCP (протокол управления передачей) устанавливает соединение до данного обмена HTTP. Клиент выбирает временный порт источника, называемый эфемерным; ответ меняет местами адреса и порты источника и назначения. TCP-соединение начинается с клиентского SYN; сервер отвечает SYN-ACK до передачи HTTP. SYN в сети сервера не доказывает, что запрос HTTP дошёл до службы. Вы посмотрите на реальный ограниченный трафик двух маршрутизаторов.
Переключитесь на West Router. tcpdump наблюдает пакеты; -n оставляет числовые адреса, -i any следит за интерфейсами этого узла, а -c 8 останавливает сбор после максимум восьми подходящих пакетов. Фильтр в кавычках выбирает TCP-порт 8080. timeout 120 также завершает через две минуты, если восемь пакетов не пришли. Это ограничивает сбор, а не создаёт трафик. Строки пакетов могут появиться только после остановки. Дождитесь сообщения запуска перед сменой вкладки, затем читайте собранные строки после завершения.
timeout 120 tcpdump -ni any -c 8 'tcp port 8080'
Дождитесь listening on any, переключитесь на East Router и запустите такое же ограниченное наблюдение:
timeout 120 tcpdump -ni any -c 8 'tcp port 8080'
После listening on any переключитесь на Area A и отправьте один запрос. Ожидается тайм-аут через три секунды:
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
echo $?
Ожидайте 28. После неудачного запроса переключитесь на East Router. Если наблюдатель ещё работает, нажмите Ctrl+C, чтобы остановить его и вывести накопленные строки. Если приглашение уже вернулось, оставьте его остановленным. В любом случае немедленно, до другой команды, выведите код завершения:
echo $?
124 означает завершение по намеренной двухминутной границе. 0 может означать достижение числа пакетов или нормальную обработку Ctrl+C; прерванная программа-обёртка может сообщить 130. Доказательством служат строки пакетов, а не только код наблюдателя. Повторите оба ограниченных захвата и запрос, если окно закончилось до запроса или пакетов не было. Две минуты дают время переключиться между вкладками; это не измеренная гарантия для начинающих.
Найдите источник 10.71.0.10 к 10.72.0.10.8080 с Flags [S], входящий через transit и выходящий через lan. Ответ меняет адреса местами: 10.72.0.10.8080 к 10.71.0.10, с Flags [S.], входящий через lan. Рабочего дальнейшего пути у него нет. Переключитесь на West Router, остановите его наблюдатель через Ctrl+C, если он ещё работает, и также прочитайте код:
echo $?
West видит исходящие SYN к Workshop, но не возвращающиеся SYN-ACK. Точные времена, эфемерные порты и число повторных передач меняются. Данные сужают причину до обратного пути; это не захват завершённого HTTP-обмена.
Добавить обратный маршрут
Здесь вы дадите назначению ответа собственный путь. Начните в East Router. Прочитайте таблицу и запросите адрес исходного клиента:
ip route
ip route get 10.71.0.10
Ожидайте RTNETLINK answers: No route to host. East Router подключён к 10.72.0.0/24 и транзитной сети 172.22.0.0/24, но ответ направляется в 10.71.0.0/24. Следующим узлом должен быть соседний West Router, 172.22.0.1, а не удалённый клиент.
Используйте тот же синтаксис ограниченного маршрута из предыдущей работы:
ip route add 10.71.0.0/24 via 172.22.0.1 dev transit
ip route get 10.71.0.10
Ожидайте via 172.22.0.1 dev transit. Переключитесь на Area A и повторите рабочий запрос:
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
Прочитайте полную программу Workshop и Request received from: 10.71.0.10. Теперь успех включает установление соединения, HTTP-запрос и HTTP-ответ. Источником остаётся адрес Area A; преобразование адресов или прокси скрыли бы отсутствующий обратный путь вместо его исправления.
Если маршрут уже существует, прочитайте таблицу и используйте ip route replace 10.71.0.0/24 via 172.22.0.1 dev transit. Если сбой сохраняется, сравните назначения и следующие узлы обоих маршрутизаторов, затем повторите из правильной клиентской вкладки. Не перезапускайте все службы и не меняйте адреса конечных узлов.
Сохранить остальные пути
Здесь вы проверите оба направления и защищённую третью сеть. Начните в Area B и запросите Main Stage:
curl --noproxy '*' -fsS --max-time 3 http://10.71.0.10:8080/programme.txt
Ожидайте вступительное выступление, шествие фонарей и Request received from: 10.72.0.10. Запросите также локальную программу и сигнал радиорубки:
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
curl --noproxy '*' -fsS --max-time 3 http://10.73.0.10:8080/programme.txt
Переключитесь на Area A и сохраните её исходный локальный доступ и радиорубку:
ip -4 addr show dev eth0
ip route show default
curl --noproxy '*' -fsS --max-time 3 http://10.71.0.10:8080/programme.txt
curl --noproxy '*' -fsS --max-time 3 http://10.73.0.10:8080/programme.txt
Адрес по-прежнему 10.71.0.10/24, клиентский маршрут по умолчанию — via 10.71.0.1. Переключитесь на Area B и прочитайте соответствующие значения:
ip -4 addr show dev eth0
ip route show default
Адрес остаётся 10.72.0.10/24, маршрут по умолчанию — via 10.72.0.1. В Area Plan запросите все три ресурса из Area A и Area B. Прочитайте содержимое и исходные адреса, затем раскройте обе таблицы. Оба исходных unreachable default metric 32760 сохранены. Более конкретные маршруты имеют приоритет без замены маршрутов по умолчанию.
Если вы случайно удалили защищённый маршрут третьей сети на East Router, восстановите только его изученной формой замены:
ip route replace 10.73.0.0/24 via 172.22.0.1 dev transit
Исходные маршруты по умолчанию конечных узлов приведены выше. Маршруты по умолчанию маршрутизаторов восстанавливаются в их собственных вкладках командой ip route replace unreachable default metric 32760; не применяйте эти учебные команды к сети платформы. После исправления прочитайте таблицу и повторите все затронутые запросы. Сохраните подключённые маршруты, адреса, каналы и процессы служб. Проверки только читают состояние и отправляют обычные GET; они не добавляют маршруты и не чинят среду. Допускаются эквивалентные точные маршруты в указанном диапазоне удалённой зоны.
Найдите на карте двух соседей транзитного канала и сравните строки назначения с сохранёнными маршрутами по умолчанию. Раскрытые таблицы показывают настоящие маршруты ядра в работающей среде.
Резюме
Вы применили настоящие запросы маршрутизации и ограниченные маршруты для передачи программ фестиваля, сохранив исходные адреса и остальные пути. Вы также различили запросы соединения и ответы с помощью ограниченного захвата реальных пакетов.
