ProHoster > Blog > Administración > Videovixilancia doméstica. Esquema para manter un arquivo de vídeo sen un gravador doméstico

Videovixilancia doméstica. Esquema para manter un arquivo de vídeo sen un gravador doméstico

Levo bastante tempo querendo escribir un artigo sobre un guión para traballar cunha cámara a través do protocolo DVRIP, pero a discusión estaba relacionada coas novas recentes sobre Xiaomi levoume a falar primeiro de como configuro a videovixilancia na casa e despois pasar aos guións e outras cousas.

Tiñamos 2 paquetes... Entón, espera, esta non é a mesma historia.
Tiñamos 2 enrutadores de TP-LINK, acceso a Internet detrás do provedor NAT, unha cámara de vixilancia Partizan non recordo que modelo (calquera cámara IP que admita RSTP sobre TCP ou DVRIP servirá) e un VPS barato por 4 euros co características: CPU de 2 núcleos 2.4 GHz, 4 GB de RAM, 300 GB de disco duro, porto de 100 Mbit/s. E tamén a reticencia a comprar algo ademais disto que custaría máis que un cable de conexión.

Prefacio

Por razóns obvias, non podemos simplemente reenviar os portos da cámara no enrutador e gozar da vida, ademais, aínda que puidésemos, non deberíamos facelo.

Oín de repente que hai algunhas opcións co túnel IPv6, onde parece que todo se pode facer para que todos os dispositivos da rede reciban un enderezo IPv6 externo, e iso simplificaría un pouco as cousas, aínda que aínda deixa a seguridade. deste evento en cuestión, e o soporte para este milagre no firmware estándar TP-LINK é estraño. Aínda que existe a posibilidade de que na frase anterior estou a falar de un despropósito completo, así que non lle prestes atención en absoluto.

Pero, afortunadamente para nós, case calquera firmware para calquera enrutador (unha afirmación bastante infundada de feito) contén un cliente PPTP/L2TP ou a posibilidade de instalar firmware personalizado con el. E a partir diso xa podemos construír algún tipo de estratexia de comportamento.

Topoloxía

Nun ataque de febre, o meu cerebro deu a luz algo así como este diagrama de cableado:

e durante outro ataque debuxeno para publicar en HabrVideovixilancia doméstica. Esquema para manter un arquivo de vídeo sen un gravador doméstico

O enderezo 169.178.59.82 xerou aleatoriamente e só serve como exemplo

Ben, ou en palabras, entón:

  • Router TP-LINK 1 (192.168.1.1), no que se introduce un cable que sobresae da parede. Un lector curioso adiviñará que este é o cable do provedor a través do cal accedo a Internet. Varios dispositivos domésticos están conectados a este enrutador mediante un cable de conexión ou wifi. Esta é a rede 192.168.1.0
  • Router TP-LINK 2 (192.168.0.1, 192.168.1.200), no que se introduce un cable que sobresae do router TP-LINK 1. Grazas a este cable, o router TP-LINK 2, así como os dispositivos conectados a el, tamén teñen acceso a Internet. Este enrutador está configurado cunha conexión PPTP (10.0.5.100) ao servidor 169.178.59.82. A cámara IP 192.168.0.200 tamén está conectada a este enrutador e envíanse os seguintes portos
    • 192.168.0.200:80 -> 49151 (webmord)
    • 192.168.0.200:34567 -> 49152 (DVRIP)
    • 192.168.0.200:554 -> 49153 (RTSP)
  • Servidor (169.178.59.82, 10.0.5.1), ao que está conectado o enrutador TP-LINK 2. O servidor executa pptpd, shadowsocks e 3proxy, a través dos cales se pode acceder aos dispositivos da rede 10.0.5.0 e así ter acceso ao enrutador TP-LINK 2.

Así, todos os dispositivos domésticos da rede 192.168.1.0 teñen acceso á cámara a través de TP-LINK 2 no 192.168.1.200, e todos os demais poden conectarse a través de pptp, shadowsocks ou socks5 e acceder a 10.0.5.100.

axuste

O primeiro paso é conectar todos os dispositivos segundo o diagrama da figura anterior.

  • A configuración do enrutador TP-LINK 1 consiste en reservar o enderezo 192.168.1.200 para TP-LINK 2. Opcional se precisa un enderezo fixo para acceder desde a rede 192.168.1.0. E, se o desexa, pode reservar 10-20 Mbit para iso (10 é suficiente para un fluxo de vídeo de 1080).
  • Debe instalar e configurar pptpd no servidor. Teño Ubuntu 18.04 e os pasos foron aproximadamente os seguintes (o doador foi un exemplo blog.xenot.ru/bystraya-nastrojka-vpn-servera-pptp-na-ubuntu-server-18-04-lts.fuck):
    • Instala os paquetes necesarios: 
      sudo apt install pptpd iptables-persistent
    • Traémolo ao seguinte formulario

      /etc/pptpd.conf

      option /etc/ppp/pptpd-options
bcrelay eth0 # Интерфейс, через который ваш сервер ходит в интернеты
logwtmp
localip 10.0.5.1
remoteip 10.0.5.100-200

    • Editamos

      /etc/ppp/pptpd-options

      novj
novjccomp
nologfd

name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
#require-mppe-128 # Можно раскомментировать, но мой TP-LINK c ним не дружит

ms-dns 8.8.8.8
ms-dns 1.1.1.1
ms-dns  77.88.8.8
ms-dns 8.8.4.4
ms-dns 1.0.0.1
ms-dns  77.88.8.1

proxyarp
nodefaultroute
lock
nobsdcomp
    • Engadindo credenciais a

      /etc/ppp/chap-secrets

      # Secrets for authentication using CHAP
# client	server	secret			IP addresses
username pptpd password *
    • Engadir a

      /etc/sysctl.conf

      net.ipv4.ip_forward=1

      e recarga sysctl

      sudo sysctl -p
    • Reinicie pptpd e engádeo ao inicio 
      sudo service pptpd restart
sudo systemctl enable pptpd
    • Editamos

      iptables

      sudo iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 1723 -j ACCEPT
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables --table nat --append POSTROUTING --out-interface ppp+ -j MASQUERADE
sudo iptables -I INPUT -s 10.0.5.0/24 -i ppp+ -j ACCEPT
sudo iptables --append FORWARD --in-interface eth0 -j ACCEPT

      E gardar

      sudo netfilter-persistent save
sudo netfilter-persistent reload
  • Configuración de TP-LINK 2
    • Reservamos o enderezo 192.168.0.200 para a nosa cámara:

      DHCP -> Reserva de enderezos — Enderezo MAC — cámara MAC, pódese ver en DHCP -> Lista de clientes DHCP
      — Enderezo IP reservado — 192.168.0.200

    • Portos de reenvío:
      Redirección -> Servidores virtuais — Porto de servizo: 49151, Porto interno: 80, Enderezo IP: 192.168.0.200, Protocolo: TCP
      — Porto de servizo: 49152, Porto interno: 34567, Enderezo IP: 192.168.0.200, Protocolo: TCP
      — Porto de servizo: 49153, Porto interno: 554, Enderezo IP: 192.168.0.200, Protocolo: TCP
    • Configurar unha conexión VPN:

      Rede -> WAN — Tipo de conexión WAN: PPTP
      — Nome de usuario: nome de usuario (consulte /etc/ppp/chap-secrets)
      — Contrasinal: contrasinal (consulte /etc/ppp/chap-secrets)
      — Confirme o contrasinal: contrasinal (consulte /etc/ppp/chap-secrets)
      - IP dinámica
      — Enderezo IP/Nome do servidor: 169.178.59.82 (obviamente, a IP externa do seu servidor)
      — Modo de conexión: Conéctase automaticamente

    • Opcionalmente, permitimos o acceso remoto á cara web do enrutador
      Seguridade -> Xestión remota - Porto de xestión web: 80
      — Dirección IP de xestión remota: 255.255.255.255
    • Reinicie o enrutador TP-LINK 2

En lugar de PPTP, podes usar L2TP ou, se tes firmware personalizado, o que queiras o teu corazón. Elixín PPTP, xa que este esquema non se construíu por razóns de seguridade e pptpd, segundo a miña experiencia, é o servidor VPN máis rápido. Ademais, realmente non quería instalar firmware personalizado, o que significaba que tiña que escoller entre PPTP e L2TP.

Se non cometín un erro en ningún lugar do manual, e fixeches todo correctamente e tiveches sorte, despois de todas estas manipulacións

  • en primeiro lugar 
    ifconfig

    mostrará a interface ppp0 inet 10.0.5.1 netmask 255.255.255.255 destination 10.0.5.100,

  • en segundo lugar, 10.0.5.100 debe facer ping,
  • e en terceiro lugar 
    ffprobe -rtsp_transport tcp "rtsp://10.0.5.100:49153/user=admin&password=password&channel=1&stream=0.sdp"

    Должен обнаружить стрим.
    Podes atopar o porto rtsp, o inicio de sesión e o contrasinal na documentación da túa cámara

Conclusión

En principio, isto non está mal, hai acceso a RTSP, se o software propietario funciona a través de DVRIP, entón podes usalo. Podes gardar a emisión usando ffmpeg, acelerar o vídeo 2-3-5 veces, dividilo en anacos dunha hora de duración, cargalo todo en Google Drive ou redes sociais e moito, moito máis.

Non me gustou RTSP sobre TCP, porque non funcionaba moi estable, pero si sobre UDP, polas razóns de que non podemos (ou podemos, pero non quero facelo) reenviar o rango de portos. a través do cal RTSP impulsará o fluxo de vídeo, non funcionará, escribín un script que arrastra un fluxo por TCP mediante DVRIP. Resultou máis estable.

Unha das vantaxes do enfoque é que podemos tomar algo que admita un asubío 2G en lugar do enrutador TP-LINK 4, alimentalo todo xunto coa cámara desde un SAI (que sen dúbida necesitará un moito menos espazoso que cando usando unha gravadora), ademais, a gravación transmítese case ao instante ao servidor, polo que aínda que os intrusos penetran no teu sitio, non poderán aproveitar o vídeo. En xeral, hai marxe de manobra e todo depende só da túa imaxinación.

PD: sei que moitos fabricantes ofrecen solucións na nube preparadas, pero en prezo son case o dobre que o meu VPS (do que xa teño 3, polo que teño que destinar recursos nalgún lugar), proporcionan moito menos control e tamén calidade non moi satisfactoria.

Fonte: www.habr.com

Engadir un comentario