Шлюз по умолчанию: куда уходит пакет, если получатель не сосед

Шлюз по умолчанию — это адрес устройства в вашей же сети, которому отправляется всё, что не предназначено соседям. Ключевое слово «по умолчанию»: это не единственный маршрут, а запасной вариант на случай, когда ничего более подходящего в таблице маршрутизации не нашлось. В таблице он записан как маршрут в сеть 0.0.0.0/0 — под такую маску попадает вообще любой адрес.

Дома роль шлюза обычно играет роутер, в офисе — маршрутизатор или межсетевой экран. Важно, что шлюз обязан находиться в той же подсети, что и устройство: обратиться к нему нужно напрямую, и если он окажется за пределами вашей сети, получится замкнутый круг — чтобы до него достучаться, уже нужен шлюз.

Отсюда простое правило проверки настроек: наложите маску на свой адрес и на адрес шлюза. Номера сетей должны совпасть. Не совпали — конфигурация нерабочая, и никакие другие настройки этого не исправят.

Перед отправкой пакета система сравнивает сеть получателя со своей — при помощи маски подсети. Дальше возможны два сценария.

• Получатель в своей сети. Система выясняет его MAC через ARP и отправляет кадр напрямую. Шлюз в этом не участвует вообще — поэтому файлы между соседними компьютерами копируются даже при полностью мёртвом интернете.

• Получатель в чужой сети. Система берёт MAC шлюза и отправляет кадр ему, оставив в IP-заголовке исходный адрес получателя.

Два адреса в одном отправлении

Тонкость, которая многих сбивает: на канальном уровне кадр адресован шлюзу, а на сетевом пакет по-прежнему адресован конечному получателю. Шлюз принимает кадр, видит, что IP-пакет не ему, ищет маршрут и переупаковывает пакет в новый кадр — уже для следующего узла.

Понимание этого момента сразу объясняет вывод arp -a на обычном компьютере: там почти всегда пусто, кроме шлюза и пары соседей. Компьютер не знает MAC-адрес сервера в интернете и знать не может — весь внешний трафик уходит на один и тот же физический адрес.

Симптом узнаваемый: внутри сети всё прекрасно — файлы копируются, принтер печатает, коллега отвечает на ping, — а наружу не проходит ничего. Причина в том, что для локального обмена шлюз не нужен, и ошибка проявляется только при попытке выйти за пределы своей подсети.

Проверка за минуту

• Смотрим, какой шлюз прописан: ip route в Linux (строка default) или ipconfig в Windows.

• Пингуем сам шлюз. Не отвечает — проблема ближе, чем казалось: ищем на втором уровне или проверяем, тот ли это вообще адрес.

• Отвечает, а ping 1.1.1.1 молчит — дело уже за шлюзом: либо он сам не знает дороги наружу, либо фильтрует.

• Внешний адрес пингуется, а сайты не открываются — шлюз ни при чём, разбирайтесь с DNS.

Отдельный случай — шлюз прописан, пингуется, но интернета нет только у одного устройства. Тогда смотреть нужно на самом шлюзе: не попал ли этот адрес под ограничивающее правило.

Соблазнительная идея: на сервере два сетевых интерфейса, пропишем шлюз на каждом — будет надёжнее. На деле становится хуже. Активный маршрут по умолчанию может быть только один, и система отправит весь внешний трафик через тот, у которого метрика меньше. Второй просто не используется, зато создаёт условия для асимметричных маршрутов, когда ответ уходит не тем путём, каким пришёл запрос, и фаервол по дороге его не узнаёт.

Правильная схема — один шлюз по умолчанию и, если нужно, конкретные статические маршруты до конкретных сетей через второй интерфейс. Типичный пример: основной шлюз смотрит в интернет, а маршрут до сети филиала 10.20.0.0/16 прописан через VPN-шлюз во втором сегменте.

А как же резервирование канала

Настоящее резервирование делается не двумя строчками в настройках сетевой карты, а на маршрутизаторе: он следит за доступностью основного канала и переключает трафик на резервный, когда тот пропал. В корпоративных сетях для отказоустойчивости самого шлюза применяют протоколы вроде VRRP — два маршрутизатора делят один виртуальный адрес, и клиенты вообще не замечают переключения. С точки зрения устройства шлюз при этом остаётся один, и это ровно то, что нужно.

Знакомая ситуация: подключились к рабочему VPN — и перестали открываться обычные сайты, хотя до офисных ресурсов всё доходит. Или наоборот: интернет есть, а рабочие серверы недоступны. Объясняется это тем, что происходит с маршрутом по умолчанию.

При подключении VPN обычно прописывает собственный маршрут 0.0.0.0/0 с лучшей метрикой, и весь трафик начинает уходить в туннель — это называют полным туннелированием. Вариант рабочий и часто обязательный по требованиям безопасности, но тогда интернет идёт через офис, и если там что-то не пускает — его нет вовсе.

Противоположная схема — раздельное туннелирование: маршрут по умолчанию остаётся прежним, а в туннель уходят только конкретные сети вроде 10.0.0.0/8. Интернет при этом работает напрямую и быстрее, но администратор сети теряет контроль над тем, куда ходит машина, — поэтому в корпоративной среде такой режим часто запрещают намеренно.

Разобраться, какой у вас случай, помогает та же команда ip route или route print при поднятом VPN. Видите два маршрута по умолчанию, и верхний ведёт в туннельный интерфейс — значит работает полное туннелирование, и искать причину пропавшего интернета нужно на той стороне.