Как стать автором
Обновить

Комментарии 46

На Win7, при неправильно указанном адресе шлюза, вываливает предупреждение, но дает сохранить.Так что, ваш коллега, скорее всего не обратил внимание и просто нажал сохранить.
Тогда это не баг, а диверсия. Хотелось бы понять логику разработчиков, заложивших такую потенциальную бомбу.
Бритва Хенлона. В данном случае просто не стали ставить дополнительную защиту от дурака.
А кто не читает предупреждения, тот сам себе злобный буратино.
А можно узнать версию форточек? А то или я не заметил или вы не указали.
А вообще — бага конечно, не иначе. Форточки это не тот инструмент которым положено отстреливать себе ноги.
Забыл указать — Windows 7 максимальная. Я бы запретил сетевикам работать с виндой, но у компании и департамента ИБ иная точка зрения, увы.
Никакого бага тут нет, ситуация, когда default gateway находится в другой подсети, хоть и странная, но реальная и возможная.
Шлюз по умолчанию совсем не обязательно должен быть в той же подсети, что и хост.
Важно, чтобы он был просто доступен (был маршрут до этого самого default-gateway).
В каком RFC это описано?
RFC 1620 — Internet Architecture Extensions for Shared Media например. Суть в том, что сегодня полно сценариев, когда 2 хоста находятся в одном L2 сегменте (SameSM), но в разных IP подсетях (LIS). При этом, один из хостов может быть шлюзом для другого. Чтобы это работало, необходимо лишь указать хосту, что шлюз находится с ним в одной shared media, т. е. вручную прописать на нем маршрут «в интерфейс» (link route), либо раздать его через DHCP option 121
Неправильный вопрос, правильный звучит так «В каком RFC явно указывается что default gateway должен находиться в той же подсети что и сетевой интерфейс?»
Правильный ответ — ни в каком, читайте как работают протоколы роутинга и что такое дефолтный маршрут и зачем он нужен.
Да пусть любые воркараунды делает. Мне все равно.
Если оно досит сетевое оборудование, значит баг.
Windows стабильно игнорит ситуации, когда шлюз оказывается за пределами, определенными маской. Такое чувство, что в случае наличия такой ситуации ОС может подменить маску, выданную DHCP сервером на ту, которая позволит достучаться до шлюза. Уведомлений об этом обычно нет. Как по мне Windows таким образом создает прецедент безопасности, хотя такое поведение очень часто фиксит проблемные сети, где так или иначе шлюз оказывается недоступен вследствие неверной маски, что очень часто можно встретить как типовую ошибку.
Технически маску можно сделать вообще любую, хоть с такой дыркой 255.0.255.0 и всё будет работать (и не обязательно неправильно) в соответствии с протоколами маршрутизации и ARP.
Хотелось уточнить, что значит технически сделать?

Вбить в конфиг и сохранить в файл или построить работающую сеть, использующую оборудование и операционные системы реализующие стандартные сетевые технологии?

Как кратко записать маску 255.0.255.0? Например, 255.255.255.0 получаем маску /24, а в вашем случае какая краткая маска получится?
А не нужно её в CIDR записывать, и всё станет на свои места.

Всё гораздо проще с этими масками.
Ведь как работает маршрутизация на какой-то абстрактный target IP адрес:
1) сначала свой IP и target IP умножается на маску (бинарно).
2) в результате сравнивается то, что остаётся после умножения.
3) если результаты совпадают, то подсеть одна, посылается ARP-request target хосту и в результате пакет пересылается напрямую хосту с IP и MAC-адресом хоста.
4) Если не совпадают, пакет всё равно посылается хосту на с MAC-адресом маршрутизатора (для чего сначала отправляется ARP-request на маршрутизатор).

и да, всё будет работать с дырявыми масками, если вся сеть будет соответствующим образом настроена. проверялось лично лет 15 назад.
RFC прерывистые маски не запрещает, но на практике никто не тестирует с ними софт и есть веротяность наткнуться на баг. Недавно наткнулся на пропадение крипто-мапы на IOS после применения к ней ACL с опечаткой в маске.
Ключевое слово опечатка (ошибка). Если всё делать преднамеренно и на всей инфраструктуре, то работать будет.
В своё время мне довелось поработать тестировщиком у отечественного производителя VPN. Там иногда тестируется и не такое.
А что вас смущает в том, что шлюз лежит вне диапазона сети? В линуксе я постоянно пользуюсь такими штуками.
ip addr add 10.100.10.2/24 dev eth0
ip ro add via 10.100.11.1 src 10.100.10.2 dev eth0
всего лишь заставит ОС в случае отсутствия известного маршрута до адреса назначения послать запрос через шлюз. Шлюз указан 10.100.11.1, и поэтому в eth0 будет послан arp who has 10.100.11.1 и после получения ответа все запросы «на шлюз» будут направляться на этот МАС. IP-адрес шлюза больше нигде не участвует в этом, собственно и ваш IP тоже, если маршрутизируем какую-то другую сеть (к примеру 10.200.10.0/24 с eth1).

