Как разные IP-адреса в одной подсети могут иметь разные маршруты?

Когда я отслеживаю свой домашний адрес из офисной сети, он застревает на третьем прыжке.

Это может быть вина вышестоящего провайдера вашего рабочего места , основанного исключительно на количестве прыжков (делая предположения, но если компания достаточно велика, чтобы иметь несколько офисов и VPN, у нее, скорее всего, будет два, если не три внутренних прыжка, прежде чем она достигнет интернет-провайдера. ), а также от попыток отследить указанные адреса из разных мест.

Когда я отслеживаю адрес своего офиса из дома, он застревает на 5-м прыжке где-то на границе между моим провайдером и одним из промежуточных провайдеров.

Не видя следов с обеих сторон, это может ввести в заблуждение. Часто один и тот же маршрутизатор имеет IP-адреса, принадлежащие как его реальному владельцу , так и различным промежуточным провайдерам, с которыми он пирингуется, и как номер AS, так и «обратный DNS» могут соответствовать этому провайдеру (или, например, IX), даже если технически это маршрутизатор клиента.

теперь вроде как роутить разные IP адреса в одной и той же подсети (89.179.244.0/24, AS8402) приходят разные ответы!

Объяснений может быть несколько:

1. Маршруты BGP (и маршруты в целом) не обязательно соответствуют подсетям. Они соответствуют сетям, но сеть может состоять из одной подсети, нескольких или половины подсети. Вполне возможно, что у вашего интернет-провайдера будет два/25подсети или четыре/26и рекламировать их как совокупность/24маршрут через BGP (а также для внутренней маршрутизации интернет-провайдера).

   И наоборот, возможно, что фактическая подсеть может быть /20 или /17 или что-то в этом роде, но интернет-провайдер деагрегирует объявления BGP до группы /24 для (часто сомнительных) целей «оптимизации BGP».

2. Некоторые маршруты могут вообще не указывать на «подсети»; вместо этого каждый отдельный адрес из /24 может быть маршрутизирован «точка-точка» через другое устройство.

   Например, возможно, что на самом деле подсети 89.179.244.0/24 как таковой не существует, но внутри клиентские маршрутизаторы используют совершенно разные адреса, а их «публичные» адреса внутренне маршрутизируются как /32 (например,89.179.244.35/32 via 172.16.42.35Такие вещи). Я знаю одного соседнего интернет-провайдера, который делает именно это.

   Я не удивлюсь, увидев это в некоторых сетях, которые полностью переходят на IPv6 (используя модель «IPv4 как услуга»). Более распространенный пример: большинство типов VPN работают в режиме «точка-точка» (без ARP), а не эмулируют широковещательную подсеть.

3. Аналогично вышесказанному, даже если у интернет-провайдера есть общий маршрут BGP для всей вашей сети, он может вручную добавить более конкретный маршрут специально для вашего адреса, например, если им по какой-то причине необходимо заблокировать трафик к нему. Вполне возможно маршрутизировать, например, определенный/32через куда-то еще, чем остальные (вопрос только зачем).

4. Точкой расхождения маршрутов может быть использование ECMP (многопутевая маршрутизация с равной стоимостью). В корпоративных маршрутизаторах (и даже в Linux) для маршрута может быть указано несколько шлюзов, и пакет может использовать любой из них. Это можно использовать в сочетании с BGP, например, если существует несколько путей с одинаковым предпочтением, вместо использования разрешения конфликтов для выбора только одного «лучшего» пути маршрутизатор просто объединяет их все в маршрут ECMP.

           $ ip route show
   
   /* Normal route: */
   10.147.112.0/24 via 10.147.240.4 dev gre-ember proto bird metric 32
   
   /* ECMP route: */
   10.147.122.0/24 proto bird metric 32 
       nexthop via 10.147.240.3 dev gre-wind weight 1 
       nexthop via 10.147.240.4 dev gre-ember weight 1 
   

   Обычно в ECMP следующий переход для каждого пакета выбирается путем хеширования адресов источника и назначения, так что все пакеты от и до одних и тех же узлов проходят по одному и тому же пути, но другой пункт назначения может идти по другому пути.

   Например, если есть два следующих перехода, тоhash(src.dst) mod 2определяет, какой следующий переход (0-й или 1-й) выбрать, поэтому в результате вы можете увидеть, что «нечетные» IP-адреса назначения будут использовать следующий переход A, в то время как «четные» пункты назначения используют следующий переход B, или наоборот.

   (Это похоже на то, как работает агрегирование каналов на основе LACP, только на уровне L3, а не на уровне L2.)

Traceroute не является надежным на 100%. Если он не сможет получить ответ от каждого перехода, он не будет работать хорошо. Несколько лет назад это работало очень хорошо, потому что ни у одного сервера не было причин избегать этого. Но теперь есть масса причин сбросить пинги.

Можешь попробоватьnmapна последнем прыжке, который вы получите, и точно увидите, что происходит с этим сервером. Ваш домашний маршрутизатор может быть настроен на отбрасывание определенных пингов, и в этом случае трассировка будет невидима.

Вы также можете повозиться с программой трассировки и посмотреть, можно ли отрегулировать время, чтобы получить больше ответов. Я сделал трассировки, где после первого прыжка ничего не показывалось! Итак, вы просто не будете точно знать, что там происходит, если не просканируете порты, казалось бы, мертвых хостов.

У вас дома открыты порты для приема пингов? Если все порты закрыты, т.е. ни один сервер не подключен к Интернету, маршрутизатор также может сбрасывать пинги, потому что вообще нет смысла сообщать о вашем присутствии. Кроме того, ваш статический IP-адрес преобразован из модемного соединения DHCP. Есть сервисы, где вы указываете свой динамический ip, а получаете статический. Если ваш динамический IP-адрес изменится, вы должны сообщить службе новый IP-адрес.

Эти типы статических IP-адресов не являются общепринятыми. Это не динамический DNS, где ваш динамический IP-адрес преобразуется в URL-адрес. Преобразование одного IP-адреса в другой более опасно с точки зрения сети. И не каждый интернет-маршрутизатор распознает такие вещи.

Попробуйте использовать IP-адрес вашего провайдера или вы получили статический IP-адрес от своего провайдера? В любом случае, все не всегда так, как кажется простым сетевым инструментам. Иногда нужно копнуть глубже.