-51

Прошу совета...

Есть условная сеть. В ней установлен интернет шлюз ideco 7.31. Вещь невероятно глючная. Три свича, которые сеть раздают и все это подключёно к роутеру, который пускает все дело в wan. Суть в том, что перед тем как попасть в wan все это дело отправляется в ideco, происходит Nat, получает ip из пула, пул настроен верно, потом идёт в роутер. Я проверил это трасировкой до роутера. Дело в том, что впн подключение по ideco слетает, а потом заново переподключаеться. Если пинговать и защищённый и не защищённый адрес шлюза, то видны переодические обрывы. Что касается самого ethenet, то здесь контролёра домена нет, dhcp следовательно тоже, все настроено в рукопашную. Не подскажите, пожалуйста, в каком направлении копать?

Дубликаты не найдены

+10

Попробуй обратиться к системному администратору

раскрыть ветку 1
-2
Обратился. Он сказал, что дело дрянь и лучше бежать.
+2
в каком направлении копать

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



Блин, ну серьезно, нарисуй схему, обозначь на ней все линки, пометь настройки портов. 80% проблем решится САМОСТОЯТЕЛЬНО, просто по факту наличия такой схемы. Серьезно.

0

Вот видишь как тут... вроде спросил совета у грамотных людей, а грамотные люди тебе минсуов понаставили и издевательских реплик накидали :)

Спрашивай здесь: https://stackoverflow.com/

0

Дам совет: если хочешь решить свою проблему, то лучше её озвучить на специализированном форуме, на том же ideco.

0

Попробуй обновить Ideco до версии 7.8.9, она вроде стабильно работает, по крайней мере по моим наблюдениям.

раскрыть ветку 1
-2
Как вариант, но обновлять нужно со стойкой. Эта уже на ладан дышит. Я уже связывался с небезыственным Дмитрием и он посоветовал тоже самое. Лицензия кончилась два года тому назад.
0
Есть подозрение, что проблема в ВПН и кривой маршрутизации/nat. Попробуй выключиТь вообще ВПН и посиотреть пинги
0
Что касается самого ethenet, то здесь контролёра домена нет, dhcp следовательно тоже, все настроено в рукопашную

Сейчас в каждом доме стоит ethernet без контроллера домена и с dhcp - тут нет причинно-следственных связей.


По сути вопроса. Без схемы фиг поймешь что куда подключено. Роутер ваш или вы шлюз провайдера роутером называете? Что значит "что впн подключение по ideco слетает" - это от клиентов до ideco или от ideco до шлюза провайдера?


Потратьте 15 минут и нарисуйте в visio\CAD'е\Фотошопе\паинте\бумаге схему. Подпишите название устройств, что куда включено и где какой IP прописан.

раскрыть ветку 13
-2
Роутер мой. От клиентов до ideco.
раскрыть ветку 12
0

а клиенты видят роутер? Т.е. есть ли физическое разграничение между клиентами и роутером? Или все проходит через свичи?

раскрыть ветку 11
0
Копай в сторону подготовки нормальной документации
раскрыть ветку 2
-2
Её не было до меня, а на все вопросы по сети меня посылают нахуй.
раскрыть ветку 1
+1
Ну так возьми и сделай. Самому же проще будет.
0

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

раскрыть ветку 13
-3
Да, потери есть и дело в локалке, а не в шлюзе. Добро это все не моё. Технической документации нет. Что тут творилось хуй его знает. Повожусь ещё неделю. Если люди из головного офиса мне сказать ничего не смогут, то придётся увольняться. Проще все сжечь и заново сделать, но одного меня маловато будет.
раскрыть ветку 12
+1

Если проблемы только в пиково-рабочее время - возможно это вызвано каким-то компом или включаемым-выключаемым оборудованием. Если всё совсем плохо, можно попробовать отключать частями (например, по одному свитчу, затем по одному кабелю и т.д.) и смотреть изменилось что-то или нет. Таким образом локализовать проблемный участок/сегмент сети. И так пока не дойдёшь до конкретного места/линка. Далее выключаешь его, помечаешь и ждёшь кто прибежит с жалобами. Идёшь туда и разбираешься что там творится :)


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

раскрыть ветку 5
0

Так ты никогда ничему не научишься. Я один на заводе сеть поменял, кучу, десятка два, неуправляемых свитчей выкинул. Растянул оптику по всей территории и сеть на кошках сделал. Естественно начал с документации. Делал один и не умер. И это не первый завод который с нуля переделывать приходится после тяпляпашников и оутсорсеров.

раскрыть ветку 5
-1

Не подскажите, пожалуйста, в каком направлении копать?

Копай пока здесь, а я схожу, узнаю, где нужно!


Честно, нихера не понял, что у тебя там, без схемы.