И даже интереснее бывают проблемы с arp. Например, когда нужно маршрутизировать разные адреса клиентов через один и тот же шлюз, но в разных вланах.
ip ro add via 10.10.20.1 dev eth0.11 table vlan11
ip ro add via 10.10.20.1 dev eth0.12 table vlan12

приходится сделать
sysctl -w net.ipv4.conf.eth0/11.rp_filter=0
sysctl -w net.ipv4.conf.eth0/11.arp_ignore=2
sysctl -w net.ipv4.conf.eth0/12.rp_filter=0
sysctl -w net.ipv4.conf.eth0/12.arp_ignore=2
а то когда одна сетевая карта разными МАСами в разных вланах смотрит в один физический сегмент на один и тот же шлюз, то трафик бывает идет не в тот влан
И даже больше скажу: если не шлюзе (роутере, компьютере) не включен arp_ignore, то при получении запроса arp who has
1) с несуществующего в этой сети IP
2) запрашивающий IP-адрес, который отсутствует на этой сетевой карте/влане, но пристутствует на хосте вообще
— роутер ответит

Часто пользуюсь командой, чтобы узнать примерно количество включенных роутеров в влане:
#arping -0 -I eth0.1234 192.168.0.1
#arping -0 -I eth0.1234 192.168.1.1

Посылает запросы с айпишника 0.0.0.0 в сегмент, и все роутеры с дефолтовыми 192.168.0-1.1 адресам отвечают как миленькие.
это на какой ОС такой ключик у arping?
[root@bsmanage ~]# arping -0
arping: invalid option — '0'
Usage: arping [-fqbDUAV] [-c count] [-w timeout] [-I device] [-s source] destination
-f: quit on first reply
-q: be quiet
-b: keep broadcasting, don't go unicast
-D: duplicate address detection mode
-U: Unsolicited ARP mode, update your neighbours
-A: ARP answer mode, update your neighbours
-V: print version and exit
-c count: how many packets to send
-w timeout: how long to wait for a reply
-I device: which ethernet device to use (eth0)
-s source: source ip address
destination: ask for what ip address

[root@bsmanage ~]# uname -a
Linux bsmanage.lds.net.ua 2.6.32-642.1.1.el6.x86_64 #1 SMP Tue May 31 21:57:07 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[root@bsmanage ~]# cat /etc/*rele*
CentOS release 6.8 (Final)
Ubuntu

ARPing 2.09, by Thomas Habets <thomas@habets.pp.se>
usage: arping [ -0aAbdDeFpqrRuv ] [ -w ] [ -S <host/ip> ]
[ -T <host/ip ] [ -s ] [ -t ] [ -c ]
[ -i ] <host/ip/MAC | -B>
Options:

-0 Use this option to ping with source IP address 0.0.0.0. Use this
when you haven't configured your interface yet. Note that this
may get the MAC-ping unanswered. This is an alias for -S
0.0.0.0.

Без ключика 0 не хочет слать arping с интерфейса, на котором нет IPv4 адреса, а у меня таких интерфейсов сотни, на вланах с proxy_arp. Поэтому использую, потому как алиас "-S 0.0.0.0" писать дольше
Меня смущает результат такого нестандартного использования шлюза, что я и описал в топике.
А, не смущает полное отсутствие необходимости в шлюзе, к примеру, на ppp-интерфейсах (точка-точка, ppp/tun/tap/etc).
Формально он там обычно указывается, но можно и без него, абсолютно.
#ip ro add dev ppp0
при этом на ppp-интерфейсах на обоих сторонах тоннеля вообще можно IP не вешать, все прекрасно работает.

Да и на обычном компе можно шлюз не указывать, винда по умолчанию (если память не изменяет) в случае отсутствия шлюза в системе просто шлет в сеть запрос «arp who has IP-адрес-назначения». И если на роутере в сети, куда подключен этот интерфейс, включен proxy_arp то интернет прекрасно работает. Просто компьютер «думает» что у него весь интернет в локальной сети, и у всех компов в интернете один и тот же МАС — МАС роутера.
в eth0 будет послан arp who has 10.100.11.1 и после получения ответа все запросы


Каким образом броадкаст пакет из одной подсети (10.100.10.0/24) попадает в другую (10.100.11.0/24)?

и после получения ответа все запросы «на шлюз» будут направляться на этот МАС

Как обратится к по MAC в другую IP-подсеть?
>Каким образом броадкаст пакет из одной подсети (10.100.10.0/24) попадает в другую (10.100.11.0/24)?
Никаким, в ip route можно жестко указать маршрут на connected сеть через интерфейс, даже не имея собственного адреса в этой сети. Маршрут есть — этого достаточно. ARP система сгенерит сама, если nexthop=интерфейс.

