Hola a todos, esta es mi primera experiencia en Habr. Quiero escribir sobre cómo gestionar de manera no convencional el equipo de red en una red externa. ¿Qué significa no convencional? En la mayoría de los casos, para gestionar el equipo en una red externa, necesita:
- Una dirección IP pública. O, si el equipo está detrás de un NAT, entonces una IP pública y un puerto 'abierto'.
- Un túnel (PPTP/OpenVPN/L2TP+IPSec, etc.) hacia el nodo central, a través del cual se accedería.
Por lo tanto, 'mi bicicleta' será necesaria cuando los métodos estándar no sean adecuados para usted, por ejemplo:
- El equipo está detrás de un NAT y, aparte del http normal (puerto 80), todo está cerrado. Es una situación bastante normal para grandes redes corporativas federales. Pueden abrir los puertos, pero no de inmediato, no rápido y no para usted.
- Un canal de comunicación inestable y/o 'estrecho'. Baja velocidad, pérdidas constantes. Dolor y frustración al intentar organizar un túnel.
- Un canal de comunicación costoso, donde literalmente cada megabyte cuenta. Por ejemplo, conexión satelital. Además, grandes retrasos y un ancho de banda 'estrecho'.
- Situación en la que necesita 'jugar' con una gran cantidad de pequeños enrutadores, donde de un lado se ha instalado OpenWrt/Lede para ampliar las capacidades, y del otro lado los recursos (memoria) del enrutador no son suficientes para todo.
Nota número uno ¿Qué impide instalar una 'memoria USB' en el puerto USB del enrutador y ampliar la memoria del enrutador?
A menudo, las exigencias sobre el costo de la solución en general, pero a veces el factor de forma también juega un papel clave. Por ejemplo, en el sitio hay un TP-Link ML3020, su único puerto USB se utiliza para un módem 2G/3G, todo esto está envuelto en algún pequeño gabinete de plástico y colocado en algún lugar muy alto (en un mástil), muy lejos (en el campo, a 30 km de la estación base más cercana del operador móvil). Sí, se puede conectar un hub USB y ampliar el número de puertos, pero la experiencia muestra que esto es engorroso e unreliable.
Así que he intentado describir mi situación típica: 'en algún lugar muy, muy lejos, hay un enrutador muy importante, solitario y pequeño, que funciona con Linux. Es importante saber al menos una vez al día que está 'vivo' y, si es necesario, enviarle comandos, por ejemplo, 'sol, reiníciate!'
Pasemos a la implementación:
1) En el lado del enrutador, cada 5/10/1440 minutos, o cuando sea necesario, se debe enviar una solicitud http al servidor utilizando wget, guardar el resultado en un archivo, hacer que el archivo sea ejecutable y ejecutarlo.
Mi línea en cron se ve algo así:
Archivo /etc/crontabs/root:
* /5 * * * * wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password" -O /tmp/wa.sh && chmod 777 /tmp/wa.sh && /tmp/wa.sh , donde:
xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai — es el dominio de mi servidor. Cabe señalar que sí, también se puede indicar una dirección IP específica del servidor; antes hacíamos eso, hasta que nuestro estado, en un impulso justo de lucha contra no sé qué, cerró el acceso a la mayoría de las 'nubes' de DigitalOcean y Amazon. En caso de usar un dominio simbólico, si se presenta un caso así, puedes levantar una nube de respaldo, redirigirle el dominio y restaurar el monitoreo de dispositivos.
a.php — es el nombre del script en el lado del servidor. Sé que no es correcto nombrar variables y nombres de archivos con una sola letra... propongo considerar que así ahorramos algunos bytes al enviar la solicitud 🙂
u — es el nombre de usuario, el login del dispositivo.
p — es la contraseña.
"-O /tmp/wa.sh" — es el archivo en el enrutador remoto donde se guardará la respuesta del servidor, por ejemplo, el comando reboot.
Nota número dos: Ahhh, ¿por qué usamos wget y no curl, si con curl se pueden enviar solicitudes https y no solo GET, sino también POST? Ahhh, porque como en el viejo chiste "¡No cabe en la tinaja!". curl incluye bibliotecas de cifrado de aproximadamente 2 MB y debido a esto, es poco probable que puedas crear una imagen para un pequeño TP-LINK ML3020, por ejemplo. Pero con wget — adelante.
2) En el lado del servidor (yo tengo Ubuntu) usaremos Zabbix. ¿Por qué? Quiero que sea bonito (con gráficos) y conveniente (enviar comandos a través del menú contextual). Zabbix tiene algo encantador llamado agente de zabbix. A través del agente, llamaremos a un script php en servidor, que devolverá información sobre si nuestro enrutador se registró en el período de tiempo requerido. Para almacenar información sobre el tiempo de registro, comandos para dispositivos, utilizo MySQL, una tabla separada de usuarios con aproximadamente estos campos:
CREAR TABLA `usuarios` (
`id` varchar(25) NO NULL,
`passwd` varchar(25) NO NULL,
`descripcion` varchar(150) NO NULL,
`categoria` varchar(30) NO NULL,
`estado` varchar(10) NO NULL,
`ultimo_tiempo` varchar(20) NO NULL,
`ultima_ip` varchar(20) NO NULL,
`ultimo_puerto` int(11) NO NULL,
`tarea` text NO NULL,
`tarea_reg` varchar(150) NO NULL,
`ultima_tarea` text NO NULL,
`respuesta` text NO NULL,
`seq` int(11) NO NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8; Todos los fuentes se pueden obtener del repositorio de Git, en la dirección:
Ahora los scripts de PHP, que se colocan en el lado del servidor (para mayor comodidad se pueden colocar en la carpeta /usr/share/zabbix/):
Archivo a.php:
set_charset("utf8");
// aquí buscamos nuestro router en la tabla de la base de datos
$sql_users=$conn->prepare("SELECT task, reg_task, response, last_time FROM users WHERE id=? AND passwd=? AND status='active';");
$sql_users->bind_param('ss', $user, $password);
$sql_users->bind_result($task, $reg_task, $response, $last_time);
$sql_users->execute();
$sql_users->store_result();
if (($sql_users->num_rows)==1){
$sql_users->fetch();
// aquí le enviamos al router sus tareas
echo $task;
echo "n";
echo $reg_task;
// aquí registramos el tiempo de respuesta y la respuesta del router
$response_history="[".date("Y-m-d H:i")."] ".$message;
// tarea enviada, ahora debemos eliminarla y después registrarla en los logs como completada
$last_ip=$_SERVER["REMOTE_ADDR"];
$last_port=$_SERVER["REMOTE_PORT"];
$ts_last_conn_time=$last_time;
$sql_users=$conn->prepare("UPDATE users SET task='', seq=1 WHERE (id=?);");
$sql_users->bind_param('s', $user);
$sql_users->execute();
if (strlen($message)>1){
$sql_users=$conn->prepare("UPDATE users SET response=?, seq=1 WHERE (id=?);");
$sql_users->bind_param('ss', $response_history, $user);
$sql_users->execute();
}
// ahora debemos guardar el tiempo de registro del usuario, su IP y su mensaje. Por ahora solo el mensaje
$ts_now=time();
$sql_users=$conn->prepare("UPDATE users SET last_time=?, last_ip=?, last_port=? WHERE (id=?);");
$sql_users->bind_param('ssss', $ts_now, $last_ip, $last_port, $user);
$sql_users->execute();
}
// si no encontramos el router en nuestra base de datos, o su estado es "inactivo", se le enviará el comando reboot....
// ¿Por qué tan drástico? Porque a veces los routers desaparecen, y esta es una pequeña forma de castigar a los "nuevos propietarios".
else
{
echo "reboot";
}
$sql_users->close();
?>Archivo agent.php (este es el script del agente zabbix llamado):
set_charset("utf8");
$sql_users=$conn->prepare("SELECT seq FROM users WHERE id=? AND passwd=? AND status='active';");
$sql_users->bind_param('ss', $user, $password);
$sql_users->bind_result($seq);
$sql_users->execute();
$sql_users->store_result();
// El intercambio de datos se realiza a través del campo seq. Al registrar, el dispositivo establece este campo en "1"
if (($sql_users->num_rows)==1){
$sql_users->fetch();
echo $seq;
}
// Reiniciamos $seq.
$sql_users=$conn->prepare("UPDATE users SET seq=0 WHERE id=? AND passwd=? AND status='active';");
$sql_users->bind_param('ss', $user, $password);
$sql_users->execute();
$sql_users->close();
?> Y la etapa final: establecer el agente y añadir gráficos.
Si aún no tienes instalado el agente zabbix, entonces:
apt-get install zabbix-agentEditamos el archivo /etc/zabbix/zabbix_agentd.conf.
Añadimos la línea:
UserParameter=test,php /usr/share/zabbix/agent.php user password , donde:
test — el nombre de nuestro agente
„php /usr/share/zabbix/agent.php user password“ — el script llamado con las credenciales del dispositivo.
Añadir gráficos: abrimos la interfaz web de zabbix, en el menú elegimos:
Configuración -> Nodos de red -> Crear nodo de red. Aquí solo es necesario especificar el nombre del nodo de red, su grupo, interfaz del agente por defecto:
Ahora, para este nodo de red, necesitamos añadir un elemento de datos. Presta atención a dos campos: „clave“ — que es el parámetro que definimos en el archivo /etc/zabbix/zabbix_agentd.conf (en nuestro caso, test), y „intervalo de actualización“ — yo pongo 5 minutos, ya que el equipo también se registra en el servidor una vez cada cinco minutos.
Y añadimos el gráfico. Recomiendo elegir „Relleno“ como estilo de representación.
El resultado es algo muy conciso, por ejemplo así:
A la razonable pregunta: „¿valió la pena?“, responderé: claro, mira „razones para crear el ciclo“ al principio del artículo.
Si mi primera experiencia de grafomanía suscita interés entre los lectores, en los próximos artículos quiero describir cómo enviar comandos a equipos remotos. También he logrado implementar todo el esquema para dispositivos basados en RouterOS (Mikrotik).
Fuente: habr.com
