Странное поведение роутинга


Главная Форумы IBM i (OS/400) Странное поведение роутинга

В этой теме 24 ответа, 4 участника, последнее обновление  Sever 5 года/лет, 9 мес. назад.

  • Автор
    Сообщения
  • #14408

    Tatyana
    Участник

    Здравствуйте!

    На сервере возникла странная ситуация ровно с одним из маршрутов роутинга. Если смотреть через netstat — > 2 (Display …) — он виден, а через cfgtcp — > 2 (Work with …) — нет. Пытались воспроизвести эту ситуация — создали с правами QSECOFR’а «левый» маршрут — не помогло, пользователь с более урезанными правами его все равно видел там и там и спокойно мог удалить (разумеется, маршрут, который не отображался через cfgtcp удалить не получилось — только «прописать поверх»). Все остальные маршруты — на месте. Случилось это после того, как сервер, на ip-адрес которого должны были отправляться ip-пакеты, снова стал доступен после перезагрузки.

    Вероятно (но тут я не до конца уверена) поменялся и сам ip-адрес «Next hop» в маршруте. Это я вообще уже объяснить не могу никак! Человеческий фактор исключен процентов на 90 — все это происходило до начала рабочего дня, пароли меняются регулярно, да и следов логина на сервер в это время пользователей с соответствующими правами в логах не замечено.

    Как такое возможно?!

  • #14409

    Sever
    Участник

    Rtanya, здравствуйте. Было бы неплохо взглянуть на скриншоты по данной теме, если они у вас есть.

  • #14411

    Tatyana
    Участник

    Rtanya, здравствуйте. Было бы неплохо взглянуть на скриншоты по данной теме, если они у вас есть.

    А что можно интересного увидеть на скриншотах? Все равно, из соображений безопасности, все ip-адреса я обязана скрыть. А нажать F11 при просмотре маршрута по netstat’у и увидеть параметр появления загадочного маршрута («CFG» или другой) я не догадалась.

  • #14412

    Sever
    Участник

    Скриншоты нужны для устранения потенциального различия терминологии. Мне кажется, что резльтат netstat *cnn не имеет никакого отношения к таблице маршрутов. Это просто слепок состояния текущих соединений или попыток таких соединений с указанием их статуса. Без ясности того, к чему у вас претензии или вопросы, дать исчерпывающий ответ невозможно.
    Если у вас ограничения по NDA, то просто откройте PMR в сервисе IBM. Только приготовьте заранее все скриншоты. Без них сервис аналогично не сможет вам ничем помочь.

  • #14413

    Tatyana
    Участник

    Скриншоты нужны для устранения потенциального различия терминологии. Мне кажется, что резльтат netstat *cnn не имеет никакого отношения к таблице маршрутов. Это просто слепок состояния текущих соединений или попыток таких соединений с указанием их статуса. Без ясности того, к чему у вас претензии или вопросы, дать исчерпывающий ответ невозможно.
    Если у вас ограничения по NDA, то просто откройте PMR в сервисе IBM. Только приготовьте заранее все скриншоты. Без них сервис аналогично не сможет вам ничем помочь.

    Спасибо большое, у нас возникло такое предположение, только мы не придумали, как его проверить. То есть, если какой-то программой пытаться сконнектиться с удаленным узлом, то соответствующий маршрут с ip-адресом появится в статистике netstat’а?

    Осталось понять, как мог маршрут пропасть из списка маршрутов без всяких следов, потому как до этого события все нормально работало.

  • #14414

    Sever
    Участник

    То есть, если какой-то программой пытаться сконнектиться с удаленным узлом, то соответствующий маршрут с ip-адресом появится в статистике netstat’а?

    да, в списке netstat *cnn появится запись, но это не «маршрут».

    Осталось понять, как мог маршрут пропасть из списка маршрутов без всяких следов, потому как до этого события все нормально работало.

    Фраза мне непонятна… Если вы имели в виду отсутствие информации о соединении в списке netstan *cnn, то это нормально. В этом списке отображается информация только об активных соединениях. После разрыва соединения информация о нем из этого списка пропадает автоматически.

    Если вы хотите отследить все попытки исходящих и входящий сетевых соединений, то задействуйте аудиторский журнал. Существует возможность его настройки для логирования коммуникационных событий.

  • #14415

    Tatyana
    Участник

    [quote quote="rtanya"]Осталось понять, как мог маршрут пропасть из списка маршрутов без всяких следов, потому как до этого события все нормально работало.

    Фраза мне непонятна… Если вы имели в виду отсутствие информации о соединении в списке netstan *cnn, то это нормально. В этом списке отображается информация только об активных соединениях. После разрыва соединения информация о нем из этого списка пропадает автоматически.[/quote]

    Нет, я имею ввиду исчезновения маршрута из списка маршрутов, который отображается через cfgtcp -> 2 (Work with TCP/IP routes)

    До времени «Ч» (перезагрузки сервера, который «Next hop») все работало нормально, после перезагрузки коннект пропал.

  • #14416

    Sever
    Участник

    Чудес не бывает. Таблица маршрутов может быть изменена только «руками», т.е. преднамеренно.

  • #14417

    Oldnick
    Участник

    а проблема то в чем? сейчас что не работает? 🙂 у вас какие-то специфические маршруты настроены в OS/400 ?
    попробуйте заново переделать таблицу маршрутов. права пользователя не имеют отношения к маршрутам. Сетевые настройки работают на уровне операционки. Менять их может только пользователь у которого есть права. Пользоваться могут все.
    также не помешает обновить PTFs, если они у вас сильно устарели.

  • #14418

    Oldnick
    Участник

    исчезновение маршрута из таблицы маршрутов — это фактически удаление записи из конкретной таблицы (файла) в библиотеке QUSRSYS.
    …ясно что кто-то удалил стандартными средствами из меню cfgtcp…
    иногда приходится удалять маршрут, когда необходимо удалить tcp/ip интерфейс, который связан с этим маршрутом… например, во время пересоздания интерфейса (изменение имени линии и т.д.), потом наверно просто забыли добавить маршрут.
    100% думаю так и было….

  • #14419

    Tatyana
    Участник

    исчезновение маршрута из таблицы маршрутов — это фактически удаление записи из конкретной таблицы (файла) в библиотеке QUSRSYS.
    …ясно что кто-то удалил стандартными средствами из меню cfgtcp…
    иногда приходится удалять маршрут, когда необходимо удалить tcp/ip интерфейс, который связан с этим маршрутом… например, во время пересоздания интерфейса (изменение имени линии и т.д.), потом наверно просто забыли добавить маршрут.
    100% думаю так и было….

    Если бы все это не происходило до начала рабочего дня и число людей, одновременно имеющих доступ на сервер и знающих команду «cfgtcp», понимающих что такое «маршрут», «tcpip» и т.п. не равнялось бы двум, я бы тоже так считала. Вдумчивый анализ логов также показал, что никто в это время на сервер не заходил.

  • #14420

    Tatyana
    Участник

    а проблема то в чем? сейчас что не работает? 🙂 у вас какие-то специфические маршруты настроены в OS/400 ?

    После прописывания маршрута все работает. Пугает, что пользователи работают без выходных в отличие от системных администраторов и если не понять, что произошло, ситуация имеет шанс повториться.

    Маршруты не специфические, обычные, на разные сервера.

    попробуйте заново переделать таблицу маршрутов.

    Все таблицу? Зачем?

  • #14421

    Oldnick
    Участник

    повторится может только если кто-то опять удалит маршрут. 🙂

  • #14422

    Tatyana
    Участник

    повторится может только если кто-то опять удалит маршрут. 🙂

    Я слабо верю в трудоголиков из головной конторы в Москве, которые появились на работе до 9 утра, да и в логах от них следов не осталось.

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

  • #14423

    Oldnick
    Участник

    подозреваю что часть пользователей имеют почти такие же права как и администраторы.
    также подозреваю что больше это у вас не повторится. 🙂
    возможно кто-то по ошибке удалил, и не признается…

  • #14424

    Tatyana
    Участник

    подозреваю что часть пользователей имеют почти такие же права как и администраторы.
    также подозреваю что больше это у вас не повторится. 🙂
    возможно кто-то по ошибке удалил, и не признается…

    Нет, у пользователей вообще нет прав «на зеленую консоль», пользователи не могли физически попасть ни за компьютеры системных администраторов, ни в серверную. Впрочем, последнее бы ничего не дало, потому что консоль «отваливается» после относительно непродолжительного бездействия, за ночь — с гарантией. В том-то и ерунда, что масса независимых логов (например, системы разграничения доступа, учета рабочего времени и т.п.) подтверждают, что нас в это время на рабочем месте не было. В понедельник буду выяснять, как с этим в головной московской конторе (но там тоже с «жаворонками» напряженка, мало их среди системных администраторов!).

  • #14425

    Oldnick
    Участник

    удалить маршрут можно тремя способами:
    1. Из меню cfgtcp, работа с маршрутами.
    2. командой RMVTCPRTE
    3. Из графического клиента iSeries Access.

    раз уж 100% доступ к этим функциям есть только у отдельных лиц, ищите среди них.
    Сам маршрут удалиться не мог. Его удалили. Это также очевидно, как то, что я сейчас этот текст ввожу…

  • #14427

    Сергей
    Участник

    Люблю загадки, но в чудеса не верю 😉
    «зеленый экран» не единственное место, откуда «пошалить» можно — через обыкновенный JDBC с префиксом CL: почти любая системная команда выполняется, есть ClientAccess, про который уже говорили, а в нем есть rmtcmd, которую можно и зашедулить (и натравить например на CHGJOBSCDE) с последующей самоликвидацией.

    Границы фантазии ограничиваются только наличием аудиторских логов и программ с adopted autority

    если уж искать врага, так по взрослому 😉

  • #14431

    Sever
    Участник

    «А был ли мальчик?»
    Столько флуда на пустом месте.

  • #14432

    Tatyana
    Участник

    «А был ли мальчик?»
    Столько флуда на пустом месте.

    Польза однозначно есть — разобралась с netstat’ом. Спасибо большое! Все остальное по-прежнему загадочно, буду дальше думать.

  • #14433

    Sever
    Участник

    IMHO:
    Никто ничего в «ночь перед рождеством» не удалял. Если что и удаляли, то сами админы и в другое время. Возможный вариант событий привел Oldnick.

    Другими словами, у вас все работало без «корректной с вашей точки зрения» прописки маршрута. При возникновении проблемы вы все силы бросили на поиски того, чего не было.

    Рекомендую не искать ведьм. Если бы хотели навредить, то не с помощью изменений в маршрутах — это слишком витеевато.

    Просто проведите инвентаризацию настроек и задокументируйте их. Будет потом на что ссылаться при подобных случаях.

  • #14435

    Tatyana
    Участник

    IMHO:
    Никто ничего в «ночь перед рождеством» не удалял. Если что и удаляли, то сами админы и в другое время. Возможный вариант событий привел Oldnick.

    Другими словами, у вас все работало без «корректной с вашей точки зрения» прописки маршрута. При возникновении проблемы вы все силы бросили на поиски того, чего не было.

    Рекомендую не искать ведьм. Если бы хотели навредить, то не с помощью изменений в маршрутах — это слишком витеевато.

    Просто проведите инвентаризацию настроек и задокументируйте их. Будет потом на что ссылаться при подобных случаях.

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

    В таблице маршрутизации прописан маршрут, по которому все пакеты из 10 подсети с маской 255.0.0.0 отсылаются на Next hop, скажем для определенности 10.1.1.1. Есть еще некоторое количество маршрутов, которые пакеты из подсети 10.хх.0.0 с маской 255.255.0.0 отсылают на другие Next hop’ы. То есть, по умолчанию все идет на 10.1.1.1. Маршрут на сервер (пусть его ip-адрес будет 10.3.3.3), из-за недоступности которого все и началось, скорее всего, действительно не был специально прописан, так как хватало умолчания (туда и надо ходить через 10.1.1.1).

    Утром пятницы нам говорят, что нет связи с сервером 10.3.3.3. Так как это случается регулярно (сервер — не наш), то мы ничего не делаем и ждем, когда все само заработает (как всегда и происходит). Через некоторое время «хозяева» сервера говорят, что у них все хорошо и мы должны искать причины на нашей стороне. По принципу «сделайте хоть что-нибудь» мы прописываем маршрут на 10.3.3.3 по узкой маске (255.255.255.254) через Next hop 10.1.1.1. Пинги пошли. Почему?!

    В понедельник с утра внимательно изучаю таблицу маршрутизации, вижу, что маршрут на 10.3.3.3 лишний, убиваю его — ничего не происходит, пинги как шли, так и идут! Ничего не понимаю, на всякий случай, создаю его снова и пытаюсь понять, что происходит, не понимаю 🙁

  • #14491

    Oldnick
    Участник

    ощущение, что у вас маршрут не было удален, а причина была в другом.

  • #14511

    Tatyana
    Участник

    ощущение, что у вас маршрут не было удален, а причина была в другом.

    Да, по предположению сетевика, вернувшегося из командировки (т.е. всех этих чудес он не застал), дело в том, что на iSeries какие-то проблемы с ICMP, по идее, надо вообще этот протокол закрыть, оставив только возможность пингов. Как это сделать — я пока не нашла.

  • #14512

    Sever
    Участник

    Дополнительные маршруты требуются:
    — при общении системы с более чем одним VLANом (обязательно)
    — при использовании более чем 1 карт/портов в одной сети для балансировки трафика (опционально)

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

Для ответа в этой теме необходимо авторизоваться.