Обновление касс к 1 сентября 2025 года. Что нужно знать
1 сентября давно уже стало одной из традиционных дат для внедрения различных изменений. В этом году изменения касаются касс ККМ и затрагивают практически каждое торговое предприятие.
Информации по этой теме в сети много, но не вся она, скажем мягко, соответствует действительности. Информационные ресурсы наперегонки стращают нас о необходимости обновляться, обновляться и еще раз обновляться. Но на самом деле не все так страшно.
Изменения касаются сразу нескольких, независимых друг от друга областей регулирования, поэтому исходить будем из того, чем занимается организация на самом деле. В качестве товароучетных систем будем рассматривать программы от 1С и кассы производства АТОЛ, однако и в других сочетаниях все будет плюс-минус также.
🔹 Если вы не торгуете маркированным товаром и не ведете дистанционную торговлю, то единственным изменением для вас будут новые требования к бумажному чеку. Новых печатных реквизитов там не вводится, а все нововведения касаются размеров шрифта и QR-кода. Поэтому достаточно просто обновить прошивку кассы до актуальной – 5.16.0 у АТОЛ.
🔹 Если вы работаете с маркированным товаром, то вы теперь обязаны передавать теги 1011 Часовая зона и 2040 Номер ФД кассового чека (чека коррекции). Эти чеки передаются только в отчет о реализации маркированного товара в ОФД вы их не найдете.
Казалось бы, тут неминуемо обновление, но не будем спешить, если изучить последние релизы типовых конфигураций 1С, то мы не найдем там специфичного кода, отвечающего за заполнение этих тегов, равно как интеграционная компонента остается версии 10.10.6.0.
Поэтому, если у вас все остальные требования по работе с маркированным товаром соблюдены – то можете остаться на текущем релизе, заодно избежав обновления платформы до 8.3.27.
В этом случае вам потребуется обновить прошивку и драйвер ККТ до последних версий: 5.16.0 и 10.10.7.0, после чего ККТ начнет самостоятельно передавать часовой пояс и номер ФД (который формируется ФН внутри ККТ и товароучетное по для этого не требуется).
Для контроля зайдите в личный кабинет Честного знака, скачайте чек в формате JSON и найдите в нем строки:
▫️ receiptDocumentNumber – тег 2040 Номер ФД кассового чека
▫️ timeZone – тег 1011 Часовая зона
Обычно они идут рядом по порядку. Также проконтролируйте наличие строки:
▫️ hasIncorrectCodes – тег 2107 Результаты проверки маркированных товаров
Он также передается самой ККТ и не требует дополнительных настроек.
🔹 Если вы занимаетесь торговлей в сети интернет, то для вас обязательными станут теги:
▫️ тег 1125 - Признак расчета в Интернет
▫️ тег 1187 – Адрес сайта (место расчетов)
▫️ тег 1008 – Контактные данные покупателя (телефон или e-mail)
В этом случае также обновляем прошивку и драйвер ККТ до последних версий: 5.16.0 и 10.10.7.0.
А вот с обновлением товароучетного ПО есть варианты. Мы не работаем с этой областью и точно сказать не можем что и в каком объеме формируется или не формируется в текущих версиях. Но, в общем и целом, доработки несложные и есть смысл задуматься о их реализации при помощи расширения если обновлять конфигурацию вы по каким-либо причинам не хотите.
Если дополнительно к этому вы продаете маркированный товар, то проконтролируйте наличие тегов из предыдущего пункта.
🔹 А как быть с тегами 1234 – 1238 и 1082? А никак! На текущий момент ФНС не утвердила точный порядок заполнения реквизита сведения обо всех оплатах по чеку безналичнымим (тег 1234). Поэтому, до появления приказа, можем эти теги не заполнять и не передавать.
Скажем больше, в настоящий момент попытка передачи этого тега руками приводит во многих ОФД к ошибке – неизвестный тег. Поэтому не бежим впереди паровоза, а спокойно ждем очередных сроков.
1 сентября давно уже стало одной из традиционных дат для внедрения различных изменений. В этом году изменения касаются касс ККМ и затрагивают практически каждое торговое предприятие.
Информации по этой теме в сети много, но не вся она, скажем мягко, соответствует действительности. Информационные ресурсы наперегонки стращают нас о необходимости обновляться, обновляться и еще раз обновляться. Но на самом деле не все так страшно.
Изменения касаются сразу нескольких, независимых друг от друга областей регулирования, поэтому исходить будем из того, чем занимается организация на самом деле. В качестве товароучетных систем будем рассматривать программы от 1С и кассы производства АТОЛ, однако и в других сочетаниях все будет плюс-минус также.
🔹 Если вы не торгуете маркированным товаром и не ведете дистанционную торговлю, то единственным изменением для вас будут новые требования к бумажному чеку. Новых печатных реквизитов там не вводится, а все нововведения касаются размеров шрифта и QR-кода. Поэтому достаточно просто обновить прошивку кассы до актуальной – 5.16.0 у АТОЛ.
🔹 Если вы работаете с маркированным товаром, то вы теперь обязаны передавать теги 1011 Часовая зона и 2040 Номер ФД кассового чека (чека коррекции). Эти чеки передаются только в отчет о реализации маркированного товара в ОФД вы их не найдете.
Казалось бы, тут неминуемо обновление, но не будем спешить, если изучить последние релизы типовых конфигураций 1С, то мы не найдем там специфичного кода, отвечающего за заполнение этих тегов, равно как интеграционная компонента остается версии 10.10.6.0.
Поэтому, если у вас все остальные требования по работе с маркированным товаром соблюдены – то можете остаться на текущем релизе, заодно избежав обновления платформы до 8.3.27.
В этом случае вам потребуется обновить прошивку и драйвер ККТ до последних версий: 5.16.0 и 10.10.7.0, после чего ККТ начнет самостоятельно передавать часовой пояс и номер ФД (который формируется ФН внутри ККТ и товароучетное по для этого не требуется).
Для контроля зайдите в личный кабинет Честного знака, скачайте чек в формате JSON и найдите в нем строки:
▫️ receiptDocumentNumber – тег 2040 Номер ФД кассового чека
▫️ timeZone – тег 1011 Часовая зона
Обычно они идут рядом по порядку. Также проконтролируйте наличие строки:
▫️ hasIncorrectCodes – тег 2107 Результаты проверки маркированных товаров
Он также передается самой ККТ и не требует дополнительных настроек.
🔹 Если вы занимаетесь торговлей в сети интернет, то для вас обязательными станут теги:
▫️ тег 1125 - Признак расчета в Интернет
▫️ тег 1187 – Адрес сайта (место расчетов)
▫️ тег 1008 – Контактные данные покупателя (телефон или e-mail)
В этом случае также обновляем прошивку и драйвер ККТ до последних версий: 5.16.0 и 10.10.7.0.
А вот с обновлением товароучетного ПО есть варианты. Мы не работаем с этой областью и точно сказать не можем что и в каком объеме формируется или не формируется в текущих версиях. Но, в общем и целом, доработки несложные и есть смысл задуматься о их реализации при помощи расширения если обновлять конфигурацию вы по каким-либо причинам не хотите.
Если дополнительно к этому вы продаете маркированный товар, то проконтролируйте наличие тегов из предыдущего пункта.
🔹 А как быть с тегами 1234 – 1238 и 1082? А никак! На текущий момент ФНС не утвердила точный порядок заполнения реквизита сведения обо всех оплатах по чеку безналичнымим (тег 1234). Поэтому, до появления приказа, можем эти теги не заполнять и не передавать.
Скажем больше, в настоящий момент попытка передачи этого тега руками приводит во многих ОФД к ошибке – неизвестный тег. Поэтому не бежим впереди паровоза, а спокойно ждем очередных сроков.
👍23❤5
Эталонная модель OSI
Продолжаем рассматривать модель OSI и переходим к самым интересным, верхним уровням.
🔹 Уровень 5 – сеансовый. Отвечает за установку, управление и завершение сеансов связи между приложениями. Также обеспечивает синхронизацию и управление диалогом и восстановление сеанса в случае его обрыва.
Казалось бы, достаточно просто, но отдельных протоколов сеансового уровня придется поискать днем с огнем. Обычно здесь мы можем увидеть самые различные протоколы, традиционно считаемые протоколами иных уровней.
Это прикладные RDP, SMB, SIP, RPC, канальный PPP и использующие его PPTP или L2TP. Также здесь может оказаться TLS или даже НТТP, хотя у последнего сессии «ненастоящие».
Почему так? Потому что OSI – это абстракция, а реальные протоколы – это реальные протоколы, которые работают по-своему и без оглядки на эту модель. Поэтому здесь очень многое зависит от контекста и угла, под которым мы рассматриваем данный вопрос.
В целом – если протокол занимается созданием, управлением и завершением сеансов – то этот протокол работает на сеансовом уровне OSI.
🔹 Уровень 6 – представления. Отвечает за преобразование данных, получаемых с самого верхнего уровня L7 или предоставляемых ему. Сюда относится преобразование форматов, сжатие, кодирование и шифрование, если оно не связано с защитой передаваемых данных на сетевом или транспортном уровне.
Кодируем видео с рабочего стола для конференции – это L6, звук – тоже сюда же. Сжатие на лету HTTP-содержимого – тоже к нам. И в качестве протоколов шестого уровня у нас полноценно выступают алгоритмы сжатия и медиакодеки.
А вот с шифрованием все очень не просто. Описание шестого уровня содержит оговорку, что шифрование считается работающим на L6 только если шифруются данные самого приложения и это не связано с защитой канала передачи данных.
А вот тут начинаются еще более веселые приключения. Например, приложение, прежде чем отправить некий протокольный блок данных, который, скажем содержит данные о начисленной зарплате решает его зашифровать. Это шестой уровень, однозначно.
А вот если оно отправило этот блок как есть через защищенный канал IPsec или TLS, то это ни разу ни шестой, а третий или четвертый.
И тут снова всплывает контекст и угол обзора. Вот берем, например, классический HTTPS, не касаясь его современных вариаций.
Если посмотреть под углом, что в TLS заворачивается только HTTP содержимое и ничего больше, то можно отправить TLS на шестой уровень.
А если вспомним, что перед тем, как начать заворачивать HTTP-содержимое TLS установил соединение (уровень 5 – сеансовый) и предоставляет HTTP-защищенный канал, то он становится протоколом транспортного уровня.
А если… И таких если может быть очень много. Поэтому всегда помним, что OSI – это эталонная модель, помогающая понять принцип сетевого взаимодействия, но красиво наложить на нее современные протоколы не получится, это действо сродни натягивания совы на глобус.
🔹 Уровень 7 – прикладной, он же уровень приложений. Обеспечивает взаимодействие с сетью приложений операционной системы. И позволяет им общаться через сеть «понятным» языком.
Сюда относятся все протоколы, с которыми работают конечные приложения: браузер, почтовый клиент, сетевой плеер, клиент удаленного доступа. Это HTTP, FTP, SMTP, POP3, IMAP, RDP, SMB и т.д. и т.п.
Но здесь тоже далеко не все так просто, тот же RDP или SMB кроме всего прочего еще устанавливает и управляет сеансами, занимается кодированием и преобразованием данных от приложения, т.е. равномерно распределяет свои функции между L5 -L7.
Точно также, как и на предыдущих уровнях достаточно сложно выделить протоколы именно прикладного уровня, каждый из них может быть свободно представлен на нескольких уровнях, что модель OSI не запрещает.
Что касается самой модели и ее стройности, то на этих уровнях она сильно страдает. Но это удел любой теоретической абстракции. В тоже время OSI надо знать и понимать, так как по ее образу и подобию построены многие иные модели, которые как раз используются в реальной жизни.
Продолжаем рассматривать модель OSI и переходим к самым интересным, верхним уровням.
🔹 Уровень 5 – сеансовый. Отвечает за установку, управление и завершение сеансов связи между приложениями. Также обеспечивает синхронизацию и управление диалогом и восстановление сеанса в случае его обрыва.
Казалось бы, достаточно просто, но отдельных протоколов сеансового уровня придется поискать днем с огнем. Обычно здесь мы можем увидеть самые различные протоколы, традиционно считаемые протоколами иных уровней.
Это прикладные RDP, SMB, SIP, RPC, канальный PPP и использующие его PPTP или L2TP. Также здесь может оказаться TLS или даже НТТP, хотя у последнего сессии «ненастоящие».
Почему так? Потому что OSI – это абстракция, а реальные протоколы – это реальные протоколы, которые работают по-своему и без оглядки на эту модель. Поэтому здесь очень многое зависит от контекста и угла, под которым мы рассматриваем данный вопрос.
В целом – если протокол занимается созданием, управлением и завершением сеансов – то этот протокол работает на сеансовом уровне OSI.
🔹 Уровень 6 – представления. Отвечает за преобразование данных, получаемых с самого верхнего уровня L7 или предоставляемых ему. Сюда относится преобразование форматов, сжатие, кодирование и шифрование, если оно не связано с защитой передаваемых данных на сетевом или транспортном уровне.
Кодируем видео с рабочего стола для конференции – это L6, звук – тоже сюда же. Сжатие на лету HTTP-содержимого – тоже к нам. И в качестве протоколов шестого уровня у нас полноценно выступают алгоритмы сжатия и медиакодеки.
А вот с шифрованием все очень не просто. Описание шестого уровня содержит оговорку, что шифрование считается работающим на L6 только если шифруются данные самого приложения и это не связано с защитой канала передачи данных.
А вот тут начинаются еще более веселые приключения. Например, приложение, прежде чем отправить некий протокольный блок данных, который, скажем содержит данные о начисленной зарплате решает его зашифровать. Это шестой уровень, однозначно.
А вот если оно отправило этот блок как есть через защищенный канал IPsec или TLS, то это ни разу ни шестой, а третий или четвертый.
И тут снова всплывает контекст и угол обзора. Вот берем, например, классический HTTPS, не касаясь его современных вариаций.
Если посмотреть под углом, что в TLS заворачивается только HTTP содержимое и ничего больше, то можно отправить TLS на шестой уровень.
А если вспомним, что перед тем, как начать заворачивать HTTP-содержимое TLS установил соединение (уровень 5 – сеансовый) и предоставляет HTTP-защищенный канал, то он становится протоколом транспортного уровня.
А если… И таких если может быть очень много. Поэтому всегда помним, что OSI – это эталонная модель, помогающая понять принцип сетевого взаимодействия, но красиво наложить на нее современные протоколы не получится, это действо сродни натягивания совы на глобус.
🔹 Уровень 7 – прикладной, он же уровень приложений. Обеспечивает взаимодействие с сетью приложений операционной системы. И позволяет им общаться через сеть «понятным» языком.
Сюда относятся все протоколы, с которыми работают конечные приложения: браузер, почтовый клиент, сетевой плеер, клиент удаленного доступа. Это HTTP, FTP, SMTP, POP3, IMAP, RDP, SMB и т.д. и т.п.
Но здесь тоже далеко не все так просто, тот же RDP или SMB кроме всего прочего еще устанавливает и управляет сеансами, занимается кодированием и преобразованием данных от приложения, т.е. равномерно распределяет свои функции между L5 -L7.
Точно также, как и на предыдущих уровнях достаточно сложно выделить протоколы именно прикладного уровня, каждый из них может быть свободно представлен на нескольких уровнях, что модель OSI не запрещает.
Что касается самой модели и ее стройности, то на этих уровнях она сильно страдает. Но это удел любой теоретической абстракции. В тоже время OSI надо знать и понимать, так как по ее образу и подобию построены многие иные модели, которые как раз используются в реальной жизни.
👍26🔥1🤮1🥱1
Не поле для ввода, а textarea. Чего разработчики ждут от аналитиков на самом деле
Понятные описания, точные термины, и «глупые» вопросы — стартовый набор системного аналитика, который ставит хорошие задачи на разработку.
Екатерина Петрова обсудила с инженерами из двух разных компаний их представления о роли и работе аналитиков.
Подробнее — в нашей статье.
#реклама
О рекламодателе
Понятные описания, точные термины, и «глупые» вопросы — стартовый набор системного аналитика, который ставит хорошие задачи на разработку.
Екатерина Петрова обсудила с инженерами из двух разных компаний их представления о роли и работе аналитиков.
Подробнее — в нашей статье.
#реклама
О рекламодателе
❤1👍1👎1🔥1🤮1
Как читать таблицу маршрутизации в Windows
Как показывает практика, маршрутизация - одна из наиболее сложных тем для начинающих администраторов. Хотя, казалось бы, берем таблицу маршрутов, там все написано.
Но не все умеют правильно читать и понимать там написанное.
Следует запомнить несколько простых правил.
1️⃣ Сначала в таблице ищется маршрут с самой узкой маской. Минимальная маска - 255.255.255.255, максимальная - 0.0.0.0.
2️⃣ Если маршрутов несколько, то берется маршрут с самой маленькой метрикой.
3️⃣ После того, как маршрут найден, следует определить интерфейс выхода, который должен быть расположен в одной из непосредственно присоединенных сетей, т.е. быть доступен на канальном уровне.
Посмотрим на картинку внизу. Если мы хотим пропинговать сами себя, т.е. 192.168.233.154, то для этого сразу будет найден кратчайший маршрут в непосредственно присоединенной сети (зеленый). On-link обозначает непосредственно присоединенную сеть.
Если мы хотим обратиться к ПК из своего сегмента. то нам подойдет маршрут с более широкой маской /24 (желтый).
А если ни одного подходящего маршрута нет? Тогда нам следует использовать маршрут по умолчанию или нулевой маршрут 0.0.0.0/0.
Смотрим, таких маршрутов сразу два. Какой из них использовать? Тот у кого меньше метрика, т.е. на интерфейса 10.20.0.101 Он тоже доступен без маршрутизации.
Если же этого маршрута не будет (отключим VPN), то заработает верхний маршрут с метрикой 25. Но там стоит адрес шлюза - 192.168.233.2. Поэтому идем дальше и ищем маршрут уже для этого адреса.
Поиск такого маршрута производится только среди непосредственно присоединенных сетей и очень скоро мы снова находим нужный маршрут, который помечен желтым.
☝️ Поэтому всегда, составляя и анализируя маршруты, помним - любой маршрут должен приводить в непосредственно присоединенную сеть, иначе он работать не будет.
Почему? Да потому что IP - это 3-й уровень модели OSI - сетевой и нельзя просто так передавать IP-пакеты между ПК. Для того, чтобы это сделать, мы должны опуститься на канальный уровень и вложить их в датафреймы.
А потом еще ниже, на физический, но так глубоко мы копать не будем.
А канальный уровень - это непосредственно присоединенная сеть и только так. Это же ответ на многие вопросы типа: я написал маршрут, а он не работает. В этом случае всегда смотрим, а можем ли мы по нему достичь непосредственно присоединенной сети или нет.
Как показывает практика, маршрутизация - одна из наиболее сложных тем для начинающих администраторов. Хотя, казалось бы, берем таблицу маршрутов, там все написано.
Но не все умеют правильно читать и понимать там написанное.
Следует запомнить несколько простых правил.
1️⃣ Сначала в таблице ищется маршрут с самой узкой маской. Минимальная маска - 255.255.255.255, максимальная - 0.0.0.0.
2️⃣ Если маршрутов несколько, то берется маршрут с самой маленькой метрикой.
3️⃣ После того, как маршрут найден, следует определить интерфейс выхода, который должен быть расположен в одной из непосредственно присоединенных сетей, т.е. быть доступен на канальном уровне.
Посмотрим на картинку внизу. Если мы хотим пропинговать сами себя, т.е. 192.168.233.154, то для этого сразу будет найден кратчайший маршрут в непосредственно присоединенной сети (зеленый). On-link обозначает непосредственно присоединенную сеть.
Если мы хотим обратиться к ПК из своего сегмента. то нам подойдет маршрут с более широкой маской /24 (желтый).
А если ни одного подходящего маршрута нет? Тогда нам следует использовать маршрут по умолчанию или нулевой маршрут 0.0.0.0/0.
Смотрим, таких маршрутов сразу два. Какой из них использовать? Тот у кого меньше метрика, т.е. на интерфейса 10.20.0.101 Он тоже доступен без маршрутизации.
Если же этого маршрута не будет (отключим VPN), то заработает верхний маршрут с метрикой 25. Но там стоит адрес шлюза - 192.168.233.2. Поэтому идем дальше и ищем маршрут уже для этого адреса.
Поиск такого маршрута производится только среди непосредственно присоединенных сетей и очень скоро мы снова находим нужный маршрут, который помечен желтым.
☝️ Поэтому всегда, составляя и анализируя маршруты, помним - любой маршрут должен приводить в непосредственно присоединенную сеть, иначе он работать не будет.
Почему? Да потому что IP - это 3-й уровень модели OSI - сетевой и нельзя просто так передавать IP-пакеты между ПК. Для того, чтобы это сделать, мы должны опуститься на канальный уровень и вложить их в датафреймы.
А потом еще ниже, на физический, но так глубоко мы копать не будем.
А канальный уровень - это непосредственно присоединенная сеть и только так. Это же ответ на многие вопросы типа: я написал маршрут, а он не работает. В этом случае всегда смотрим, а можем ли мы по нему достичь непосредственно присоединенной сети или нет.
👍27❤6🤮1
gf_УФНС_о_поддержке_ФФД_в_ККТ_АВ_нб2025.pdf
283.9 KB
Получил сегодня по официальным каналам письмо ФНС, которое полностью подтверждает все изложенное во вчерашней заметке. А именно:
💬 Изменения в Приказе о ФФД носят ограниченный характер, не требуют масштабных доработок. Более того, большая часть новых тегов, предназначенных для записи информации о безналичных транзакциях в кассовый чек, может не включаться в состав фискальных данных в данной редакции Приказа о ФФД.
Т.е. теги 1234-1238 и 1082 формировать и передавать не нужно. Поэтому вам нужно только прошить кассу и обновить драйвер ККТ. Исключения касаются тех, кто торгует дистанционно, там потребуется дополнительно формировать и передавать 1125, 1187 и 1008.
Также плохая новость для тех, кто думал пересидеть, пересидеть не получится, снова цитирую:
💬 Учитывая изложенное, ФНС России сообщает об отсутствии весомых причин для переноса срока вступления в силу изменений в Приказ о ФФД и необходимости неукоснительного соблюдения его положений с 01.09.2025. Указанные изменения необходимо поддержать до 01.09.2025 и с этой даты исполнять обновленные требования Приказа о ФФД.
Поэтому, кто не успел – времени еще до понедельника, а работы не особо много. Иначе есть вполне реальные риски попасть под штрафные санкции.
💬 Изменения в Приказе о ФФД носят ограниченный характер, не требуют масштабных доработок. Более того, большая часть новых тегов, предназначенных для записи информации о безналичных транзакциях в кассовый чек, может не включаться в состав фискальных данных в данной редакции Приказа о ФФД.
Т.е. теги 1234-1238 и 1082 формировать и передавать не нужно. Поэтому вам нужно только прошить кассу и обновить драйвер ККТ. Исключения касаются тех, кто торгует дистанционно, там потребуется дополнительно формировать и передавать 1125, 1187 и 1008.
Также плохая новость для тех, кто думал пересидеть, пересидеть не получится, снова цитирую:
💬 Учитывая изложенное, ФНС России сообщает об отсутствии весомых причин для переноса срока вступления в силу изменений в Приказ о ФФД и необходимости неукоснительного соблюдения его положений с 01.09.2025. Указанные изменения необходимо поддержать до 01.09.2025 и с этой даты исполнять обновленные требования Приказа о ФФД.
Поэтому, кто не успел – времени еще до понедельника, а работы не особо много. Иначе есть вполне реальные риски попасть под штрафные санкции.
👌5
Установка MikroTik RouterOS на VDS/VPS
Cloud Hosted Router - специальный продукт компании Mikrotik позволяющий установить MikroTik RouterOS практически на любую виртуальную машину.
Однако не все хостеры позволяют загружать собственные образы, но это не страшно, RouterOS можно поставить на любой VPS с Linux, о чем мы и расскажем в данной статье.
Также уделим отдельное внимание UEFI-системам и предварительной настройке образа, позволяющей избежать потенциальных проблем с безопасностью и уменьшить количество ручной работы, а также сразу получить требуемую конфигурацию RouterOS.
https://interface31.ru/tech_it/2024/11/ustanovka-mikrotik-routeros-na-vdsvps.html
Cloud Hosted Router - специальный продукт компании Mikrotik позволяющий установить MikroTik RouterOS практически на любую виртуальную машину.
Однако не все хостеры позволяют загружать собственные образы, но это не страшно, RouterOS можно поставить на любой VPS с Linux, о чем мы и расскажем в данной статье.
Также уделим отдельное внимание UEFI-системам и предварительной настройке образа, позволяющей избежать потенциальных проблем с безопасностью и уменьшить количество ручной работы, а также сразу получить требуемую конфигурацию RouterOS.
https://interface31.ru/tech_it/2024/11/ustanovka-mikrotik-routeros-na-vdsvps.html
2👍16❤1