🥇Construyendo un enrutador en SOCKS en un portátil con Debian 10

Durante un año (o dos) he postergado la publicación de este artículo por una razón principal: ya había publicado dos artículos en los que describía el proceso de creación de un enrutador SOCKS a partir de una laptop común con Debian.

Sin embargo, desde entonces la versión estable de Debian se ha actualizado a Buster, y he recibido suficientes mensajes de personas pidiendo ayuda con la configuración, lo que significa que mis artículos anteriores no son exhaustivos. Bueno, yo mismo sospechaba que los métodos descritos en ellos no revelan todos los matices de la configuración de Linux para enrutamiento en SOCKS. Además, estaban escritos para Debian Stretch, y después de actualizar a Buster, en el sistema de inicialización systemd, noté algunos cambios menores en la interacción de los servicios. Y en los propios artículos no utilicé systemd-networkd, aunque es la más adecuada para configuraciones de red complejas.

Además de los cambios mencionados anteriormente, se añadieron a mi configuración servicios como hostapd — un servicio para la virtualización de puntos de acceso, ntp para sincronizar el tiempo de los clientes de la red local, dnscrypt-proxy para cifrar las conexiones mediante el protocolo DNS y bloquear la publicidad en los clientes de la red local, así como, como mencioné anteriormente, systemd-networkd para configurar las interfaces de red.

Aquí hay un esquema básico del funcionamiento interno de un enrutador de este tipo.

Así que recordaré cuáles son los objetivos que persigue este ciclo de artículos:

Enrutar todas las conexiones del sistema operativo SOCKS, así como las conexiones de todos los dispositivos en la misma red que la laptop.
La laptop en mi caso debe permanecer completamente móvil. Es decir, debería permitir el uso del entorno de escritorio y no estar sujeta a una ubicación física.
El último punto implica la conexión y enrutamiento únicamente a través de la interfaz inalámbrica integrada.
Y, por supuesto, crear una guía exhaustiva, así como analizar las tecnologías pertinentes según mis humildes conocimientos.

Lo que se tratará en este artículo:

git — descargaremos los repositorios de los proyectos tun2socks, necesarios para enrutamiento de tráfico TCP a SOCKS, y create_ap — un script para automatizar la configuración de un punto de acceso virtual usando hostapd.
tun2socks — construiremos e instalaremos un servicio systemd en el sistema.
systemd-networkd — configuraremos las interfaces inalámbricas y virtuales, las tablas de enrutamiento estático y la redirección de paquetes.
create_ap — instalaremos el servicio systemd en el sistema, configuraremos y activaremos un punto de acceso virtual.

Pasos opcionales:

ntp — instalaremos y configuraremos un servidor para la sincronización de tiempo en los clientes del punto de acceso virtual.
dnscrypt-proxy — ciframos las solicitudes DNS, las enrutamos a SOCKS y desactivamos los dominios publicitarios para la red local.

¿Por qué todo esto?

Es una de las formas de organizar la protección de las conexiones TCP en la red local. La principal ventaja es que todas las conexiones se dirigen a SOCKS, a menos que se construya una ruta estática a través de la puerta de enlace original. Esto significa que no es necesario configurar el servidor SOCKS para aplicaciones individuales o clientes en la red local; todos van a SOCKS por defecto, ya que es la puerta de enlace predeterminada, a menos que indique lo contrario.

En esencia, estamos agregando un segundo router cifrante en forma de un portátil delante del router original y utilizamos la conexión a internet del router original para las ya cifradas solicitudes SOCKS del portátil, que, a su vez, enruta y cifra las solicitudes de los clientes de la red local.

Desde el punto de vista del proveedor, estamos constantemente conectados a un solo servidor con tráfico cifrado.

Por lo tanto, todos los dispositivos se conectan al punto de acceso virtual del portátil.

Instala tun2socks en el sistema

Mientras tengas internet en tu máquina, descarga todas las herramientas necesarias.

apt update

apt install git make cmake

Descarga el paquete badvpn

git clone https://github.com/ambrop72/badvpn

Aparecerá una carpeta en tu sistema badvpn. Crea una carpeta separada para la compilación

mkdir badvpn-build

Cambia a ella

cd badvpn-build

Compila tun2socks

cmake ../badvpn -DBUILD_NOTHING_BY_DEFAULT=1 -DBUILD_TUN2SOCKS=1

Instala en el sistema

make install