Задам поэтому наводящий вопрос: а аплинк у тебя не по оптике, часом? Посмотри, не перегнул ли ты патч-корд

Похожие посты
575

Один пинг проходит и тишина – решение проблемы

Кому не интересно, можно сразу переходить к блоку «как лечить».


Симптомы:

Итак, ранним осенним утром внезапно отвалились почти все сервисы для одного из филиалов. Симптомы: один пинг проходит и дальше «тишина». Иногда может пролететь еще 1 icmp, но редко. При повторном запуске пинга даже одного пакета уже не пролетает, если не выдержать паузу в несколько минут. Отвалились не все сервисы, но большинство.

Та часть схемы сети, которая нас интересует:

Один пинг проходит и тишина – решение проблемы Системное администрирование, Пинг, Перенаправление, Сети, Маршрутизация, Длиннопост

Понятно по схеме, что грешить сразу стали на красный ящик WatchGuard Firebox, но на нём явно никаких блокировок в логах не обнаружено. Поэтому коллега пока пускал трафик до самых важных сервисов в обход, а я ставила WireShark на то, что не столь нужно вот-прям-щас.


Что происходит:

Итак, что показал WireShark:

Один пинг проходит и тишина – решение проблемы Системное администрирование, Пинг, Перенаправление, Сети, Маршрутизация, Длиннопост

А показал он нам, что после первой же пары request/reply нам прилетело от Watchguard сообщение ICMP redirect (type 5; code 1), в котором сказано примерно следующее «братюнь, да что ты мне своими реквестами отвечаешь, я тут посмотрел – у меня есть более крутой маршрут для этого хоста – шли всё на шлюз 10.77.10.254».


Вот тут и дошло до меня, что ICMP – это не только пинги, но и «Internet Control Message Protocol». Из вики: «ICMP-сообщения с типом 5 используются маршрутизаторами для обновления записей в таблице маршрутизации отправителя». Далее, собственно, request по-прежнему приходит с WatchGuard, а reply уходит на D-Link. При этом, на сервере есть статический маршрут в сеть 10.97.0.0/16 (через 10.77.10.3), а системе строго срать на этот маршрут! Всё потому, что на самом деле при получении сообщения redirect, маршрут на хост (то есть более специфический) добавляется в таблицу маршрутизации на 10 минут. Но route print его не показывает. И не нужно гнать на винду: во всех debian были всё те же симптомы.


Почему это происходит:

Беда Особенность Watchguard, как и микротиков, что Site-to-Site IPSec не является интерфейсом, не участвует в таблице маршрутизации, и, соответственно, маршруты на сеть за поднятым туннелем вы в ней не увидите. На нашем ватче был маршрут 10.0.0.0/8 на 10.77.10.254, так как за D-Link находятся все остальные филиалы (агрегированные по /16 каждый), чтоб не писать маршрут на каждый филиал (их 50, а динамической маршрутизации нет). Из-за особенностей Watchguard получилось так, что на 10.97.0.0/16 маршрута он не видел. Раньше, кстати, всё было ок до последнего обновления прошивки.


Почему некоторые сервисы и все компы были доступны: на них стоял касперский с сетевым модулем, который отбрасывал эти сообщения как небезопасные.


Что было сделано и не помогло:

Попробовали задрать метрику на маршруте 10.0.0.0/8 на WatchGuard – не помогло. Попробовала сделать правило фильтрации по типу ICMP и блочить эти сообщения – не помогло, через это правило трафик с сообщением редиректа не проходил.

Один пинг проходит и тишина – решение проблемы Системное администрирование, Пинг, Перенаправление, Сети, Маршрутизация, Длиннопост

Ну и были перечитаны кучи мануалов по отключению редиректа на WatchGuard – ничего рабочего не нашлось.


Как лечить в итоге:

На линухе лечится тремя командами (2 чтоб прям вот сейчас, одна, чтоб прям вообще).

Запрет приёма редиректа:

/sbin/sysctl -w net.ipv4.conf.eth0.accept_redirects=0

Запрет отправки редиректа:

/sbin/sysctl -w net.ipv4.conf.eth0.send_redirects=0

И чтоб вообще:

echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

Ну и может networking рестартануть, делала машинально.

При этом редиректы продолжают падать, но эффекта не оказывают:

Один пинг проходит и тишина – решение проблемы Системное администрирование, Пинг, Перенаправление, Сети, Маршрутизация, Длиннопост

На винде правится параметрами реестра, но эффекта до перезагрузки не оказывает (даже если выключить-включить сетевой интерфейс). Параметр в ветке

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

называется EnableICMPRedirect и выставляется в 0. По некоторым советам гугла (про Windows 2000 простихосподи), добавляла еще EnableICMPRedirects (во множественном числе). НО! После ребута сообщения redirect на машинах с исправленном параметром вообще не регистрируются WIreShark’ом, что меня несколько смутило (а вдруг вернутся?). Ну и ребутать over 100 серваков – такая себе идея.


Так что в итоге убрала маршрут 10.0.0.0/8 и добавила вместо него два:

10.0.0.0/10 и 10.64.0.0/11 – получились все сети от 10.0 до 10.95 включительно, а 97-ая, как видите, не вошла, что нас в принципе устроило. Проблема ушла.


То, что обычно пишут в начале поста:

Предыдущий мой пост на ИТ тематику был более 2 лет назад.

Чуть раньше этого я познакомилась на пикабу с классным чуваком, а полтора года назад мы поженились. Сисадмин и программист – норм сочетание оказалось =)


Я попробовала писать на хабр (мне даже одобрили аккаунт за тот пост), но мне не понравилось – на пикабушечке и аудитория поживее и можно не так цензурить текст.


А ещё наш офис вместе с серверной, которая уже стала мини-ЦОД для компании два раза за два года переехал. Если кому интересно – напишите в комментах, могу сделать пост о том, как происходит такой переезд, что мы планируем на каких этапах и т.д. На идеал не претендуем, происходит та ещё трешанина, но рассказать могу.

Показать полностью 3
316

Администрирование #05. DNS.

Я опять, как и в статье про DHCP, постараюсь идти от сильного упрощения к менее сильному упрощению. Статья ориентирована на уровень студентов и начинающих админов. Я не буду затрагивать вопросы безопасности или конкретной реализации, но постараюсь затронуть те вопросы, которые «проскакивают», либо вовсе игнорируют популярные статьи типа «что такое DNS».


Часть 1. История.


Наиболее увлекательное художественное описание того, как всё начиналось, доступно в rfc1034.

В давние времена, когда сети были маленькими, а компьютеры большими, кто-то заметил, что, во-первых, IP-адреса запоминать не очень удобно (гораздо удобнее слова, которые имеют смысл), а во-вторых, надо бы как-то обозначать один объект с несколькими сетевыми адресами.


«Давай запишем в текстовый файл соответствия сетевых адресов и понятных человеку имён» - сказал кто-то.

«А давайте!» - ответили остальные.


Сейчас вы можете найти файл «hosts» у себя на компьютере и посмотреть в него – почти так всё и было. Люди запоминали имя, запрашивали по имени ресурс. Система смотрела в файлике соответствие имени и сетевого адреса и возвращала по имени адрес. За файлик назначили ответственного, он вносил туда изменения и раздавал через файлообменник свежую версию всем желающим.


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


«Идите в жопу» - сказал ответственный.

«Вот дерьмо, как же быть?» - подумали остальные.


И придумали DNS – Domain Name System – систему доменных имён. Люди были не дураки. Они подумали: «если мы уж внедряем такую сложную систему, на которую потребуется выделить бабло, давайте запихаем туда всё, связанное с именованием ресурсов!». И запихнули.


Что получилось. Общий смысл остался – по имени возвращается адрес. Теперь доменное имя стало состоять из частей, разделенных точкой (Например, pikabu.ru) и за каждую часть (домен определенного уровня иерархии, уровни нумеруются справа налево) стал отвечать свой сервер имён со своим персональным ответственным (на самом деле, всё немного сложнее, разберем в следующих частях). Система стала распределенной и иерархической. Запрос адреса по имени стало возможным разбить на части, и, пройдясь по цепочке серверов имён, найти нужный с нужным ответом. Каждый ответственный теперь мог менять свой кусочек информации, независимо от остальных. В зависимости от настроек, эта информация становилась доступной для всех через некоторое время. К записи о домене добавили дополнительную информацию: информацию о почтовых серверах, о доступных ресурсах, о псевдонимах, служебную информацию и т.д. Корпорации теперь могли делать так, что изнутри на запрос отвечал один сервер имён, а снаружи компании на тот же самый запрос отвечал другой сервер и возвращал другой адрес.


Сформулируем, зачем нужен DNS:

1) Чтобы при вводе имени сайта, например, pikabu.ru, в браузере, система могла понять, на какой сетевой адрес «стучаться»

2) Чтобы при вводе синонима имени сайта www.pikabu.ru, система могла понять, что это имя всё равно, что pikabu.ru

3) Чтобы когда вы отсылаете письма с яндекса на gmail, сервер яндекса знал, на какой сетевой адрес отправить письмо, то есть, где искать почтовый сервер gmail’a

4) Чтобы в ответ, почтовый сервер gmail мог проверить, что адрес, с которого пришло письмо, принадлежит почтовому серверу яндекса.

5) Чтобы при каких-либо проблемах с данной системой, можно было узнать контакты ответственного лица и связаться с ним


«А давайте будем брать за запись о домене деньги?» - подумал кто-то хваткий. И в чьих-то глазах зажглись зеленые искры в виде долларов. Но это уже совсем другая история.


Часть 2. Домен, зона и другие страшные слова.


Отойдём от абстракций и перейдем к конкретике. Зона – это набор ресурсных записей домена, то есть, фактически – это информация о домене и вся та сопутствующая лабуда, о которой мы говорили в части 1. Причем, заметьте, домен в нашем случае, это не «pikabu», а именно «pikabu.ru», так как, скажем, «pikabu.net» - это уже совсем другой домен. Это как директория «помойка» может лежать у вас как на диске C:\, так и на диске D:\ и это будут две разные директории. Зона может быть текстовым файликом или записью в базе данных сервера имён.

Выглядит, примерно так (мне не жалко):

Администрирование #05. DNS. Системное администрирование, Для начинающих, DNS, Сети, Длиннопост

@ означает подставить имя домена целиком


Ресурсная запись (Resource Record – RR) - собственно, информация о некотором ресурсе- состоит из нескольких полей: Владелец, Тип, Класс, TTL, данные. Владелец – это домен, к которому запись относится. Тип может быть одним из стандартных (например, A, AAAA, MX, NS, SOA, TXT и т.д.). Класс раньше разделял записи для Интернет и для других сетей, сейчас, вроде, используется только IN для Интернет. TTL – время, на которое запись разрешено закэшировать резолверу (рекурсивному кэширующему серверу, см. Часть 3). Ну и данные – собственно нужная информация, формат которой зависит от типа записи.


Запись SOA (Start Of Authority) – это начальная запись зоны и она должна быть обязательно, потому остановимся на ней подробнее. В ней содержится целый ряд полей:


- Первичный (Primary) DNS-сервер для некоторой зоны — DNS-сервер, на котором хранится полная исходная информация об этой зоне.

- e-mail ответственного лица

- serial – серийный номер зоны. Фактически, это номер изменения файла зоны. Если у главного DNS-сервера, отвечающего за зону, есть подчиненные сервера, то они периодически сравнивают номер копии зоны у себя с номером на главном сервере. Если на главном номер больше – подчиненные сервера обновляют у себя зону.

- refresh – это то, как часто подчиненные сервера будут пытаться обновить зону

- retry – это то, как часто подчиненные сервера будут пытаться обновить зону, если в первый раз произошла ошибка (например, главный сервер был недоступен)

- expire – то, сколько времени подчиненный сервер может считать информацию о зоне актуальной, если главный сервер ему так и не ответил

- TTL – мы уже говорили – на сколько можно закэшировать запись.

Администрирование #05. DNS. Системное администрирование, Для начинающих, DNS, Сети, Длиннопост

NS – записи содержат сведения о DNS-серверах, где хранится информация о зоне (их может быть больше одного).

Администрирование #05. DNS. Системное администрирование, Для начинающих, DNS, Сети, Длиннопост

А – запись связывает имя с IPv4 адресом. Кстати, если сделать несколько записей с одним именем, но разными адресами, то в ответах они будут чередоваться (чаще всего по алгоритму round robin) – поэкспериментируйте на pikabu.ru и его трех адресах ;)


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

Администрирование #05. DNS. Системное администрирование, Для начинающих, DNS, Сети, Длиннопост

Чуть позже рассмотрим еще PTR записи. Ну а про остальные, если интересно, можно прочитать в вики.


Часть 3. Как идёт запрос.


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


Вы уже поняли, что в системе есть DNS-сервера – сервера имён, на которых хранятся файлы зон. Есть клиенты, которые пытаются узнать адрес по имени (браузер, в котором мы шароебимся по сайтикам, например).


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


Вспоминаем, что система DNS иерархическая. У этой иерархии есть вершина (или корень) – корневая зона, за которой зарезервировано нулевое имя, и за которую отвечают корневые сервера. Эта зона невидимо присутствует во всех доменных именах - на самом деле, все они заканчивают на точку-ничего (можно посмотреть на первую картинку с файлом зоны и увидеть эти точки). Корневые сервера содержат информацию о доменах первого уровня (ru, com, net и т.д.). Этих серверов всего 13 штук (но физически их гораздо больше – резервирование, распределение нагрузки, всё такое). Почему 13? Так исторически сложилось: тогда максимальное количество данных в пакете было 512 байт и туда влезало только 13 записей. Корневые сервера нерекурсивные и некэширующие, кстати.


И сейчас я кратенько перескажу тот самый комикс. Итак, вы вводите в своем любимом браузере адрес любимого сайта pikabu.ru – что же происходит с точки зрения DNS?


1) Браузер роется у себя в кэше – может, вы недавно уже заходили на пикабу и он это еще помнит. Если нет, идем дальше.


2) Потом браузер обращается с животрепещущим вопросом «где же pikabu.ru?» к операционной системе. Она проверяет в своём кэше (может, вы недавно пинговали пикабу?) и в файлике hosts. Если не нашла, передает вопрос тому серверу, который у вас указан на компьютере в качестве DNS.


3) Этот сервер, обычно, сервер провайдера, кэширующий и рекурсивный. То есть, он вернет вам адрес сайта или ошибку. Сначала он проверяет свой кэш (может, ваш сосед по общаге только что запрашивал пикабу?). А еще смотрит в своих зонах (может, он за пикабу и отвечает?). Если ничего не находит, этот сервер начинает собирать ответ, используя нерекурсивные запросы.


4) Первым делом, запрос отправляется на ближайший корневой сервер (вру, там еще есть манипуляции с кэшем, но мы их опустим - пусть ничего нигде не найдено). Адреса корневых серверов известны и меняются очень редко, так что они просто забиты руками во все DNS-сервера. Корневой сервер отвечает, что он в душе не знает адреса «pikabu.ru», но вот тебе список серверов, отвечающих за «ru». Кстати, возвращает он имена и «приклеенные» ip-адреса, а то вы могли бы зациклится в своих запросах.

Администрирование #05. DNS. Системное администрирование, Для начинающих, DNS, Сети, Длиннопост

Кстати, слышали, что rpin вроде как передает права на управление зоной ru Ростелекому?


5) Ок, наш сервер сохранил инфу в кэше (и теперь за всеми сайтами, заканчивающимися на .ru будет обращаться уже к этим серверам). Берет верхний сервер из списка и спрашивает его, где же «pikabu.ru»? Ему отвечают списком из трех адресов, он возвращает верхний операционной системе. Все счастливы, все прописали себе в кэш, что могли, подключаемся к этому IP-адресу и читаем пикабу.


Часть 4. Обратная зона.


Случается так, что нам нужна обратная процедура: не по имени узнать адрес, а по адресу имя. Такие запросы, в частности, используют почтовые сервера, чтобы бороться со спамом. То есть, приходит нам письмо от vasya@gaza.net, например, с адреса 1.23.45.6. И мы хотим узнать, а правда ли адрес 1.23.45.6 является адресом почтового сервера этого домена. Для этого нам надо получить имя по адресу 1.23.45.6 и сравнить его с MX-записью домена (кто заморачивается почтовиками, почитайте еще про spf обязательно).


Для преобразования ip-адресов в имена существует специальный домен in-addr.arpa и специальная запись типа PTR. Как это выглядит, видно на скриншоте. У пикабу, кстати, какая-то лажа с его гуглопочтой, так что пример на другом домене (надеюсь, они не обидятся). Обратите внимание, что IP-адрес переворачивается (задача для самостоятельного раздумья – вспомнить про адресацию и понять, почему).

Администрирование #05. DNS. Системное администрирование, Для начинающих, DNS, Сети, Длиннопост

Часть 5. Внутренняя зона – что за зверь?


Это немножко вбоквел. Например, вы зарегистрировали домен не для себя, а для компании. В компании решили организовать доменную структуру (AD поднять, например). И для этой доменной структуры у вас появляется внутренняя зона DNS. Зона, причем, может быть та же самая, что и в инете, но к той интернетовской зоне она не будет иметь никакого отношения. У вас появляются контроллеры домена (или иные DNS-сервера – держатели внутренней зоны) в вашей локальной сети. На всех компьютерах вашей организации в качестве DNS-серверов вы указываете контроллеры домена (на которых поднята роль DNS). Во внутренней зоне находятся записи внутренних ресурсов: все компьютере в домене, внутренние web-порталы, и т.д. На DNS-серверах корпорации указаны «Forwarders» - сервера, на которые пойдет запрос, если ответа не найдется во внутренней зоне (это уже сервера провайдера, обычно).


Ну, предположим, что pikabu.ru – большая корпорация, в которой есть доменная структура и вы в этой корпорации работаете. Если вы изнутри этой зоны (сидя на работе) выполните команду «nslookup pikabu.ru», вы получите список внутренних DNS-серверов компании, а на сайт пикабушечки не попадёте. Всё потому, что вам ответит внутренний сервер компании, в котором прописано, что «pikabu.ru – это ж я сам и есть, а еще все мои дублирующие сервера!». А вот если вы выполните эту команду из дома, получите внешние адреса пикабу – потому что вам ответит DNS-сервер хостинг-провайдера.


Теперь, предположим, вы с работы набрали www.pikabu.ru. Допустим, у вас в корпорации нет компа с именем www и внутреннего ресурса такого тоже нет. Корпоративный DNS не найдет у себя в зоне записи www и перенаправит запрос на адрес форварда. Мы помним, что это адрес сервера провайдера. И вот тут ответ будет идентичный, что изнутри, что снаружи корпорации, потому что мы искали во внешней зоне.


И третий вариант, у вас в домене есть компьютер W01-vasya-PC.pikabu.ru. Изнутри компании вам внутренний DNS вернет его внутренний адрес. А вот запрос извне "Где W01-vasya-PC.pikabu.ru?" вернет вам "такого хоста не существует" - потому что DNS хостинг-провайдера, где находится ваша внешняя зона pikabu.ru (и куда в конце-концов дочапает DNS-запрос) понятия не имеет о вашей внутренней зоне.


Часть 6. Интересные факты:


Сейчас для распределения нагрузки на корневые сервера используется anycast – это такая публикация маршрутов в сети (BGP), при которой, вам ответит географически ближайший сервер, а не тот, до которого маршрут по некоторым причинам короче.


Максимальное имя поддомена 63 символа, максимальное общее доменное имя 255 символов.


Обычно, обратную зону надо просить прописывать своего провайдера. Но есть вариант, при котором провайдер делает у себя пару записей, а вы после этого можете менять PTR-запись прям у себя в админке родного DNS от хостинг-провайдера (ну, насколько я поняла). Статья вот.


P.S.: Что-то дофига получилось, мда. Надеюсь, кому-то стало понятнее. Правки по существу приветствуются.

Показать полностью 6
199

План адресации в учебных сетях - выдумка или реальность

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

Всё, что я здесь напишу – это сугубо моё личное мнение, которое не претендует на истину в последней инстанции. И да, тут будет много поясняющей воды.


Зайду издалека. Если вы проходите что-то связанное с сетями (или посещаете курсы, а может просто решили сварганить тестовую среду с друзьями под пивко), то рано или поздно дело доходит до практики – построения сети на живом оборудовании или во всяких там эмуляторах. Я сейчас буду рассматривать пример лабораторной в университете/на курсах. Итак, на доске рисуется некоторая схема сети, а дальше у нас два варианта:


1) Преподаватель расписывает всю-всю адресацию (рис.1)


2) Преподаватель расписывает концептуальное задание, а адресация остается на ваше усмотрение (рис.2)

План адресации в учебных сетях - выдумка или реальность Системное администрирование, Сети, Для начинающих, IT, План, Длиннопост
План адресации в учебных сетях - выдумка или реальность Системное администрирование, Сети, Для начинающих, IT, План, Длиннопост

Первый вариант понятен – за нас уже подумали. Но не факт, что хорошо (и мы всегда можем предложить свой вариант с преферансом и гимназистками – вдруг прокатит). Рассмотрим плюсы и минусы конкретного примера с рисунка 1 (синие кружки – хосты, оранжевое – линки, зеленое – сеть на самом хосте и «за ним»).


Плюсы:

1) Препод делал эту лабу раз 800 именно в таком виде и может отдебажить с закрытыми глазами

2) Возможно, у него уже написана методичка под эту адресацию.

3) В принципе, одинаковые IP для хостов (192.168.х.1) – это удобно.


Вообще, на мой взгляд, плюсы на этом заканчиваются (да и то: два из них для преподавателя, а третий сомнителен) и начинается полная Ж для нас:


1) Если вы видите и делаете эту лабу первый раз, у вас все десятые айпишники сливаются перед глазами. Мы делали во второй раз – просто при конфигурации интерфейсов на 4 человека и восемь интерфейсов было сделано три ошибки с перепутанной единичкой/двойкой.

2) При прописывании маршрутов эти описки множатся

3) Дебажить – просто ад. Постоянно пялиться на схему, сверять сети. Сети опять сливаются перед глазами. На слух тоже плохо воспринимаются адреса.

4) При усложнении конфигурации (добавлении пары ликнов, как на рис.2) вообще пропадает логика адресации. Только схема, только хардкор.


Подход, тем не менее, очень часто используется и имеет право на жизнь. Но теперь представьте, что вы уже не на первом курсе. У вас не 4 хоста, а 14, по числу студентов в группе и соединены они не по кругу, а как попало (рис.3). И задачи у вас посложнее.

План адресации в учебных сетях - выдумка или реальность Системное администрирование, Сети, Для начинающих, IT, План, Длиннопост

Немного вбоквел. На прошлой неделе я счастливо посещала курсы, на которых мы в очередной раз не сошлись с преподавателем в некоторых концептуальных вопросах. Его мнение – не стоит тратить время на такие глупости, как выбор толкового плана адресации, не надо усложнять, надо скорее делать, так как время не резиновое. Моё мнение – один раз расписать логику адресации (я делаю это уже на автомате и быстро), зато снизим ошибки конфигурации и облегчим дебаг. Победил преподаватель, расписав схему а-ля рис.1. Роман, если читаешь, извини, что я так громко возмущалась, но я до сих пор не согласна. Конец вбоквела.


Сейчас несколько общих советов, годных для любого плана адресации:


1) План адресации вам всё-таки нужен, иначе обязательно пойдут пересечения сетей, особенно «популярных», вроде 10.1.1.0/24


2) Выбирайте строго одного человека, который выберет план адресации, пусть даже хреновый. Время принятия решения возрастает в степени количества участников (один человек – 5 минут, 3 человека – 5^3=125 минут)


3) Не мельчите сетки и указывайте популярные маски, если иное не обозначено условиями задачи. В учебной сети нет цели сэкономить адреса. Помните, что вокруг вас люди, которые даже с калькулятором сетей не особо представляют себе, как одна сетка /25 делится на две /26. Короче, /24 – ваш безусловный выбор (если только вы не проходите тему агрегации сетей).


Теперь посмотрим на рис.4 – Это бывший рис.2 с расписанной альтернативной адресацией. И сейчас будут конкретные советы.

План адресации в учебных сетях - выдумка или реальность Системное администрирование, Сети, Для начинающих, IT, План, Длиннопост

В данном случае, план адресации сформулирован правилами:


1) На сеть между двумя хостами X и Y назначается адрес вида 10.1.XY.0/24, где X – номер меньшего по номеру хоста, а Y – адрес большего по номеру хоста.

2) На хост X назначается адрес 10.1.XY.Х/24, на хост Y адрес 10.1.XY.Y/24

3) VLAN между хостами имеет номер XY

4) Адрес сети за хостом имеет адрес вида 192.168.100+X.0/24

5) Адрес хоста во внутренней сети назначается 192.168.100+X.Х/24


Эта сеть легко расширяется. 100+Х мы брали, чтоб не пересечься с популярной дефолтной сеткой 192.168.1.0/24, на которой, скорее всего, висит сеть с инетом.


А внимательный пикабушник посмотрит на рисунок 3 и скажет, что данная схема нормально расширяется только до 9 хостов, а дальше мы имеем вероятность вылезти за рамки числа 254 в XY. НО! У нас же остался неиспользованный октет!


В сети более, чем на 9 хостов используйте правила:


1) На сеть между двумя хостами назначается адрес вида 10.X.Y.0/24, где X – номер меньшего по номеру хоста, а Y – адрес большего по номеру хоста.

2) На хост X назначается адрес 10.X.Y.Х/24, на хост Y адрес 10.X.Y.Y/24


Пример с рис.3: На линке между 12 и 9 хостами будет сеть 10.9.12.0/24, на 9ом будет адрес 10.9.12.9/24, а на 12ом 10.9.12.12/24.


И ещё несколько советов:

1) Используйте как можно более разные сети для связей разной природы. Скажем, 10.1.XY.0/24 для физических линков, а 172.16.XY.0/24 для навешивания на GRE туннели.

2) В схеме 10.X.Y.0/24 у вас еще есть запас сетей 10.100+X.100+Y.0/24

3) Аккуратно относитесь к номерам VLAN, если нумеруете хосты с нуля. VLAN 1 занят под native. И за к номерам за 1000 тоже аккуратно относитесь, лучше сделать пару исключений из логики, если пошли такие VLAN’ы.


Что мы получаем: Зная только номера хостов соседей можно спокойно расписывать себе адреса, пока они там телятся. Глядя только на схему с хостами и связями, можно прописывать на своей стороне уже всё, что надо (и не надо расписывать на доске адресацию по всем 14 хостам). В любом месте, запуская tcpdump (или аналог), мы по прилетающим адресам точно можем сказать, откуда они прилетели и быстро найти это место.


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


Собственно, вот и всё, чем хотелось поделиться. Выбирать из этих или придумывать свой вариант – решать вам.

Показать полностью 3
63

Ужасы в картинках

В продолжении поста картинки лабораторных по сетям.

Статическая маршрутизация (каждая точка – хост, каждый хост – студент):

Ужасы в картинках Сети, IT, Образование, Маршрутизация, Длиннопост

Экзамен на 5 курсе:

Ужасы в картинках Сети, IT, Образование, Маршрутизация, Длиннопост

Он же, то уже с «розданными» мною подсетями и в процессе настройки:

Ужасы в картинках Сети, IT, Образование, Маршрутизация, Длиннопост

Ёлочка на старшем курсе, снеговик – на младшем:

Ужасы в картинках Сети, IT, Образование, Маршрутизация, Длиннопост

Мануал по тому, как коммитить диплом:

Ужасы в картинках Сети, IT, Образование, Маршрутизация, Длиннопост

И небольшое заключение:

Сегодня день рождения у нашего бывшего преподавателя по сетям. Месяца не проходит, как вспоминаю его добрым словом. Он дал отличную базу в плане образования, он никогда не отказывал в помощи студентам (как по учебе, так и моральной, и материальной, вроде поддержки проектов). Он никогда не кричал на нас, максимум бился головой об стол =) Никто не смог выиграть у него зачёт в Warcraft. Он научил меня играть в преферанс и кучу народа в настолки. Спасибо!

Показать полностью 3
2762

Про собеседования в ИТ

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


Приходят люди наниматься на работу системным администратором, им начинаешь задавать вопросы, а они отвечают что-то типа «это всё теория, я её может не очень хорошо знаю, но на практике вы мне дадите задание и я всё настрою». Так вот, это херня.


Если вы не можете сказать, зачем нужна маска подсети, что такое «шлюз по умолчанию» и первый раз слышишь о таблице маршрутизации, то, честное слово, вы не справитесь. Вам ни о чем не скажут слова «у вас сеть такая_то/16 на филиал, по допофисам рулите сами», вы не поймете, почему нет доступа куда-то именно с этого компа и т.д.


Можно ли поднять в одной локальной сети 2 DHCP-сервера, обоснуйте ответ. Опять, «ну это теория, так то я подниму». Да-да, пройти мастер и нажать три раза «далее» и обезьяна сможет, не спорю. Но у тех, кто не может ответить на этот вопрос нет понимания, как работает DHCP. Именно у них идут конфликты IP-адресов, именно они не могут всем массово поменять DNS-сервер. Для них откровение, что можно передать ЕЩЁ какие-то настройки. А если, внезапно, нужно поднять DHCP не на винде и там нет мастера, который заботливо задаст вам все вопросы, то всё – тушите свет.


Обжим кабеля по цветам наизусть. Мы всё понимаем, век мобильного интернета и доступности информации (особенно, в отдаленном пункте на Ямале/Чукотке и т.д. *sarcasm*), но у вас в резюме «монтаж ЛВС/СКС» и опыт 2 года. Вы, извините, по листочку два года обжимали? 20 патчиков и вы никогда этого не забудете, проверено.


Камень преткновения. Хаб и свич. К сожалению, не догадались сразу записывать, а то бы можно было издать юмористический сборник «Отличие хаба от свича. 50 укуренных мыслей». Основной аргумент, что хаб – устаревшее оборудование и им никто не пользуется, потому и знать о нём не надо. И всё бы так, если бы кто-то из тех, кто приводит этот аргумент смог бы сформулировать, чем же всё-таки занимается свич (то есть, что он делает, как именно и нафига вообще нужен). Зачем?

- Я заблокировал ресурс А на роутере, а на него всё равно все мои пользователи попадают.

- Ресурс А находится в той же локальной сети, что и пользователи?

- Да

- Всё отрабатывается на канальном уровне, через роутер этот трафик вообще не проходит

- Ну они ж по IP заходят

И начинаешь рассказывать человеку, как свич работает, что такое ARP-таблица и прочую «теорию».


Мы всё понимаем, любую информацию можно нагуглить. Но как человек предполагает этим заниматься, если не понимает, о чем идет речь? Гуглить «курс по сетям для чайников»? А почему почему бы не сделать это до собеседования? А я знаю, что будут делать в итоге – звонить мне и говорить «сломалось/настройте/не понимаю, сделайте». И никто так и не выяснит, нафига же айпишнику нужна маска…


Раньше у нас были лайтовые собеседования – вопросы из разряда «Знаешь это? –Знаю». и никакой конкретики, никакой «теории». Регулярные звонки из филиалов с элементарными вопросами. Админ даже локализовать проблему не может. И если вы думаете, что не было инструкций и лекций, то вы ошибаетесь. Есть и «мануал начинающего админа» и «трактат о сетях для самых начинающих». Просто их никто не читал (ё-моё, 15 страниц с картинками, где ж тут успеть!). Года два назад мы стали практиковать «жесткие» собеседования и сейчас стало натурально лучше. Народ может решить проблемы самостоятельно, иногда лучше/быстрее нас. И ещё одна закономерность: те, кто смог ответить на «теоретические» вопросы, читает мануалы и инструкции. Совпадение? Не думаю.


И да, мы не задираем планку там, где зарплата меньше средней в ИТ по региону. Но хоть немного ориентироваться в теме необходимо, чтобы мы не летали в этот регион в командировки каждые пару месяцев и не висели на телефоне с одними вами весь день. Просто десяток-полтора статей по теме можно же было прочитать за 5-10 лет админства, которые указаны у вас в резюме. Для ответа на 7 из 10 вопросов этого хватит, а 7 – это очень крутой показатель.


Надеюсь, что кому-то это прояснит ситуацию, кого-то сподвигнет прочитать тот самый десяток статей.


P.S.: пост по теме ИТ первый, будет ли еще – не знаю. Подозреваю, что сильный интерес тема не вызовет.

Показать полностью
Похожие посты закончились. Возможно, вас заинтересуют другие посты по тегам: