Desde hace algunos días vengo experimentando problemas con mi conexión doméstica a Internet. Esto es un problema bastante molesto para mí, porque hago uso de una serie de servicios en un servidor casero que publico hacia el exterior. El principal de ellos es este sitio web, pero hay algunos adicionales, como algunos servicios de domótica y una conexión VPN para acceder de manera segura desde el exterior. Hasta ahora, venía publicándolo todo de manera directa, ya que disponía de una IPv4 con mi conexión, pero desde la semana pasada han pasado a darme acceso a Internet detrás de un CG-NAT. Esto implica que ya no dispongo de una IPv4 propia, sino que salgo a través de una NAT del operador, por lo que no es posible acceder de manera remota a dichos servicios.
Mientras me lo solucionan, he optado por poner en pie un mecanismo para poder seguir publicando servicios, basado en el uso de un pequeño servidor público que se encarga de redireccionar los servicios hacia mi sistema detrás del CG-NAT. Y para ello, hago uso de una plataforma que permite establecer redes securizadas mediante una combinación de SG-NAT y VPN, llamada ZeroTier. La gracia de ZeroTier es que el entorno funciona como un concentrador de VPNs, de tal manera que entre los clientes que necesitemos conectar se establece una red privada, con lo que es posible dotar de conectividad entre ellos a los mismos, tan sólo instalando un agente del propio ZeroTier entre ellos, y establecer la visibilidad oportuna entre nodos. Haciendo que el servidor publicado en Internet sea uno de los nodos, puedo proporcionar servicios utilizándolo de pasarela pública.
La segunda pata del asunto es conseguir este servidor frontal público, y hacer que funcione de pasarela. En mi caso, he optado por hacer uso de Oracle Cloud Infrastructure, donde se puede desplegar de manera gratuita un servidor basado en Linux. Y una vez que me he hecho con este servidor, he montado la pasarela con un servidor NGINX, debido a que me permite redireccionar tanto servicios publicados por TCP (mi servidor web y mi servidor MQTT) como UDP (mi servidor VPN), con lo que me ahorro tener que andar instalando y gestionando servicios duplicados en este frontal. Sencillo y eficiente. El diagrama general de cómo ha quedado el entorno es el siguiente:
La configuración a nivel interno sí que tiene algunos puntos a tener en cuenta:
stream {
upstream web_server {
server IP_PRIVADA_REMOTA_ZEROTIER:443;
}server {
listen 443;
ssl_preread on;
proxy_pass web_server;
}upstream mqtt_server {
server IP_PRIVADA_REMOTA_ZEROTIER:1883;
}
server {
listen 1883;
proxy_pass mqtt_server;
proxy_connect_timeout 1s;
}upstream vpn_server {
server IP_PRIVADA_REMOTA_ZEROTIER:1194;
}
server {
listen 1194 udp;
proxy_pass vpn_server;
}}
stream {
upstream vpn_server {
server IP_SERVIDOR_LOCAL_VPN:1194;
}
server {
listen 1194 udp;
proxy_pass vpn_server;
}}
En realidad, me gusta tanto cómo ha quedado configurado, que es posible que lo deje así incluso cuando se solucione el tema del CG-NAT, ya que añade una capa extra de seguridad y disponibilidad a mis sistemas.
Referencias:
How to bypass CGNAT and expose your server to the internet using ZeroTier, a VPS and NGINX
Bypassing a CGNAT with Wireguard (Especialmente útil para la parte de configuración del entorno en Oracle Cloud)
How to set nginx reverse proxy to an SSL site without certificate?
Etiquetas: cg-nat, iot, mqtt, nginx, oracle cloud, vpn, vps, wordpress, zerotier
En fechas recientes he realizado un cambio de arquitectura en mi sitio web: he pasado de un servidor con WordPress colgado directamente en Internet a utilizar un frontal NGNIX como proxy inverso a la hora de acceder al sitio web. Hay diversas razones para ello, pero la principal está centrada en la seguridad. Sin embargo, esta arquitectura tiene una contrapartida: dado que el proxy inverso realiza una conversión SNAT de la dirección IP, el servidor WordPress interpreta que todas las peticiones vienen del proxy -lo que en realidad es rigurosamente cierto-, perdiéndose la información relativa a la IP real del equipo desde el que el usuario final accede.
Por suerte, este comportamiento se puede manipular. La idea general es incrustar la IP del cliente final en un campo cabecera (X-Forwarded-For), y luego modificar el comportamiento de WordPress para que haga uso de la IP contenida en esta cabecera como la IP del usuario. La receta para ello es la siguiente:
proxy_set_header X-Forwarded-For $remote_addr;
// Use X-Forwarded-For HTTP Header to Get Visitor's Real IP Address
if ( isset( $_SERVER['HTTP_X_FORWARDED_FOR'] ) ) {
$http_x_headers = explode( ',', $_SERVER['HTTP_X_FORWARDED_FOR'] );
$_SERVER['REMOTE_ADDR'] = $http_x_headers[0];
}
Et voilà! A partir de este momento, nuestro WordPress pasa a mostrar de nuevo correctamente las IPs con la que se accede por parte de los usuarios del sitio a nuestro contenido.
Etiquetas: nginx, proxy inverso, wordpress, x-forwarded-for
El ciclismo, como sabe cualquiera que lea un poco estas páginas, es una de mis grandes pasiones. Disfruto con el ciclismo de carretera, pero tengo especial predilección por el ciclismo de montaña. Afición que, afortunadamente, comparto con una buena cantidad de amigos. Hace ya algún tiempo, en una charla con Mané, estuvimos hablando sobre la creación de un foro para nuestro grupo de amigos en el que pudiéramos charlar de las etapas, planificar salidas, y poder contar cosas en general sobre nuestra común afición.
Tiempo después, me encontré con un pequeño problema: desde hace un año registro todas las salidas que hacemos con la bici en archivos GPX, a fin de tenerlas documentadas para posteriores salidas, así como material para realizar los relatos con los que me gusta recordar las etapas. El almacenaje de esos gpx se estaba volviendo un tanto caótico (ya que no contenía referencias o datos más allá de la fecha del fichero), por lo que se me ocurrió poder utilizar algún gestor documental para almacenar las etapas de manera más ordenada, y que a la vez me sirviera de copia de seguridad de mi registro de archivos.
Fue entonces cuando se me ocurrió que podía aprovechar un gestor de contenidos con el que tengo bastante esperiencia, WordPress, para solucionar ambos problemas. Y fruto de esa idea fue como nació MTB A Fondo.
MTB a Fondo ha sido creado como una pequeña red social especializada en ciclismo; su principal función es que los aficionados al ciclismo podamos compartir noticias, ideas, experiencias y conocimiento. Es una herramienta pensada para ser usada por nuestro grupo de amigos, pero que está abierta a cualquiera que quiera participar. Originariamente fue creada como una sección de mi página principal (www.eniac2000.com), pero como me aconsejó mi buen amigo Manolo, si quería darle algo de vidilla, era más conveniente crear la red como una web aparte. Y así fue como me decidí a compar el dominio www.mtbafondo.es
En cuanto a su estructura, está formada por los siguientes elementos:
He hablado un poco de las principales funcionalidades que ofrece MTB a Fondo, pero existen otras dignas de destacar:
Otros Mundos
Otra de las cosas que he procurado proporcionar con MTB a Fondo es una facilidad para seguir la actividad del sitio. Esto no se limita al seguimiento mediante RSS que comentaba antes, sino que he integrado la publicación de la actividad de la página en Facebook y en Twitter:
Creo que con esto he desgranado lo más importante de la página, en lo que se refiere a los aspectos técnicos. Pero una web social no es nada sin sus usuarios. Por ello, animo a cualquiera que quiera participar en el sitio a que se registre, participe, disfrute con la página, y que la haga suya. ¡Adelante!
Etiquetas: buddypress, facebook, gps, gpx, mtb, mtb a fondo, twitter, wordpress
Gracias a Ángel (¡gracias nen!) he visto que desde que actualicé el plugin que despliega el captcha para usuarios no autenticados (es decir, todo el mundo menos yo) no se podían escribir comentarios. Todo era un tema de permisos de escritura en el servidor, que ya ha quedado corregido. ^_^
Estaba ya a punto de empezar a cantar aquello de estoy solo, no me quieren…
Etiquetas: captcha, comentarios, permisos, plugin, wordpress
El sistema que utilizo para publicar este sitio web es el siguiente: se utiliza como base el gestor de contenidos WordPress, complementado con algunas soluciones periféricas. La principal de ellas es la integración con el sistema de gestión de galerías fotográficas Gallery2, que se realiza mediante un plugin diseñado al efecto: WPG2.
No todas las fotografías que publico son gestionadas mediante Gallery2. Para fotografías sueltas utilizo el propio sistema de WordPress, pero cuando inserto referencias a una serie fotográfica (correspondiente a algún viaje o evento concreto) sí que suelo utilizar Gallery2. El sistema es bastante simple: una vez subidas las fotografías a Gallery2 y catalogadas por éste, desde WordPress sólo es necesario hacer referencia al identificador de la imagen mediante la etiqueta <wpg2id> para insertar la imagen en la entrada. Con esta referencia, el artículo muestra una versión reducida de la imagen, y un enlace a la imagen original dentro de la estructura de la galería de imágenes, adaptada para su visualización en WordPress,
Por lo general, el sistema funciona bastante bien. Sin embargo, desde hacía tiempo había observado un problema con las imágenes panorámicas, en las que existe una gran diferencia entre el ancho y el alto de la imagen: cuando insertaba una imagen mediante el sistema explicado anteriormente, en el caso de las fotografías panorámicas no se mostraba la miniatura de la imagen, sino la imagen completa, pero escalada al tamaño de la miniatura definida. Los problemas que esto provoca, especialmente en tiempo de carga, eran significativos, ya que algunas de las panorámicas pueden alcanzar tamaños de más de 10000×2000 píxels, y pesos superiores a los 10 MB, mientras que las miniaturas asociadas tienen unas dimensiones máximas de 400 píxels en su lado más grande, y pesos inferiores a los 30 KB.
Tras un tiempo de investigación, he conseguido dar con una solución al problema, en los foros de Gallery: <wpg2> tags use always full-size versions En una de las entradas, uno de los usuarios informa de que el problema se debe al método en el que el sistema estudia si ha de escoger mostrar una miniatura o la versión completa de la imagen, aunque escalada. Para determinar esto el sistema compara el ancho y el alto de la imagen. Esta comparación, si bien resulta adecuada para la mayoría de las imágenes, produce problemas en aquellas con importantes diferencias entre ancho y alto, como es el caso de las panorámicas. Ante ello, el usuario propone hacer uso sólo del ancho. Para ello, es necesario realizar modificaciones en el archivo ImageBlockHelper.class, ubicada en el directorio /modules/imageblock/classes de Gallery2 (en mi caso, al usar el paquete Debian, su ruta completa es /usr/share/gallery2/modules/imageblock/classes). En concreto, es necesario realizar unas modificaciones a partir de la línea 424 del archivo:
/* Get the list of resizes */
$resizes = array();
list ($ret, $ok) = GalleryCoreApi::hasItemPermission(
$derivativeParentId, 'core.viewResizes', $userId);
if ($ret) {
return array($ret, null);
}
if ($ok) {
list ($ret, $resizes) =
GalleryCoreApi::fetchResizesByItemIds(array($derivativeParentId));
if ($ret) {
return array($ret, null);
}
$resizes = isset($resizes[$derivativeParentId]) ? $resizes[$derivativeParentId]
: array();
}
if (isset($thumbnail)) {
$resizes[] = $thumbnail;
}
foreach ($resizes as $imageObject) {
/*Primera modificacion*/
/* $rawDifferential = ($imageObject->getHeight() - $maxSize)
+ ($imageObject->getWidth() - $maxSize);*/
$rawDifferential = ($imageObject->getWidth() - $maxSize);
if ($biggerOnly && $rawDifferential < 0) {
continue;
}
$resizeDifferential = abs($rawDifferential);
/*Segunda modificacion*/
/* $resizeSize = $imageObject->getHeight() * $imageObject->getWidth();*/
$resizeSize = $imageObject->getWidth();
/*
* If this differential is smaller than the last, update the image target and
* the comparison value.
* If two differentials are equidistant, use the larger based on image size.
*/
if ($resizeDifferential < $imageDifferential
|| $resizeDifferential == $imageDifferential
&& $resizeSize > $imageSize) {
$image = $imageObject;
$imageDifferential = $resizeDifferential;
$imageSize = $resizeSize;
}
}
}
Una vez hecho esto, en WordPress se empezarán a mostrar correctamente las miniaturas de las imágenes en vez de las versiones escaladas de las imágenes completas, en el caso de las panorámicas.
Etiquetas: debian, gallery2, panorámica, wordpress, wpg2