Parámetro -DBUILD_NOTHING_BY_DEFAULT=1 desactiva la compilación de todos los componentes del repositorio badvpn.
—DBUILD_TUN2SOCKS=1 incluye en la compilación el componente tun2socks.
make install — instalará el binario tun2socks en tu sistema en la dirección /usr/local/bin/badvpn-tun2socks.

Instala el servicio tun2socks en systemd

Cree un archivo /etc/systemd/system/tun2socks.service con el siguiente contenido:

[Unit]
Description=SOCKS TCP Relay

[Service]
ExecStart=/usr/local/bin/badvpn-tun2socks --tundev tun2socks --netif-ipaddr 172.16.1.1 --netif-netmask 255.255.255.0 --socks-server-addr 127.0.0.1:9050

[Install]
WantedBy=multi-user.target

--tundev — recibe el nombre de la interfaz virtual que inicializamos usando systemd-networkd.
--netif-ipaddr — la dirección de red del "enrutador" tun2socks, al que se conecta la interfaz virtual. Es mejor hacerla una subred reservada separada..
--socks-server-addr — recibe el socket (dirección:puerto del servidor SOCKS).

Si tu servidor SOCKS requiere autenticación, puedes especificar los parámetros. --nombre de usuario y --contraseña.

A continuación, registre el servicio

systemctl daemon-reload

E incluya

systemctl enable tun2socks

Antes de iniciar el servicio, proporcionemos una interfaz de red virtual.

Pasamos a systemd-networkd

Activamos systemd-networkd:

systemctl enable systemd-networkd

Desactivamos los servicios de red actuales.

systemctl disable networking NetworkManager NetworkManager-wait-online

NetworkManager-wait-online — es un servicio que espera la disponibilidad de una conexión de red activa antes de que systemd continúe iniciando otros servicios que dependen de la red. Lo desactivamos, ya que pasaremos a un equivalente de systemd-networkd.

Habilitemos esto de inmediato:

systemctl enable systemd-networkd-wait-online

Configure la interfaz de red inalámbrica

Cree un archivo de configuración de systemd-networkd para la interfaz de red inalámbrica /etc/systemd/network/25-wlp6s0.network.

[Match]
Name=wlp6s0

[Network]
Address=192.168.1.2/24
IPForward=yes

Nombre — este es el nombre de su interfaz inalámbrica. Identifíquelo con el comando ip a.
IPForward — es una directiva que habilita el reenvío de paquetes en la interfaz de red.
Address es responsable de asignar una dirección IP a la interfaz inalámbrica. Lo especificamos de forma estática porque en la directiva equivalente DHCP=yes, systemd-networkd crea un gateway predeterminado en el sistema. Entonces, todo el tráfico irá a través del gateway original y no a través de la futura interfaz virtual en una subred diferente. Puede verificar el gateway predeterminado actual con el comando ip r

Cree una ruta estática para el servidor SOCKS remoto

Si su servidor SOCKS no es local, sino remoto, necesita crear una ruta estática para él. Para ello, añada la sección Route al final del archivo de configuración de su interfaz inalámbrica con el siguiente contenido:

[Route]
Gateway=192.168.1.1
Destination=0.0.0.0

Puerta de enlace — este es el gateway predeterminado o la dirección de su punto de acceso original.
Destino — dirección del servidor SOCKS.

Configure wpa_supplicant para systemd-networkd

systemd-networkd utiliza wpa_supplicant para conectarse a un punto de acceso protegido. Al intentar "levantar" la interfaz inalámbrica, systemd-networkd inicia el servicio wpa_supplicant@nombre, donde nombre — este es el nombre de la interfaz inalámbrica. Si no ha utilizado systemd-networkd hasta ahora, seguramente este servicio no está presente en su sistema.

Por lo tanto, créelo con el comando:

systemctl enable wpa_supplicant@wlp6s0

He utilizado wlp6s0 como el nombre de su interfaz inalámbrica. Este nombre puede diferir en su caso. Puede averiguarlo con el comando ip l.

Ahora el servicio creado wpa_supplicant@wlp6s0 se iniciará al "levantar" la interfaz inalámbrica, sin embargo, buscará la configuración del SSID y la contraseña del punto de acceso en el archivo /etc/wpa_supplicant/wpa_supplicant-wlp6s0. Por lo tanto, es necesario crear uno utilizando la utilidad wpa_passphrase.

