avk013.blogspot.com - другой мой блог "C# and etc"

понедельник, 16 марта 2026 г.

Подключение к компьютеру, который находится за NATом

Появилась необходимость подключиться к изолированному компьютеру (технологический) специалисту из зарубежья, причем на компьютере установлен какой-то специализированный Linux от которого, к тому же, нет пароля, только меню на экране.
*приведено к читаемому и рабочему виду с помощью Грока, за что и спасибо, описано Клаудем, идея и реализация моя.

Играться с промежуточным компьютером можно, НО
есть 
4G-модем, бюджетный, просто дает интернет
и 
Mikrotik hAP Lite  - ультрабюджетный.

Зато есть где-то там, другой Микротик с выделенным IP, и извращенным админом, и так наш технологический компьютер подключается в сеть 192.168.1.х микротика, который образует туннель с базой, также туннель образует и специалист со своего зарубежья, и заходит на наш промкомпьютер специализированной программой.
Выбрано L2tp как простота реализации.


Анализ логики работы

Топология «звезда» (hub-and-spoke). Все клиенты подключаются только к центральному серверу — прямых туннелей между клиентами нет. Для связи MikroTik-клиент ↔ Windows-клиент трафик идёт через хаб: 192.168.1.199 → 192.168.166.1 → 192.168.166.x.

Стек протоколов. L2TP создаёт туннель на уровне 2 (PPP-сессия), IPsec шифрует этот туннель на уровне 3 (ESP + IKE). PPP внутри туннеля обеспечивает аутентификацию (MSCHAPv2/CHAP) и назначение адресов из пула vpn-pool.

Жизненный цикл соединения состоит из трёх фаз: (1) IKE-согласование (UDP 500/4500, PSK — предобщий ключ), (2) IPsec SA — установка шифрованного канала (протокол ESP), (3) L2TP + PPP поверх IPsec — туннель, аутентификация пользователя, получение IP из пула.

Маршрутизация. MikroTik-клиент получает адрес .166.x, но его локальная сеть 192.168.1.0/24 не анонсируется автоматически — для этого добавляется статический маршрут 192.168.166.0/24 via l2tp-to-hub на клиенте. Windows работает в режиме full-tunnel: весь трафик идёт через 192.168.166.1, что обеспечивает галочка «использовать шлюз по умолчанию».

Firewall-логика выстроена в два слоя: на сервере input-цепочка разрешает только служебные порты VPN (1701, 500, 4500, ESP), forward-цепочка разрешает трафик внутри interface-list=PPP-VPN. На MikroTik-клиенте правила forward разрешают двунаправленный обмен между туннелем и мостом LAN.

======================================

мини-шпаргалка по настройке L2TP/IPsec «звезды» на MikroTik (центральный сервер + MikroTik-клиент + Windows-клиент с full-tunnel), с акцентом на правильную последовательность и проверку перед применением.

1. Центральный сервер (L2TP-сервер)

Порядок выполнения:

1. Создать пул адресов для клиентов /ip pool add name=vpn-pool ranges=192.168.166.10-192.168.166.250

2. Создать / проверить профиль PPP

text

/ppp profile

add name=vpn-profile local-address=192.168.166.1 remote-address=vpn-pool \

    use-encryption=required change-tcp-mss=yes only-one=no

(если профиль уже есть → set вместо add)

3. Включить L2TP-сервер + IPsec

text


/interface l2tp-server server

set enabled=yes default-profile=vpn-profile authentication=mschap2,chap \

    use-ipsec=yes ipsec-secret=ВАШ_СЕКРЕТНЫЙ_КЛЮЧ

Создать пользователя для Windows text

/ppp secret

add name=win-user password=СильныйПароль service=l2tp profile=vpn-profile

Создать список интерфейсов PPP-VPN (если его ещё нет) text

/interface list print where name=PPP-VPN

→ если ничего не нашлось →

text


/interface list add name=PPP-VPN comment="VPN клиенты L2TP"

Привязать список к профилю (только после создания списка!) text

/ppp profile set [find name=vpn-profile] interface-list=PPP-VPN

Добавить базовые firewall-правила (input + forward) text

/ip firewall filter

add chain=input  action=accept protocol=udp dst-port=1701,500,4500 comment="L2TP/IPsec"

add chain=input  action=accept protocol=ipsec-esp

add chain=forward action=accept in-interface-list=PPP-VPN out-interface-list=PPP-VPN comment="VPN ↔ VPN"

MikroTik-клиент (тот, за которым 192.168.1.199) Порядок:

Создать L2TP-клиент text

/interface l2tp-client

add connect-to=ПУБЛИЧНЫЙ_IP_СЕРВЕРА user=имя_секрета password=пароль \

    name=l2tp-to-hub use-ipsec=yes ipsec-secret=ВАШ_СЕКРЕТНЫЙ_КЛЮЧ \

    add-default-route=no disabled=no

Дождаться подключения (Connected) /interface l2tp-client print

Добавить маршрут обратно к туннельной подсети text

/ip route add dst-address=192.168.166.0/24 gateway=l2tp-to-hub distance=1 check-gateway=ping

Разрешить трафик из туннеля в LAN и обратно text

/ip firewall filter

add chain=forward action=accept in-interface=l2tp-to-hub out-interface=bridge comment="туннель → LAN" place-before=0

add chain=forward action=accept in-interface=bridge out-interface=l2tp-to-hub comment="LAN → туннель" place-before=0

(bridge → замени на реальное имя интерфейса с 192.168.1.0/24)

5. Разрешить доступ к WebFig/Winbox с VPN (если нужно)

text


/ip firewall filter

add chain=input action=accept protocol=tcp dst-port=80,443,8291 \

    in-interface=l2tp-to-hub comment="Web/Winbox из VPN" place-before=0

Убедиться, что masquerade только на WAN /ip firewall nat print → не должно быть masquerade на l2tp-to-hub

Windows-клиент

Создать VPN-соединение: L2TP/IPsec с предв. ключом

Сервер = публичный IP сервера

Тип входа = имя пользователя и пароль

Предварительный ключ = ВАШ_СЕКРЕТНЫЙ_КЛЮЧ

В свойствах соединения → IPv4 → Дополнительно → Поставить галочку «Использовать шлюз по умолчанию в удалённой сети»

Подключиться → проверить:

ipconfig → IP из 192.168.166.x

route print → default gateway = 192.168.166.1

ping 192.168.1.199 Краткая проверка после всего

Сервер: /interface l2tp-server print → connected клиенты

Сервер: /interface list member print where list=PPP-VPN → есть l2tp-in*

Клиент: /ip route print → есть 192.168.166.0/24 через l2tp-to-hub

Windows: tracert 192.168.1.199 → проходит через 192.168.166.1

======================================

среда, 17 сентября 2025 г.

модуль отправки сообщений и фото в мессенджер Ватсап, перспективно сервис MessHub2

Аксиома:
 1. Бесплатно бота нам Американская Цель не дает
Поправки:
1. У меня есть браузер,
2.Я могу сохранить сессию в папке локального пользователя
3. Я могу нажимать на кнопки программно
Инструменты:
1. AI модели
2. Linux + X.
3. Venv
Мотивация:
1. Сделать это ( скрытое: что-то, кому-то доказать )
2. Альтернативная без телеграмм реализация, валидная от СБ в стране.
3. Производственная необходимость
Спонсор:
1. Человеческие условия труда

messhub2

16.09.2025.....наконец-то пошли текстовые сообщения, это прорыв, 1 неделя на нажатие кнопки отправить :) в тексте,  и 2 недели на окно с Картинкой без отправки.... - прорыв но отсылается картинка в качестве стикера.
17.09.2025....седые волосы, бан от моделей АИ....НО мы сделали это.....все оказалось проще чем сам путь, вопрос на долго ли.... Тестирование, не нравятся задержки интерфкйса, но это граничит с баном от компании.
21.09.2025...2е суток в реальных условиях испытаний следующей версии, коды выложу позже, есть часть (в виде сервиса) которая обслуживает очередь и кидает в мессенджер, вторая крутится возле прикладной программы подпрограммой и создает очередь, соприкосновение только папкой очереди. messhub2v4 
09.10.2025...ватсап решил отключить старые устройства...потому мы обновляем представление агента, посмотрим на сколько хватит...
chrome_options.add_argument("--user-agent=Mozilla/5.0 (iPad; CPU OS 18_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Mobile/15E148 Safari/604.1")
13.10.2025 поменял Большой Брат селекторы...теперь "       
 # Нажимаем на кнопку "Прикрепить"
        attach_selectors = [
            (By.CSS_SELECTOR, 'span[data-icon="plus-rounded"]'),  # Новый селектор

воскресенье, 14 сентября 2025 г.

Подключение китайского регистратора от Hangzhou Xiongmai Technology Co. к регистратору HikVision по протоколу rtsp

Бесплатное ПО от  HikVision просто убивает вычислительные ресурсы ПК, понадобилось какое-то время чтобы я пришел к тому, что китайская плата регистратора может показывать rtsp потоки от регистратора  HikVision (Юра..ка представитель от Viatek, который "толакет" компы с игровыми видеокартами для поста видеонаблюдение - ПРИВЕТ!!!!).
====================

1. Альтернативным способом показывать поток в обычном проигрывателе:

у меня VLC и  PotRlayer
согласились показывать поток 7 от регистратора 192.168.0.9 в виде:
rtsp://login:password@192.168.0.9:554/Streaming/Channels/701
и дополнительный
rtsp://login:password@192.168.0.9:554/Streaming/Channels/702
====================

2.Регистратор на плате:  XM/HiSilicon  AHB8004R-MH-NVT

прошивка "V4.03.R11.00000227.12001.131700.0000000 BuildDate: 2023-09-18 16:32:09"
до этого НЕУДАЧНО пробовал на неновом регистраторе NBD8004R-PL с прошивкой "V4.03.R11.00000203.12001.130000.0000000 BuildDate: 2019-07-30 16:50:44", там есть поддержка onvif но нет rtsp.
Через сетевое ПО можно даже не пытаться ... у меня корректно занести устройство rtsp не удалось.
Итак только локально...


и случайно выбранный DVR вместо HVR, заставил погрузиться в конфиг, который можно забекапить....это обычный архив, в котором хранятся локальные конфиги общей системы регистратора, в котором есть папка JSON в которой опять в архивах хранятся файлы (в моей версии по 2: нынешний и предыдущий) и нас интересует NetWork~ в котором есть раздел нашей камеры внешнего регистратора 

{
  "ConnType": "SINGLE",
  "Decoder": [
    {
      "Channel": 0,
      "ConfName": "chConfig",
      "DevType": "HVR",
      "Enable": true,
      "IPAddress": "192.168.0.9",
      "Interval": 10,
      "MacAddr": "",
      "MainRtspUrl": "rtsp://192.168.0.9:554/Streaming/Channels/701",
      "PassWord": "test1290",
      "Port": 554,
      "Protocol": "RTSP",
      "SerialNo": "",
      "StreamType": "MAIN",
      "SubRtspUrl": "rtsp://192.168.0.9:554/Streaming/Channels/702",
      "TransModel": 0,
      "UserName": "test"
    }
  ],
  "EnCheckTime": true,
  "Enable": true,
  "SingleConnId": "0x00000001",
  "SynchResolution": true,
  "TourIntv": 10
}

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



четверг, 28 августа 2025 г.

dokuwiki + .htapasswd + docker

 казалось бы простая "модификация" стандартного докера, заняла немало времени.
Что тут такого? пещерная "HTTP Basic Authentication" как лишняя проверка и слепость разных ИИ в интеграции настроек.

Итак:
cat docker-compose.yml
services:
  web:
    image: ghcr.io/linuxserver/dokuwiki:latest
    container_name: dokuwiki
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - ./dokuwiki_config:/config
      - ./.htpasswd:/etc/nginx/.htpasswd
      - ./nginx-auth.conf:/config/nginx/site-confs/custom.conf
    ports:
      - "127.0.0.1:80"
      - "127.0.0.1:443"
    restart: unless-stopped
    network_mode: bridge
 cat nginx-auth.conf
# Добавление Basic Auth к существующему блоку server
auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/.htpasswd;

=============
.htpasswd делается стандартным способом
ну наличие папки dokuwiki_config в корне с этими файлами.
IP вместо 127.0.0.1 но можно и по другому.....
В папке:
docker compose up -d
docker compose logs -f

Плюшка:
попадаем внутрь докера, кривыми ручками:
docker exec -it dokuwiki /sbin/apk update
docker exec -it dokuwiki /sbin/apk add mc
docker exec -it dokuwiki mc
Но это только на сессию докера....может оно и к лучшему, все что нужно поменять на свое притягиваем через volumes в docker-compose.yml

вторник, 26 августа 2025 г.

вредные советы, можно сказать: "неожидал"

1. Бесконечное монтирование

 mount --bind источник приемник
делаем в цикле бесконечное количество раз.....и желательно чтобы одна из папок была удаленным сетевым ресурсом

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

2.

понедельник, 18 августа 2025 г.

Windows клавиатура: Отключение действия кнопки питания, Отключение действия кнопки спящего режима

 вдруг захотелось автоматизировать отключение вредных клавиш для эмоциональных людей, сгенерировано АИ

Windows Registry Editor Version 5.00


; Отключение действия кнопки питания (действие не требуется)

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\4f971e89-eebd-4455-a8de-9e59040e7347\7648efa3-dd9c-4e3e-b566-50f929386280]

"Attributes"=dword:00000002

"ACSettingIndex"=dword:00000000

"DCSettingIndex"=dword:00000000


; Отключение действия кнопки спящего режима (действие не требуется)

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\4f971e89-eebd-4455-a8de-9e59040e7347\96996bc0-ad50-47ec-923b-6f41874dd9eb]

"Attributes"=dword:00000002

"ACSettingIndex"=dword:00000000

"DCSettingIndex"=dword:00000000

понедельник, 4 августа 2025 г.

vsftpd с папкой, которая находится на другом iscsi узле (однозначно извращение)

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

Действующие элементы (все все из семейства Linux):

1. NAS iscsi (и второго клиента он подключать отказывается, работает - не тронь!!!)

2. Компьютер с смонтированным файловым iscsi пространством и vsftpd сервером

3. Компьютер, которому нужно воспользоваться файловым iscsi пространством

Итак, есть сервер клиент iscsi c vsftpd сервером с аутенфикацией по пользователю. Так как пользователей несколько а подключаются они по умолчанию в собственные папки...то элемент iscsi массива нужно "склеить" с папкой пользователя и......и символические ссылки не работают:(,
 НО работает 
 mount --bind источник /home/login/ftp
!!!
а после этого на настоящем клиенте монтируем пространство

curlftpfs ftp://login@10.10.10.10/folder /mnt/folder

и с ужасом ожидаем когда это все поломается

избавить от этого можно просто размещение nfs сервера на компьютере где подключен iscsi

и это завелось, хоть и по безопасности разрешение подключения только по IP как-то напрягает.......но право жить имеет.....

перед тестами производительности субъективно казалось что он более тормознутый, НО

на конкретной задаче, с одним и тем же объектом получили соотношение:

881 к 655 попугаям

nfs оказалась на 25% производительнее ftp-file systems,
повторные тесты показали отличие около 15% в туже пользу. 

=============== и вообще зачем это
iscsi пространство содержит шифрованный раздел, и усугублять рисками не хочется, поэтому и делимся смонтированным шифрованным разделом через nfs и ftp с другими хостами.