Визуальный калькулятор подсетей

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

Обычно это решается графическими построениями на бумаге или в Excel, но есть способ лучше – использовать Visual Subnet Calculator, открытый продукт, распространяющийся под лицензией MIT.

Проще и быстрее всего запустить его в Docker:

docker run -d -p 8081:8080 --name visualsubnetcalc ckabalan/visualsubnetcalc:latest

Теперь открываем http://myhost:8081 и начинаем работать. Сначала задаем желаемую сеть верхнего уровня и начинаем делить ее мышкой. Нажатие на сеть нижнего уровня делит ее на две равных подсети, нажатие на сеть верхнего уровня сворачивает все подсети под ней.

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

Утилита имеет четыре режима работы: стандартный и специализированный расчет для AWS, Azure и Oracle Cloud.

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

Как обустроить современный корпоративный VPN

Сегодня многие пользователи сталкиваются со сложностями в работе VPN-соединений благодаря заботе о нас одного уважаемого ведомства.

Забота эта достаточно непредсказуема и может коснуться каждого. Поэтому у многих возникает вопрос: а как жить дальше в этом непредсказуемом мире. Причем мы говорим о сугубо законопослушном использовании VPN для корпоративных нужд.

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

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

Тот же Cloud.ru дает неплохую виртуалку бесплатно в рамках free tier, все что вам останется – это купить белый IP-адрес, который обойдется примерно в 150 руб./мес.

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

Таким образом наша схема приобретает законченные очертания. Приобретаем виртуалку в крупном отечественном датацентре и разворачиваем там VPN-сервер для доступа удаленных сотрудников.

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

Задача выполнена. Удаленные клиенты соединяются с доверенным облаком, блокировки которого гораздо менее вероятны, нежели блокировки офисного адреса, а офис общается с удаленной площадкой по туннелю IPsec, который также имеет крайне невысокий риск блокировки.

Хотя как именно организовать канал – это дело сугубо личное. Но в любом случае перенастроить одно подключение проще, нежели чем десяток-другой клиентских.

VPN-протоколы, степени риска

Не так давно, в связи с потребностями наших заказчиков мы провели достаточно объемное исследование на тему рисков использования VPN-протоколов для использования их в корпоративных целях и хотим поделиться некоторыми результатами.

Исследование основано на изучении публикаций в сети, доступных документов регулятора, доступной статистики и не претендует на всеобъемлющее или истину в последней инстанции.

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

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

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

🔴 L2TP/IPsec – риски крайне высокие, сигнатуры выгружены для блокировки, кроме того, протокол обладает крайне низкой устойчивостью, есть проблемы в сетях мобильных операторов, проблемы нескольких клиентов из-за одного NAT и т.д.

🟠 IKEv2/IPsec – риски высокие, UDP-сигнатуры прекрасно видны, сам протокол также широко использовался в известных целях. Устойчивость высокая, стабильно работает в сетях различных операторов, но также имеет высокую сложность настройки и отладки.

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

🔴 WireGuard – риски очень высокие, легко детектируется и активно блокируется. Устойчивость высокая, но при этом имеет повышенные накладные расходы на администрирование в корпоративной среде.

🟢 SSTP – риски ниже среднего, это объясняется тем, что протокол проприетарный и в основном применение ограничено экосистемой Windows, ну и, пожалуй, Mikrotik. Для указанных целей практически не используется. Устойчивость высокая, практически не отличим от HTTPS, но при необходимости легко детектируется. Работает даже там, где заблокирован практически весь интернет.

🟢 OpenConnect – риски низкие, устойчивость высокая, внешне представляет реалистичный HTTPS-трафик, для обозначенных целей практически не используется. Привлекателен в корпоративной среде благодаря возможностям передачи настроек с сервера на клиент.

🟠 GRE/IPIP – риски низкие, устойчивость также низкая, имеют проблему прохождения NAT, не работают в сетях мобильных операторов, небезопасны. IPIP архитектурно ограничен только IP-трафиком.

🟢 IPsec – риски низкие, в основном используется для корпоративных и магистральных коммуникаций. Устойчивость выше средней, но также присутствуют требования к сторонам соединения (белые адреса и т.д.). Сложность настройки и отладки – крайне высокая, требует специальных знаний и навыков.

🟢 GRE/IPIP over IPsec – риски низкие, устойчивость выше средней. Внешне это тот же IPsec со всеми плюсами и минусами. Внутри привычные GRE/IPIP туннели. Сложность эксплуатации выше средней из-за присутствия IPsec, но значительно ниже, чем у чистого IPsec.

👉 Исходя из вышесказанного для целей удаленного доступа (Road-Warrior) рекомендуются SSL-VPN решения, такие как SSTP или OpenConnect, последний очень хорошо впишется в корпоративную сеть как полноценная замена OpenVPN с возможностью централизованного управления настройками клиентов.

Для соединения площадок (Site-to-Site) следует предпочитать решения на базе IPsec, наилучшим вариантом здесь будет GRE over IPsec, который сочетает сильные стороны IPsec с понятной сетевой моделью туннелей GRE, основанной на классической маршрутизации, а не на политиках.

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

Защищаем сетевые службы при помощи stunnel

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

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

Чтобы понять для каких случаев предпочтительнее stunnel снова вернемся к VPN, при всех ее достоинствах некоторые из них могут обернуться недостатками.

С помощью VPN легко предоставить доступ ко всем ресурсам внутренней сети, но если с той стороны находится неконтролируемый или внештатный сотрудник (скажем бухгалтер на аутсорсинге), то этот плюс моментально превращается в минус. И нам уже надо думать не о том, как доступ к сети предоставить, а о том, как бы его закрыть.

В то же время stunnel предусматривает совершенно иной принцип работы, он работает на уровне TCP-соединений и позволяет просто и эффективно защитить его при помощи современного шифрования.

С его помощью клиент будет иметь доступ к одному единственному порту сетевой службы и никуда более. При необходимости можно настроить несколько таких соединений.

Для примера мы рассмотрим организацию доступа к веб-серверу с опубликованной на нем базой 1С:Предприятия, доступ к которой должен иметь удаленный сотрудник.

Будем считать, что веб-сервер с модулем расширения 1С установлен на машине с Linux (Debian или Ubuntu) расположенной в локальной сети предприятия, веб-сервер принимает подключения по протоколу HTTP без шифрования. Задача - обеспечить доступ к 1С с рабочего места бухгалтера.

✅ Читать далее: https://interface31.ru/post/zashhishhaem-setevye-sluzhby-pri-pomoshhi-stunnel/

Как быть если потеряли лицензию от 1С?

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

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

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

После чего идем на https://portal.1c.ru/support/license и получаем что нам нужно, а получить можно:

🔹 Информацию о владельце

🔹Текущее состояние пин-кодов

🔹 Резервный пин-код

Либо обращаемся с этой информацией на линию поддержки по вопросам лицензирования lic@1c.ru

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

Обычно C:/ProgramData/1C/licence

Затем качаем утилиту LicDataViewer, это удобная обертка над стандартными Ring и License Tools, натравливаем его на файл программной лицензии и получаем сведения о регистрационном номере, использованном пин-коде и введенной информации о владельце.

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

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

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

Временные метки файлов в Linux

Этот, вроде-бы простой на первый взгляд вопрос часто вызывает достаточно много сложностей, особенно у начинающих.

Согласно стандарту POSIX у файлов в Linux имеются три временных метки:

▫️ atime – время последнего доступа к файлу
▫️ mtime – время последней модификации содержимого файла
▫️ ctime – время последнего изменения содержимого файла или его метаданных

С первой меткой вроде бы все просто, atime обновляется при любом доступе к файлу, однако по умолчанию в большинстве систем включен режим relatime (метка обновляется не чаще раза в сутки, если файл не менялся), а при опции noatime обновление отключено вовсе

Метка mtime меняется при изменении содержимого файла, но ее не меняют изменения метаданных, такие как изменение владельца или прав доступа или переименование.

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

Особенностью метки ctime является то, что данная метка управляется системой, в то время как atime и mtime может произвольно изменять владелец файла. Таким образом данная метка однозначно покажет нам время последнего изменения файла, в то время как mtime может содержать неверную информацию.

При этом в нормальных условиях изменение mtime всегда влечет изменение ctime, а вот изменение ctime может происходить отдельно от других временных меток.

Так переименование файла изменит только ctime (а также затронет родительский каталог), но не отразится на mtime, а изменение прав или владельца файла затронет только ctime.

Позвольте, скажет иной читатель, а как быть с временем создания файла? А никак, такой временной метки POSIX не предусматривает. Однако позже была добавлена еще одна временная метка – crtime – которая как раз отражает время создания файла, но она имеет некоторые особенности.

Не являясь POSIX-совместимой, данная метка была реализована на уровне файловой системы и, следовательно, хранится только в ее пределах, между системами данный атрибут не переносится.

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

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

Каким образом можно посмотреть временные метки? Используйте команду stat, например:

stat file.txt

Строки Доступ, Модифицирован и Изменен будут соответствовать atime, mtime и ctime. Однако если мы посмотрим на свойства файла в графическом окружении, то сможем увидеть, что Изменен в этом случае соответствует mtime, что в целом верно логически, но способно внести путаницу.

Поэтому, если вы хотите получить точное значение параметра, то используйте форматирование вывода команды stat:

stat -c '%x' file.txt - atime
stat -c '%y' file.txt - mtime
stat -c '%z' file.txt - ctime

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

Забавная маршрутизация

Маршрутизация – пожалуй одна из самых сложных тем для начинающих, да и не только для них.

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

Когда-то давно мои заказчики попросили придумать задачку для собеседования на тему маршрутизации и базового понимания сетей.

👉 Задачка простая, но не совсем очевидная.

Итак, имеется следующая таблица маршрутизации:

192.168.0.0/24 – eth0
192.168.0.0/25 – eth1
192.168.0.0/26 – eth2
192.168.0.0/27 – eth3
192.168.0.0/28 – eth4

Будет ли такая таблица работать и какие сети находятся за каждым интерфейсом?

❗️Примечание: за каждым интерфейсом только одна сеть, все интерфейсы активные.