Para ello, ejecute el siguiente comando:

wpa_passphrase SSID password>/etc/wpa_supplicant/wpa_supplicant-wlp6s0.conf

donde SSID es el nombre de su punto de acceso, password es la contraseña, y wlp6s0 es el nombre de su interfaz inalámbrica.

Inicialice la interfaz virtual para tun2socks

Cree un archivo para inicializar la nueva interfaz virtual en el sistema/etc/systemd/network/25-tun2socks.netdev

[NetDev]
Name=tun2socks
Kind=tun

Nombre es el nombre que systemd-networkd asignará a la futura interfaz virtual al inicializarla.
Kind es el tipo de interfaz virtual. Como sugiere el nombre del servicio tun2socks, puede adivinar que usa una interfaz de tipo tun.
netdev es la extensión de archivos que systemd-networkd utiliza para inicializar las interfaces de red virtuales. La dirección y otras configuraciones de red para estas interfaces se especifican en .network-archivos.

Cree un archivo como este /etc/systemd/network/25-tun2socks.network con el siguiente contenido:

[Match]
Name=tun2socks

[Network]
Address=172.16.1.2/24
Gateway=172.16.1.1

Nombre es el nombre de la interfaz virtual que especificó en netdev-archivo.
Address es la dirección IP que se asignará a la interfaz virtual. Debe estar en la misma red que la dirección que indicó en el servicio tun2socks
Puerta de enlace es la dirección IP del "enrutador" tun2socks, que indicó al crear el servicio systemd.

Por lo tanto, la interfaz tun2socks tiene la dirección 172.16.1.2, y el servicio tun2socks — 172.16.1.1, es decir, es la puerta de enlace para todas las conexiones desde la interfaz virtual.

Configure el punto de acceso virtual

Instale las dependencias:

apt install util-linux procps hostapd iw haveged

Descargue el repositorio create_ap en su máquina:

git clone https://github.com/oblique/create_ap

Navegue a la carpeta del repositorio en su máquina:

cd create_ap

Instale en el sistema:

make install

Aparecerá un archivo de configuración en su sistema. /etc/create_ap.confEstas son las principales opciones para editar:

GATEWAY=10.0.0.1 es mejor hacerlo como una subred reservada separada.
NO_DNS=1 desactívelo, ya que este parámetro será gestionado por la interfaz virtual systemd-networkd.
NO_DNSMASQ=1 desactívelo por la misma razón.
WIFI_IFACE=wlp6s0 la interfaz inalámbrica de la laptop.
INTERNET_IFACE=tun2socks la interfaz virtual creada para tun2socks.
SSID=hostapd es el nombre del punto de acceso virtual.
PASSPHRASE=12345678 es la contraseña.

No olvide habilitar el servicio:

systemctl enable create_ap

Habilite el servidor DHCP en systemd-networkd.

El servicio create_ap inicializa en el sistema la interfaz virtual ap0. En teoría, dnsmasq está «colgado» en esta interfaz, pero ¿por qué instalar servicios innecesarios si systemd-networkd incluye un servidor DHCP integrado?

Para habilitarlo, definamos la configuración de red para el punto virtual. Para ello, cree un archivo /etc/systemd/network/25-ap0.network con el siguiente contenido:

[Match]
Name=ap0

[Network]
Address=10.0.0.1/24
DHCPServer=yes

[DHCPServer]
EmitDNS=yes
DNS=10.0.0.1
EmitNTP=yes
NTP=10.0.0.1

Después de que el servicio create_ap inicialice la interfaz virtual ap0, systemd-networkd le asignará automáticamente una dirección IP y habilitará el servidor DHCP.

Las líneas EmitDNS=yes y DNS=10.0.0.1 transmiten la configuración del servidor DNS a los dispositivos conectados al punto de acceso.

Si no planea usar un servidor DNS local — en mi caso, dnscrypt-proxy — puede establecer DNS=10.0.0.1 en DNS=192.168.1.1, donde 192.168.1.1 — la dirección de su puerta de enlace original. Así, las solicitudes DNS de su host y red local se enviarán sin cifrar a través de los servidores del proveedor.

EmitNTP=yes y NTP=192.168.1.1 transmiten la configuración NTP.

Lo mismo aplica para la línea NTP=10.0.0.1.

Instale y configure el servidor NTP

Instale en el sistema:

apt install ntp

Edite la configuración /etc/ntp.conf. Comente las direcciones de los grupos estándar:

#pool 0.debian.pool.ntp.org iburst
#pool 1.debian.pool.ntp.org iburst
#pool 2.debian.pool.ntp.org iburst
#pool 3.debian.pool.ntp.org iburst

Agregue las direcciones de servidores públicos, como Google Public NTP:

server time1.google.com iburst
server time2.google.com iburst
server time3.google.com iburst
server time4.google.com iburst

Proporcione acceso al servidor a clientes de su red:

restrict 10.0.0.0 mask 255.255.255.0

Habilite la transmisión en su red:

broadcast 10.0.0.255

Finalmente, agregue las direcciones de estos servidores en la tabla de enrutamiento estática. Para ello, abra el archivo de configuración de la interfaz inalámbrica /etc/systemd/network/25-wlp6s0.network y añada al final de la sección Route.

[Route]
Gateway=192.168.1.1
Destination=216.239.35.0

[Route]
Gateway=192.168.1.1
Destination=216.239.35.4

[Route]
Gateway=192.168.1.1
Destination=216.239.35.8

[Route]
Gateway=192.168.1.1
Destination=216.239.35.12

Puede averiguar las direcciones de sus servidores NTP utilizando la utilidad host de la siguiente manera:

host time1.google.com

Instale dnscrypt-proxy, elimine anuncios y oculte el tráfico DNS del proveedor

apt install dnscrypt-proxy

Para atender las solicitudes DNS del host y la red local, edite el socket /lib/systemd/system/dnscrypt-proxy.socket. Cambie las siguientes líneas:

ListenStream=0.0.0.0:53
ListenDatagram=0.0.0.0:53

Reinicie systemd:

systemctl daemon-reload

Edite la configuración /etc/dnscrypt-proxy/dnscrypt-proxy.toml:

server_names = ['adguard-dns']

Para dirigir las conexiones de dnscrypt-proxy a través de tun2socks, añada a continuación:

force_tcp = true

Edite la configuración /etc/resolv.conf, que indica al servidor DNS el host.

nameserver 127.0.0.1
nameserver 192.168.1.1

La primera línea habilita el uso de dnscrypt-proxy, la segunda utiliza la puerta de enlace original, en caso de que el servidor dnscrypt-proxy no esté disponible.

¡Listo!

Reinicie o detenga los servicios de red actuales:

systemctl stop networking NetworkManager NetworkManager-wait-online

Y reinicie todos los necesarios:

systemctl restart systemd-networkd tun2socks create_ap dnscrypt-proxy ntp

Después del reinicio o la reanudación, tendrás un segundo punto de acceso que enruta el host y los dispositivos de la red local a SOCKS.

Así es como se ve la salida ip a de un portátil normal:

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: tun2socks:  mtu 1500 qdisc pfifo_fast state UP group default qlen 500
    link/none 
    inet 172.16.1.2/24 brd 172.16.1.255 scope global tun2socks
       valid_lft forever preferred_lft forever
    inet6 fe80::122b:260:6590:1b0e/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
3: enp4s0:  mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether e8:11:32:0e:01:50 brd ff:ff:ff:ff:ff:ff
4: wlp6s0:  mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 4c:ed:de:cb:cf:85 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global wlp6s0
       valid_lft forever preferred_lft forever
    inet6 fe80::4eed:deff:fecb:cf85/64 scope link 
       valid_lft forever preferred_lft forever
5: ap0:  mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 4c:ed:de:cb:cf:86 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 brd 10.0.0.255 scope global ap0
       valid_lft forever preferred_lft forever
    inet6 fe80::4eed:deff:fecb:cf86/64 scope link 
       valid_lft forever preferred_lft forever

En resumen

El proveedor solo ve una conexión cifrada a tu servidor SOCKS, por lo que no ve nada.
Sin embargo, él puede ver tus solicitudes NTP; para prevenir esto, elimina las rutas estáticas para los servidores NTP. Sin embargo, no es seguro que tu servidor SOCKS soporte el protocolo NTP.

Una solución alternativa, notada en Debian 10

Si intentas reiniciar el servicio de red desde la consola, fallará con un error. Esto se debe a que una parte de él, como interfaz virtual, está vinculada al servicio tun2socks, y por lo tanto está en uso. Para reiniciar el servicio de red, primero debes detener el servicio tun2socks. Pero, creo que si has leído hasta aquí, ¡esto no será un problema para ti!