Buenas Tardes Lista , simplemente les estoy reenviando este email explicativo
con estos simples Shell Scripts
para los que les interese saber algo más del uso y configuración de estos
servidores Wireguard. Serán, 2 partes,
por ende el segundo email lo enviaré ya en la tarde posiblemente y tratará
sobre el Script Automático llamado helper en si.
El que realmente hace el trabajo duro !!! jejejeje
Cheers and Please Enjoy Responsibly !
JJ
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, December 24, 2020 12:32 PM, Juan J. Fdez #StayHome
<juanjfdez@xxxxxxxxxxxxxx> wrote:
Buenos Dias a ambos, como prometí anoche he aquí una breve explicación de
como funcionan estos Scripts del BASH o
Bourne Again Shell que es uno de los shell o intérpretes de comandos
disponibles en los sistemas Unix-Like como Linux.
Obviamente los SysAdmin usan los Scripts para automatizar muchas de las
tareas y funciones de los servidores y justamente
estos que menciono se ejecutan solamente cuando el server Wireguard se
"levanta" o activa (up y ya está automático via systemd) o
cuando por alguna razón se requiere "tumbarlo" o desactivarlo (down) para asi
no tener que manualmente ejecutar una serie de comandos
nuevamente.
Si se fijan en el inicio del fichero de configuración del interfaz wireguard
llamado /etc/wireguard/wg0.conf verán que entre otras cosas
hay 2 directivas dedicadas a PostUP y PostDowm respectivamente. REalmente
ambas son cuasi 100% identicas pues lo único que las
diferencia son las banderas -I en Post UP y -D en PostDown pues -I inserta
esas reglas en las IPTABLE o tablas de ruteo
y -D simplemente Delete esas mismas reglas en el PostDown o sea cuando se
deshabilita el wireguard (posible reboot, shutown , maintenance)
Vean PostUP apunta al Shell Script llamado add-nat-routing.sh que es el que
se ejecuta cuando se quiere iniciar o restart o habilitar el Server Wireguard
y similarmente PostDown apunta al Script remove-nat-routing.sh que se
ejecutaría al deshabilitar o tumbar el Server Wireguard.
A continuación vean el Script add-nat-routing.sh y recuerden todo esto está
en la carpeta /etc/wireguard con accesso restringido a solo ROOT o sea
a golpe de umask 077 para evitar otro user account o cuenta tenga acceso a
estas configuraciones del server wireguard.
*********************************************************************************************************************************************
## PostUP Script EXCLUSIVELY FOR AZURE because it uses 10.0.0.0/16 IP range ##
## Therefore in Azure the 172.16.0.0/12 range must be used to avoid conflict
##
#!/bin/bash
IPT="iptables"
IPT6="ip6tables"
IN_FACE="eth0" # NIC connected to the internet
WG_FACE="wg0" # WG NIC
SUB_NET="172.31.0.0/12" # WG IPv4 sub/net aka CIDR in the range 172.16.0.0 to
172.31.255.255
WG_PORT="51820" # WG udp port
SUB_NET_6="fd70:714:2002:726::/64" # WG IPv6 sub/net
## IPv4 ##
$IPT -t nat -I POSTROUTING 1 -s $SUB_NET -o $IN_FACE -j MASQUERADE
$IPT -I INPUT 1 -i $WG_FACE -j ACCEPT
$IPT -I FORWARD 1 -i $IN_FACE -o $WG_FACE -j ACCEPT
$IPT -I FORWARD 1 -i $WG_FACE -o $IN_FACE -j ACCEPT
$IPT -I INPUT 1 -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT
## IPv6 (Uncomment) ##
$IPT6 -t nat -I POSTROUTING 1 -s $SUB_NET_6 -o $IN_FACE -j MASQUERADE
$IPT6 -I INPUT 1 -i $WG_FACE -j ACCEPT
$IPT6 -I FORWARD 1 -i $IN_FACE -o $WG_FACE -j ACCEPT
$IPT6 -I FORWARD 1 -i $WG_FACE -o $IN_FACE -j ACCEPT
$IPT6 -I INPUT 1 -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT
********************************************************************************************************************************
Como ven realmente ambos Scripts, Up y Down o ADD y REMOVE, están habilitando
reglas para IPv4 y para IPv6
a pesar realmente aún el interfaz eth0 del server este en Azure no tiene
definido una dirección IPv6 Global Pública que
es algo IMHO pendiente de agregar por parte de Daniel me parece. Yo sugiero
que en el Azure web admin le asignen 1
IPv6 Pública Global que suelen ser de tipo 2006: o 2001: en su inicio por
ejemplo y porque usualmente ya veo en estos
sistemas cloud realmente te dan al menos 2 direcciones IPv6 Globales Públicas
gratuitas. Eso estaría abriendo un número
de posibilidades de enrutamiento y trasnporte para ese servidor pues aunque
es poco probable suceda puede que en algún
momento algun otro servidor o servicio falle en IPv4 pero siga funcionando en
IPv6 por ende los users en los túneles Wiregard estos
podrían seguir usando esos servicios caídos en IPv4 pues el server Wireguard
se los gestionaría en IPv6 (digamos Youtube cae
en IPv4 pero que siga funcionando en IPv6 por alguna bien rara e improbable
razón) . Además de que realmente en IPv6 al ser
un sistema mucho mas moderno es mucho mas eficiente su enrutamiento, y ya
incluso lso sistemas modernos tienden a siempre
intentar primero por IPv6 y si no funciona entonces revierten o "fallback"a
IPv4.
En AWS ese proceso para mi fué tan simple como asignar una subred IPv6 con
prefijo /56 o sea 56 bits a mi VPC o Virtual Private Computing
(yo escojí lo hiciera automático del pool de direcciones IPv6 de AWS pues
quizás asignar una de mi propio pool con HE o Hurricane electric quizás al
ser custom
si implique un pago mensual adicional) y después Asignar los 8 bits (56 + 8 =
64 bits del Ntwork ID) o XX a mi subred en el availability zone que uso para
mi server shark
en AWS. En mi caso escojí 1c para esos 8 bits y asi completar la porción de
64 bits del Network ID de esa IPv6 que automáticamente AWS me asignó.
Estoy mas que seguro que Azure sigue un proceso similar y que solo es
cuestión de leerse la documentación de ellos o consultar su propio foro por
ej.
Vean ahora el inicio de ese fichero de configuración del server Wireguard
(que por cierto con el comando dpkg-reconfigure tzdata he reconfigurado el
Huso Horario
a sincronizarlo con CST o Central Standard Time mas apropiado a San Antonio,
TX donde pareec estar el server en la nube de Azure) apenas solo
las primeras 7 líneas para evitar vean el PrivateKey del server , ejecutando
el comando
daniel@daniel:~$ sudo head -7 /etc/wireguard/wg0.conf
[Interface]
Address = 172.16.0.1/12
Address = fd70:714:2002:726::1/64
SaveConfig = true
PostUp = /etc/wireguard/add-nat-routing.sh
PostDown = /etc/wireguard/remove-nat-routing.sh
ListenPort = 51820
Y vean que además he adicionado la directiva SaveConfig = true con el
objetivo de que al menos cada vez que el server Wireguard se "tumbe o down"
por software
entonces que salve la configuración de los usuarios wireguard activos en ese
propio fichero wg0.conf para no tener que hacerlo manualmente.
OJO , regularmente se debe ejecutar el comando
sudo wg-quick save wg0
Que es el que va a hacer lo mismo mientras está el server activo, o sea graba
las config hasta ese momento de los users que los scripts automáticos hayan
creado,
aunque ciertamente al final del script daniel.helper.sh se pudiera agregar
ese comando pero yo sugiero no se haga asi, sino que se cree un cron job (o
mejor aun un timer en el nuevos sistema systemd)
que precisamente cada madrugada salve las configuraciones de los users
creados por os scripts ejecutados durante esa jornada. Es solo cuestión de
gustos.
Evidentemente el server Wireguard usa la primera dirección del rango
172.16.0.0/12 que va hasta el 172.31.255.255 por ende hasta mas de 1 millón
de posibles
direcciones IPv4 privadas lo cual me parece es mas que suficiente, al menos
por ahora inicialmente, y además vean que yo he asignado arbitrariamente
esa dirección privada local en IPv6 (las IPv6 Private empiezan con fd00/3 y
por favor no confundir con las de tipo Local-Link que empiezan con fe80 y que
usualmente
los sistemas basados en IPv6 generan automáticamente usando el método EIA-64
que agrega FFFE al medio de laa MAC address de una interfaz de red)
El resto de los users en este tunel wiregard comienzan por la IP terminada en
2 y como el script helper asigna 4 cuentas a cada user (para hasta 4
dispositivos, cell, computer, laptop y tablet)
por ende inicialmente daniel usa el rango del 172.16.0.2 al 172.16.0.5 y el
user orestes desde 0.6 al 0.9 y yo juanjfdez desde 0.10 al 0.13 y por último
hasta ahora el user cubacel desde 0.14 al 0.17
y similarmente las IPv6 privadas terminan en eso números IP mencionados.
ListenPort evidentemente define que puerto es el que el server Wireguard va a
estar escuchando las peticiones de conexión y sualmente el default es 51820 y
justamente
es via UDP pues Wireguard no usa TCP para evitar problemas de conectividad y
por eso siempre en los firewall o routers o el Security Group settings de
estas nubes AWS y Azure
hay que habilitar reglas inbound que permitan el trafico inbound en UDP 51820
o el puerto que se haya definido.
Verán que en esa carpeta /etc/wireguard hay un fichero llamado
daniel.welcome.txt que les sugiero personalizen a sus necesidades o servidor
pues vean ese
es el original de mi server shark y por ende solo menciona a mis servers y
mis emails para soporte técnico y por ende eso si va aconfundir a muchos
nuevos users
que reciban estos scripts automáticos.
Como les dije anoche en un email desde la propia consola Linux del server en
Azure, todo el sistema de email del server realmente está saliendo como si
fuera
del dominio mio abroadtelecom.net, y por ende cada email externo realmente
está pasando por mi Proxmox Mail Gateway aqui en mi casa para procesar
anti-spam y anti-virus
via el server SMTP EXIM4 que yo instalé en la madrugada para poder darle la
funcionalidad completa al 100% a esos scripts peus sino no había forma de
enviar
los emails sin que fueran a parar a los Junk o Spam folders o marcaran a su
server como spam relay o algo asi. Eso es solo un "stop-gap meassure" temporal
y les sugiero con tiempo piensen en como van a implementar su propio sistema
de servidor email pues estoy seguro en algún momento en el futuro lo
necesitarán, pero
obviamente no hay apuro con eso.
Normalmente para el funcionamiento de un server Wireguard o se requiere
almacenar las llaves privadas, publicas o los preshared keys, ni tampoco los
ficheros de
configuración o .conf ni mucho menos los QR Code generados pero yo prefiero
hacerlo (obviamente acceder todo eso requiere privilegios ROOT) por si en el
futuro
algún usuario pierde su configuración le sirva como backup y pueda ser
recuperada en vez de dado que todo es asignado IP manuales , desechar las IP
viejas
y asignarle una nueva lo cual me parece muy ineficiente, pero bueno, ese
script saniel.helper.sh que explicaré en un segundo email lo pueden modificar
según crean convenientey según sus necesidades.
De hecho si se fijan en el fichero wg0.conf a los efectos del server
Wireguard solo le interesa saber la llave pública de sus peers o clientes
aunque claro si tiene
que saber el IP privado que usa y el opcional presahred key asignado. No
obstante vean todos mis scripts asumen que el sistema sigue un patrón común
reconocible
desde los nombres de los ficheros hasta la propia estructura de directorios
de forma tal que todos tanto admins como users (incluído los hackers !
jejejeje) puedan facilmente
usar y administrar estos VPN Wireguard. Mi moto coincidentemente es el moto
de Bell, Making it Simple !.
Realmente ya esta trova es muy larga, pero me parece puede sea de interés
para algunos miembros de la lista cubacel asi que después de enviarles este
yo lo reenviaré de nuevo a la lista cubacel. Yo haré lo mismo con el Script
Automático llamado daniel.helper.sh pues ese realmente es un poco mas
complejo de
explicar me parece y obviamente también es modificable según su gusto o
necesidades.
Please Enjoy Responsibly,
Cheers
JJ
Sent with [ProtonMail](https://protonmail.com) Secure Email.