>Как обратится к по MAC в другую IP-подсеть?
Никак, на MAC-уровне нет подсетей.
НЛО прилетело и опубликовало эту надпись здесь
Когда устройств за 2к и все на мониторинге у людей, которые по каждому чиху заводят инциденты — желание проводить ренамберинг на них в очередной раз как-то улетучивается 8)
НЛО прилетело и опубликовало эту надпись здесь
Согласен почти со всем, но пользовательская ОС это не роутер. По моему мнению в ней всё должно быть однозначно.
Чувак, ты явно в ударе, делать заключения аля «вы ничего не понимаете в сетях» на основании одного из высказываний. По моим сведениям, например Router OS для микротиков ведет себя иначе при такой ситуации.
Неужели не дает поставить шлюз вне пределов сети??? Нет под рукой микротика сейчас, чтобы проверить, но как-то не вертится в это берд.
Дает поставить, но только какой результат? В Windows ядро маршрутизирует трафик в этом случае, микротик по-моему в таком случае игнорил это, можете проверить, я проверял на случаях, когд DHCP сервер выдавал шлюз за пределами, дозволенными маской.
НЛО прилетело и опубликовало эту надпись здесь
С какого перепугу УМЕНЬШЕНИЕ размера локальной сети (а ведь именно такая опечатка в маске привела к тому, что шлюз оказался за бортом) должна неправомерно УВЕЛИЧИТЬ количество хостов которые посчитали локальными? Вероятнее наоборот, что часть локальных узлов стали адресоваться через шлюз. Но так мы не объясним флуд.

Предложу более простой сценарий — винда сохраняет МАС только тех, кто в своей сети, справедливо предполагая, что остальных она будет искать только через шлюз. Ну а МАС шлюза она не сохраняет специально _ОШИБОЧНО_ считая, что он всегда из своей сети, а значит уже сохранен. В результате любой запрос за пределы своей сетки вызывает ARP.

У меня правда остается непонимание что за топология такая у которой есть шлюз (напомню, что мы говорим о сервисной сети для администрирования сетевого оборудования), и этот шлюз на один интерфейс отвечает на ARP, а на остальные пересылает его дальше. Но тут или я что-то не понял, или какая-то специфическая структура, или просто проморгали такую возможность. Ну или я не прав и есть другой сценарий.
НЛО прилетело и опубликовало эту надпись здесь
Ну я диагноз по фотографии ставить не собирался. Я лишь сказал о том, что ваш диагноз по фотографии неверен, а свой привел лишь для иллюстрации того почему неверен ваш.
Плохо не то, что винда позволяет шлюз за пределами маски. Плохо то, что она при этом создает флуд, но не запрещает.
Запретила бы, мол не делай такой шлюз, все бы подстроились, это ж Винда)
Разрешала бы, и не спамила — все было бы тоже ок.
Но разрешать и бажить — плохо.
>IP Unnumbered — маску ставят 255.255.255.255 (те всё слать шлюзу, совсем всё)

Скажу больше, если оборудование поддерживает маску 0.0.0.0, то ему вообще не нужен шлюз ни в каком виде (при определенных усилиях, естественно). Оно будет считать, что все (совсем все) IP адреса находятся с ним в одной подсети и слать ARP запросы в поисках их MAC адресов. Достаточно завести в том же L2 сегменте хост-роутер с Proxy ARP, который будет отвечать на эти запросы и маршрутизировать трафик и, voilà, эти железяки уже в интернете.
Конечно, это голая, но небезынтересная теория. Конечно никто не поддерживает маску /0 и конечно размеры ARP таблиц будут чудовищные))
На чистой винде удалось воспроизвести подобное поведение?
Странно 2016 год, а коммутатор без блокировки ARP storm, обычно глючная карта даунит интерфейс как только широковещалка насчитает 300-500 пакетов в секунду. 5 минут перерыв и интерфейс поднимается 3-5 попыток и даунится интерфейс до операторского вмешательства… ну ладно мож просто не включили. но и в sys log наверняка много интересного упало… хотя я сам когда его смотрел последний раз… Да и втыкать что-то в производственное оборудование как-то не гуд, нет что ли постоянного терминального сервака для настройки обязательно физический доступ к стойке в машинном зале? Разве только с фигой в кармане…
Так судя по всему флуд на коммутаторы доступа прилетал из ядра сети (одмины же, имеют возможность), то есть с аплинкового порта. Включать шторм-контрол на аплинке — не лучшая идея.
А с каких пор кривые руки\невнимательность стали багами ОС?
Так-то в этих ваших линуксах можно и похлеще натворить, особенно не проверяя что ты там по настраивал.
Интересно, я когда-нибудь привыкну, что есть большая и меньшая половины?!..
Учительница детям:
— Я уже который раз объясняю, что половина не может быть большей или меньшей! Половины — они одинаковые, на то они и половины!
Однако большая половина класса этого не понимает…
TCPDUMP запустили… А что в ARP-запросах было?
ip 10.220.198.111/23
GW 10.220.192.1/19
вполне рабочая конфигурация в отличие от
ip 10.220.198.111/23
GW 10.220.192.1/23
возможно у Вас просто неисправен интерфейс
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории