Francyz
@Francyz
Photographer & SysAdmin

Данное поведение провайдера это норма?

На статью на Хабре не тянет, поэтому спрошу тут о ситуации.

Вопрос в следующем: "Нормально ли это?"

Настраивал ноутбук с включенным Wi-Fi, сетевая была свободная. Так случилось, что нужно было настроить сетевой принтер "по-быстрому". Не вопрос, ставлю локальный адрес на ноуте и потом на принтере. По сложившейся уже давно традиции перед назначением адреса я их пингую. Адрес просто взялся рандомно из головы, без раздумий - 192.168.40.41 и для принтера хотел сделать 192.168.40.40.
Но дальше пошло волшебство, я пинганул с ноута адрес 192.168.40.41 и он отвечал, хотя такого быть не может. У меня нет ни 40 сети, ни тем более этого адреса. Далее в дело пошел трасерт.
tracert 192.168.40.41
Трассировка маршрута к 192.168.40.41 с максимальным числом прыжков 30
 
  1    <1 мс    <1 мс    <1 мс  192.168.2.250
  2    <1 мс    <1 мс    <1 мс  192.168.1.1
  3     4 ms     4 ms     4 ms  73.*****.donpac.ru [73.*****]
  4     4 ms     4 ms     4 ms  188.***.172
  5    43 ms    37 ms    37 ms  192.168.40.41

Любопытный читатель сразу же увидит, кому из провайдеров принадлежат адреса.

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

Он из частной сети, на нашем оборудовании не определяется, не резолвится через 2IP и подобные сервисы. Проблема на вашем оборудовании.

Если не брать во внимание то, что ТП зачем-то пробивали адрес 192.168.40.41 на внешнем сервисе 2ip, на мой вполне логичный (как я думаю) вопрос: Причем тут мое оборудование, если на третьем шаге ваш шлюз перенаправил мой запрос сначала на другое оборудование (тоже этого провайдера), а потом и на конечный адрес, который не пойми где находится, последовал очередной ответ:

Но каким-то же образом это оборудование с данным IP-адресом отобразилось в Вашем мониторинге

С нашей стороны предоставляется по договору услуга «Доступ в Интернет»
Соответственно, маршрутизация нашего оборудования не отбрасывает шаги при трассировке и позволяет пинг
Сделала бы она это в том случае, если IP 192.168.40.41 принадлежит Вашей внутренней сети

А данный IP вполне возможно Вы можете пропинговать, если на оборудовании, которому он принадлежит, открыт доступ из внешней сети
Если Вы хотите дополнительно защитить свою сеть от предполагаемого несанкционированного подключения с этого адреса - можем предложить Вам дополнительно настроить Access-list у Вас на оборудовании и запретить любой трафик по любым портам с IP 192.168.40.41

Т.е. получается у Ростелекома (извините за спойлер), вообще никаких ограничений нет в их сети, и то что я пингую чейто адрес оборудования, которое втыкнуто в коммутатор в другом городе - это впорядке вещей. У них нет ни vlan, ни каких-то других разграничителей доступа для разных организаций или банально сегментов сети.
А проблема оказывается лечится на моей стороне при помощи ACL.

Это норма и я чего-то не понимаю?
  • Вопрос задан
  • 1170 просмотров
Решения вопроса 1
CityCat4
@CityCat4 Куратор тега Сетевое оборудование
//COPY01 EXEC PGM=IEBGENER
Практически первым шагом у меня было заблокировать любой трафик с RFC1918-совместимых адресов с внешнего интерфейса и точно также его заблокировать с внутренних адресов, если он уходит на внешний интерфейс.

Судя по счетчику дропов - отброшено около 100 Мб таких пакетов :) И голова не болит. Да, могут быть и криворукие юзера и не менее криворукие провайдеры - но это уже не мое дело
Ответ написан
Пригласить эксперта
Ответы на вопрос 5
@Akina
Сетевой и системный админ, SQL-программист.
Нет, это явное нарушение RFC.

Адрес 192.168.40.40 относится к категории немаршрутизируемых в Интернете. Любой узел, если он получил пакет на этот адрес на интерфейсе с маршрутизируемым адресом, либо если он должен согласно своей таблице маршрутизации отправить его через интерфейс с маршрутизируемым адресом, должен отказать в маршрутизации (какое при этом применить правило - deny или drop,- не описано). В трассе имеется адрес 188.***.172, не принадлежащий какой-либо немаршрутизируемой сети - следовательно, в маршрутизации пакета должно было быть отказано.

А что бардак - таки да, это в порядке вещей. Вы поснифьте свой внешний адресок да посмотрите, сколько на него попадает "грязи" - удивитесь.
Ответ написан
На самом деле icmp-ответ, в котором будет "серый" ip-адрес, может прилететь от любого промежуточного узла при трассировке, а не только от ближайшего роутера или из сети своего провайдера. Это связано с тем, что ip-адрес в icmp-ответе, который будет отображен в трассировке, и фактический адрес источника в ip-пакете, с которым он был отправлен с транзитного узла, - это разные сущности. Кроме того, фактический ip-адрес источника может на транзитном маршрутизаторе превратиться из "серого" в "реальный", чтобы иметь возможность быть гарантированно доставленным в интернете. Самый частый случай, приводящий к такому - какой-либо промежуточный маршрутизатор в сети провайдера может обрабатывать транзитный трафик с реальными ip-адресами, имея при лишь служебный серый ip-адрес. Протоколы маршрутизации вполне такое допускают. Так что это в принципе не проблема, хотя некоторых смущает.
P.S. В моей практике была обратная ситуация. Безопасники докопались до ситуации, когда при трассировке внутри интрасети большой организации один из промежуточных узлов отображал реальный ip-адрес, пусть даже этой организации и принадлежащий. Они требовали объяснить, почему трафик ходит через интернет :)
Ответ написан
Комментировать
@Drno
Это не совсем правильно. Но спорить с рт все равно бестолку.
Вы кстати тоже не позаботились защититься толком... с чего это ваш шлюз разрешил пинг на серый адрес через WAN интерфейс?)
Ответ написан
Комментировать
@Gansterito
Это не норма, но и не проблема.
Вы включены в ШПД сегмент Ростелеком, и там наличие серых адресов - норма. Поэтому на доступе трафик на серые IP не ограничивается, улетает куда-то в ядро, и где-то может даже найти своего получателя.
Ответ написан
SLIDERWEB
@SLIDERWEB
ИТ-Куроводитель
Если вас на границе сети стоит маршрутизатор - просто исключите трансляцию/маршрутизацию адресов в Bogoon-подсети через интерфейс провайдера.
Неадекватных инженеров провайдеров, в последнее время, более, чем хотелось бы, это факт. Но это не очень страшно. Можно решить своими силами.
Создайте ACL или пропишите их явно (зависимости от того, что у Вас на границе)
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы