Ответы пользователя по тегу Компьютерные сети
  • Как получить данные через интернет от компьютера?

    athacker
    @athacker
    Настройте с домашнего компа регулярную отправку данных с домашнего компа в сторону сервера в интернете по расписанию. ЧТобы соединение инициировал домашний комп.
    Ответ написан
  • Как заставить apache/nginx под докером работать вместе с локальным nginx?

    athacker
    @athacker
    Товарищ выше в целом верно говорит, только не обязательно для этого docker-compose использовать. Запустите контейнер со старым приложением с указанием ключа -p 8080:80. Тогда 80-ый порт контейнера будет доступен на 8080 порту хоста. Соответственно, снаружи можете подключаться к этому порту: http://my_host_ip:8080 -- и попадёте в своё старое приложение.
    Ответ написан
  • Какими знаниями должен обладать начинающий сетевой инженер?

    athacker
    @athacker
    У Cisco масса учебных курсов и книжек. Например, есть курс ICND (Interconnecting Cisco network devices), в двух частях. Пусть слово "Cisco" в названии вас не смущает -- курс более общий, просто примеры на базе цисок даются. Если осилите -- будет проще разбираться и с любым другим оборудованием. Следующим шагом может бытькурс Cisco "Routing and switching", например.

    P/S/: Если вы в Москве, то книжку по курсу ICND 1 могу вам отдать безвозмездно, у меня тут завалялась.
    Ответ написан
  • В чем основное различие между trank портом и access портом?? кроме tagged это понятно?

    athacker
    @athacker
    ОСНОВНОЕ отличие -- именно в этом. Что trunk порт может гонять тегированный трафик нескольких вланов, а аксесс порт будет принимать/отправлять нетегированный трафик, принадлежащий только одному влану (трафик как принадлежащий влану будет маркироваться только внутри коммутатора).

    Неосновное отличие -- trunk-порты могут поддерживать протоколы автоматического согласования режимов/VLAN'ов. Это протоколы DTP или VTP.

    Коммутаторы можно связывать акцесс-портами в том случае, если вы стыкуете две инфраструктуры с пересекающимися вланами. Такой кейс возникает у интернет-провайдеров, например. Когда нужно подключить коммутатор клиента, и у вас на этого клиента выделен влан, скажем, 666. Но у клиента этот влан уже используется. Вы не можете ломать свой VLAN план, и клиент не может. Тогда вы настраиваете порт в сторону коммутатора клиента на 666 влан акцессом, а клиент на своей стороне настраивает акцесом порт в том влане, который у него выделен как стыковочный. Ну, к примеру, 777. И получается мир-дружба-жвачка, и все работают согласно своим VLAN-планам без всяких проблем. Но технически получается, что два коммутатора подключены акцесс-портами.
    Ответ написан
  • Нужно ли создавать отдельные зоны DNS для каждого VLAN?

    athacker
    @athacker
    Структура прямых зон полностью зависит от ваших задач. Если вам нужны отдельные зоны под каждую подсеть -- создавайте отдельные зоны.

    Обратные зоны (PTR) же всяко придётся создавать для каждой подсети отдельно.
    Ответ написан
  • Как настроить группы портов на ESXi 5.0 и получить доступ к виртуальной машине?

    athacker
    @athacker
    У вас настроен distributed vSwitch. Что намекает на присутствие где-то в схеме vCenter. Потому что без него такой свич не собрать. И управлять им, соответственно, тоже нельзя без vCenter. Вы же подключились напрямую на хост, насколько я понимаю, и пытаетесь что-то там делать. Это не пройдёт.

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

    Либо забэкапьте машины, перепишите настройки сетей (наименования портгрупп и вланы, а также какая машина в каком влане должна быть) снесите гипервизор, и выстраивайте систему с нуля на одном физическом хосте и standard vSwitch. Потом восстановите машины и подключите их к нужным сетям.

    P/S/: Да, и для информации. Свичи в гипервизорах маршрутизацией не занимаются, это чисто L2 "устройства". Маршрутизация в вашей сети выполняется либо виртуальной машиной, либо отдельной железкой-роутером.
    Ответ написан
  • Какой поставить маршрутизатор в конторе на 60 устройств?

    athacker
    @athacker
    Вот, например, хорошая штука: https://mikrotik.com/product/RB3011UiAS-RM
    И на вырост хватит.

    Коммутаторы нужно ставить только управляемые. У микротика тоже есть, так что можно моно-вендорный конфиг собрать.
    Ответ написан
  • Как разделить resolve различных имен между двумя интерфейсами к разным DNS серверам?

    athacker
    @athacker
    Вам нужно свой DNS-сервер ставить. Который может и внешние имена резолвить, и внутренние. Например, так умеет делать Unbound. По дефолту он резолвит всё через корневые NS, но можно сделать local zone, и прописать там локальные хосты. Тогда по этим именам Unbound будет отдавать то, что прописано в local zone.
    Ответ написан
  • Вопрос по разделению VLAN?

    athacker
    @athacker
    У вас основной трафик будет ходить между серверами, терминалами и сервером бэкапов. Всё остальное -- это копейки, по большому счёту. Ну, ещё 15 камер с хорошим качеством могут подгрузить. Ну хотя тоже, даже если там 2 мегабита на камеру, то в сумме получится 30 Мбит/сек. На гигабитном линке -- тоже не очень много.

    Как вариант -- собрать на микротике LAG. Если на микроте 5 портов, то один порт отдаём в WAN, два порта -- LAG в сторону коммутатора 1, и оставшиеся два порта -- LAG в сторону коммутатора 2. Таким образом трафик каждого коммутатора будет падать на два порта микротика, и в сумме можно получить 2 гигабита. Ну т. е. понятно, что у вас любая коммуникация не может быть больше 1 гигабита, но суммарно можно прокачать и 2 (из разных вланов в разные вланы).
    Ответ написан
  • Есть ли смысл разделять принтеры, телефоны, компьютеры по отдельным VLAN'ам?

    athacker
    @athacker
    Логика правильная. Номера вланов значения не имеют, но выделять однотипные устройства в отдельные сети -- это правильно и хорошо. Связность между вланами обеспечивается также, как и между отдельными физическими сетями -- с помощью маршрутизатора. Почитайте, что такое VLAN trunking, и ознакомьтесь, как это реализуется на микротиках, и настраивайте маршрутизацию на нём.

    Сегментация сети -- это не просто правила хорошего тона, это необходимость, особенно в свете развития малвари/вирусов и прочих угроз ИБ. Принтеры/телефоны -- легко уязвимые устройства, поэтому их нужно изолировать. Плоская сеть, где все компы организации находятся в одном влане/сетевом сегменте приведёт к тому, что любой залётный NotPetya распространится по всей сети в считанные минуты. И будет как здесь. Или мамкины хакеры какие-нибудь начнут ковырять компы соседнего отдела по сети. Так что сгементация и настроенные правила хождения трафика между подсетями -- это must have в современных условиях.
    Ответ написан
  • Как защитить коммутатор от L2 петли без отключения избыточного линка?

    athacker
    @athacker
    Придётся всю систему менять. Либо переделывать отдачу трафика на "анализатор" (вы, я так понимаю, строите IPS?) через маршрутизацию, т. е. выносить на уровень L3. Либо подавать на анализатор копию трафика через SPAN, а анализатор должен отстреливать spoofed-пакетами TCP RST в сторону клиента, прикидываясь сервером если соединение признано подозрительным. Тогда клиент будет сразу закрывать соединение.

    Но отвечая на прямым образом поставленный вопрос -- защитить коммутатор от отключения избыточного линка можно настроив, например, port-channel на этих линках (между коммутаторами). Однако очевидно, что это не ваша история, и вам этот вариант не поможет. Так что остаётся только менять систему.
    Ответ написан
  • Защита от ддос для домашнего сервера?

    athacker
    @athacker
    Да не смешите, какие атаки на домашний сервер? Да ещё DDoS. Одинокие попытки подключиться на SSH? Это не DDoS, это боты сканируют сети в поисках жертв. Перенесите SSH на нестандартный порт повыше (>1024), и "атаки" прекратятся.
    Ответ написан
  • Я правильно понимаю, Россию собираются вообще изолировать от "мирового интернета"?

    athacker
    @athacker
    Нет, неправильно.

    Часть законов, которыми пытаются регулировать интернет в последнее время -- это бред и дурь, конечно. Например, закон Яровой -- это полный трэш. Он нереализуем технически.

    А вот закон, который ограничивает иностранных участников во владении магистральными точками обмена трафика на территории РФ, или закон, который призван обеспечить маршрутизацию локального трафика только через сети РФ -- с точки зрения управления рисками вполне оправданы, в текущей политической обстановке. И речь даже не только про изоляцию, а ещё и про то возможность контроля трансграничного трафика. Ландшафт угроз сейчас такой, что это технически сложная, но необходимая мера. И в той или иной степени, этим занимаются все государства, в меру наличия технических/финансовых стредств для этого. Контроль не на предмет "лайков и репостов", а на предмет реальных угроз для критической информационной инфраструктуры (см. 187-ФЗ).

    Другой вопрос, что реализация может быть кривая, ну и как любой инструмент, этот закон может быть использован и во зло. Равно как и молотком -- можно по башке кого-нибудь приложить. Но вообще-то это инструмент для строительства.

    Даже закон, дающий РКН право блокировать ресурсы -- тоже скорее полезен, нежели вреден. Потому что 99.999% списка блокировок -- это сайты с продажей наркоты, притоны, бордели и онлайн-казино. Политики там -- тысячные доли процента. Да, реализация блокировок хромает на обе ноги. Да, методика внесения в списки и особенно удаления из списков -- хромает ещё сильнее. Но в целом -- инструмент нужен, просто нужно было хорошенько продумать все механизмы и методику, прежде чем запускать всё в дело. У нас, к сожалению, часто начинают с принятия закона и запуска его в действие, а потом -- "авось как-нибудь оно само всё обустроится".

    Возвращаясь же к законопроекту об автономной работе рунета, то на мой взгляд, есть как минимум три проблемы, которые он должен решать:

    1) Контроль пиринга. Часто провайдеры не в состоянии договориться о прямом обмене трафиком между своими абонентами. И тогда реально получается, что трафик из одного офиса Москвы в другой ходит через AMS-IX, например. Чаще всего причиной недостижимости договорённости является жадность :-)

    2) Создать автономну DNS-инфраструктуру. Сейчас проблема частично решена, т. к. на территории РФ есть корневые NS-сервера.

    3) Иметь свои удостоверяющие центры для реализации PKI. Сейчас в России можно создать PKI, но никто из вендоров ПО не будет его добавлять в списки доверенных. Но можно в законе предусмотреть такое требование. И тогда, опираясь на этот закон, можно будет прессовать вендоров, мотивируя это тем, что "хотите вести бизнес в России -- будьте добры расширить список доверенных УЦ". Ну а со временем этот УЦ попадёт во все такого рода списки, в том числе и зарубежом. В текущей же ситуации, если каким-то образом будет нарушен доступ к серверам зарубежных УЦ (Comodo, Let's Encrypt, DigiCert. Thawte), то проблем у информационных систем внутри РФ возникнет немало, т. к. куча сервисов просто перестанут работать из-за невозможности проверить валидность сертификатов.
    Ответ написан
  • Как сделать редирект на локальный адрес, когда нет интернета (squid и bind)?

    athacker
    @athacker
    Это проще файрволом на шлюзе сделать. При отсутствии интернета делать DST NAT любых запросов на 80/443 порты на локальный веб-сервер с заглушкой.

    DNS'ом тоже можно. Но в DNS клиентах есть кэш, поэтому пока TTL записи не истечёт, клиенты будут пользоваться кэшом, и обращаться к DNS-серверу не будут. Соответственно, при отсутствии интернета они никакую заглушку не увидят.
    Ответ написан
  • Как лучше организовать IT-инфраструктуру предприятия?

    athacker
    @athacker
    1) фольгированная витая пара -- только между этажами. С обязательным заземлением, иначе толку от неё не будет. В остальном можно разводить обычной UTP без экранирования;

    2) Коммутаторы должны быть на каждом этаже. Не хватает 16 портов -- ставьте 24-портовые. Не хватает 24-портовых -- ставьте по 48. Но реально жить будет проще, если у вас коммутаторы доступа будут стоять на каждом этаже. Потому что тогда вам можно будет купить менее ёмкие коммутаторы агрегации и поставить их в серверной. Менее ёмкие -- потому что туда не все на свете компы будут сведены, а только коммутаторы доступа. Подключение каждого коммутатора доступа к агрегации -- двумя линками, в ether-channel, для резервирования;

    3) Citrix XenServer... Ну такое... Посмотрите на картинку и найдите там XenServer:
    Virtualization%20usage%20by%20company%20

    4) "SSD в рейд-массивах не дает преимуществ" -- шта? О_о Собирать SSD в RAID10 -- несколько расточительно. Хотя, конечно, если у вас бюджеты не ограничены... Я бы собирал массив так -- как можно бОльшее количество дисков небольшого объёма, которые бы уже собирал в RAID6 или RAID60 (в зависимости от количества дисков и потребных объёмов). Вот шпиндельные диски -- их имеет смысл в RAID10 собирать, т. к. больно медленные. Но подход тот же самый -- диски меньшего объёма, но в большем количестве. В последние годы я постоянно наблюдаю ситуации -- есть до фига объёмов, но не хватает производительности. Обратное -- производительность есть, но мало объёмов, пока не попадалось. Отсюда рекомендация брать диски поменьше, но количеством побольше. Хотя всё зависит от задач, конечно. И от бюджетов.

    Да, и "RAID-массив в стойку" не поставить. Поставить можно железку. Какую-то. Промышленную СХД, например. Или самосборное хранилище (считай, обычный сервер, с линукс или FreeBSD на борту, настроенный на отдачу объёмов по какому-то storage-протоколу). Или корзину DAS. Или NAS. Перечислены в порядке предпочтения. Опять-таки, всё зависит от бюджета.

    5) ИБП нужно брать с запасом не 50%, а 100% или даже 200%. Потому что когда вы докинете ещё серверов, то ваши 50% будут съедены моментом. Или когда у вас нагрузка поднимется, то тоже начнёте упираться в потолок мощности ИБП. А то, что нагрузка будет расти и сервера придётся добавлять -- это к бабке не ходи. Поэтому брать нужно с большим запасом, не менее 100%. Как вариант -- брать ИБП, к которым можно подключать внешние блоки батарей. Но мощность ИБП всё равно должен иметь с запасом не менее 100%.

    6) Датчики влажности, температуры без регистрации и SMS и возможность отправки SMS-сообщений лучше реализовать с помощью устройств типа UniPing server v3/SMS. Датчиков там отдельно можно докупить всеразличных, вплоть до инфракрасных управлялок для кондиционеров в серверной.

    7) RAID-ы в виртуалках -- это бред, конечно же. Достаточно обеспечить отказоусточивое дисковое хранилище. Лучше всего с отказоустойчивостью дела обстоят у промышленных СХД, конечно же. HPE MSA, Dell MF -- вот это вот всё.

    8) Правила распределения сервисов по виртуалкам очень простое -- один выстрел -- один труп сервис -- одна машина. Т. е. под почтовый сервер -- одна виртуалка. Под DNS -- ещё машина. Даже две. Под контроллеры доменов -- две виртуалки (минимум). Под DHCP -- ещё машина.

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

    XXX+1) Да, и про резервное копирование не забудьте. Чем бэкапить, и куда складывать. Hint: складывать на ту же хранилку, на которой виртуалки работают -- моветон и чревато печальными последствиями.
    Ответ написан
  • Какова суть псевдо-интерфейса Null0 на Cisco IOS?

    athacker
    @athacker
    Это /dev/null для маршрутизации. Пакеты, которые маршрутизируются в Null0 -- фактически, просто дропаются.

    Такой подход используется в разных целях. Например, вам нужно заблочить мощный поток трафика на определённую подсеть, для которой вы -- транзит. Такой поток может быть, например, DDoS'ом. Блочить такое на файрволе -- может быть довольно дорогим удовольствием, с точки зрения используемых системных ресурсов. Поэтому сетку просто блэкхолят. В разных системах это по-разному называется -- в IOS это Null0 (и то, возможно, не во всех модификациях), во фре -- так и называется, blackhole.

    Для NAT сам по себе этот интерфейс роли большой не играет, но его могут использовать. Например, у вас на устройстве нат для какой-то сетки. Сетка вам анонсируется по какому-нибудь протоколу динамической маршрутизации. Допустим, сессия динамической маршрутизации сломалась, и пользовательская сеть больше не доступна. Но на файрволе остались NAT-правила для неё. Соответственно, если придёт пакет снаружи для DST IP из клиентской сети (которая отвалилась), то шлюз посмотрит в таблице маршрутизации, не найдёт там specific-записей для этой сети и отправит пакет в default gateway. А на default gateway указано, что вот эта клиентская сеть доступна для него через ваш шлюз. И он опять отправит пакет на ваш шлюз. Ваш шлюз -- опять вернёт его в default gateway. И так будет до тех пор, пока TTL пакета не истечёт и пакет не будет прибит. Поэтому такие сети иногда блэкхолят. Если сессия динамической маршрутизации поднята, и клиентская сеть доступна -- пакет уйдёт туда. Если сессия упадёт, то пакет сразу будет заблэкхолен, т. е. прибит, и не будет крутиться по кольцу между вашим шлюзом и его default gateway'ем до истечения TTL.
    Ответ написан
  • Провайдер блокирует доступ к сайту, подсобите?

    athacker
    @athacker
    1) "Почему так получилось" -- вероятнее всего, ваш провайдер использует схему блокировки с анализом запроса от клиента, и если ресурс из списка блокируемых, то клиенту отправляется TCP RST пакет, после чего клиентское приложение закрывает соединение. Потом приходит реальный ответ от сайта, но т. к. сайт находится дальше, чем оборудованием провайдера, то к этомум моменту ситуация следующая: клиент получил от системы DPI фальшивый TCP RST пакет, якобы от того сайта, к которому он обращался; клиент сбросил соединение; пришедший ответ от сайта системой клиента просто отбраывается, т. к. с точки зрения системы, он не относится ни к одному из установленных соединений.
    После включения локального VPN-соединения для перехвата всего трафика для анализа, вероятнее всего, фальшивый TCP RST от DPI к клиенту приложением дропается. Я бегло посмотрел описание PacketCapture, там вроде как даже изменения в транзитные пакеты можно вносить по шаблону, так что вполне может быть, что либо предусмотрен мехнизм игнорирования предположительно фейковых TCP RST, либо это побочный эффект от какого-то другого функционала PacketCapture.

    2) Что делать, чтобы всё работало -- тут вам уже объяснили. VPS за пределами контролируемого периметра с последующей настройкой выхода в интернет через этот VPS. Вариантов реализации -- тьма. Это и VPN, и поднятые SSH-туннели, проксирующие порт какого-нибудь Squid на клиента, и sshuttle, и ещё много-много всякого.
    Ответ написан
  • Как сделать отдельный dns-ответ для хоста, на котором крутится dns-сервер?

    athacker
    @athacker
    Не очень понятно, зачем вообще роутеру пинговать чего-то для определения IP, если он и так прекрасно знает, какой адрес ему выдали :-) Проще прописать всё в HOSTS, а скриптом анализировать адрес на внешнем интерфейсе. Если там серый, то переподключаться до тех пор, пока не станет белым.

    Но если там реально начали серые адреса появляться, готовьтесь к тому, что скоро они все серыми станут. Вероятнее всего, провайдер решил монетизировать белые IP-шники, т. е. в скором времени они будут выдаваться только по прямым запросам и за деньги.
    Ответ написан
  • Как соединить 2 mikrotik через L2TP over IPSEC?

    athacker
    @athacker
    Микротик указан как шлюз по умолчанию для своих клиентов? В IPsec анонс сетей со стороны Zyxel'ей прописан?
    Ответ написан