athacker

Это баг в JDK. Вот тут немного информации: https://github.com/jetty-project/jetty-alpn/issues/18

Мануал по OpenVPN почитайте, в части параметров route и iroute.

Настройте с домашнего компа регулярную отправку данных с домашнего компа в сторону сервера в интернете по расписанию. ЧТобы соединение инициировал домашний комп.

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

P/S/: Если вы в Москве, то книжку по курсу ICND 1 могу вам отдать безвозмездно, у меня тут завалялась.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3) Citrix XenServer... Ну такое... Посмотрите на картинку и найдите там XenServer:


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: складывать на ту же хранилку, на которой виртуалки работают -- моветон и чревато печальными последствиями.

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

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

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