🥇 Construire un routeur SOCKS sur un ordinateur portable avec Debian 10

Cela fait un an (ou deux) que je repousse la publication de cet article pour une raison principale : j'avais déjà publié deux articles où j'ai décrit le processus de création d'un routeur SOCKS à partir d'un simple ordinateur portable avec Debian.

Cependant, depuis lors, la version stable de Debian a été mise à jour vers Buster, et un nombre suffisant de personnes m'a contacté en privé pour demander de l'aide dans la configuration, ce qui signifie que mes précédents articles ne sont pas exhaustifs. Eh bien, je me doutais déjà que les méthodes décrites dans ces articles ne dévoilaient pas toutes les subtilités de la configuration de Linux pour le routage SOCKS. De plus, ils étaient écrits pour Debian Stretch, et après la mise à jour vers Buster, j'ai remarqué quelques changements mineurs dans l'interaction des services avec le système d'initialisation systemd. Et dans les articles eux-mêmes, je n'ai pas utilisé systemd-networkd, bien qu'il convienne mieux aux configurations réseau complexes.

En plus des modifications mentionnées ci-dessus, ma configuration a vu l'ajout de services tels que hostapd — un service pour la virtualisation du point d'accès, ntp pour la synchronisation de l'heure des clients du réseau local, dnscrypt-proxy pour le chiffrement des connexions par le protocole DNS et le blocage des publicités sur les clients du réseau local, ainsi que, comme je l'ai mentionné précédemment, systemd-networkd pour la configuration des interfaces réseau.

Voici un schéma simple de l'architecture interne d'un tel routeur.

Donc, je vais rappeler quels objectifs ce cycle d'articles poursuit :

Routage dans SOCKS de toutes les connexions du système d'exploitation, ainsi que des connexions de tous les appareils connectés au même réseau que le portable.
Le portable, dans mon cas, doit rester entièrement mobile. Cela signifie permettre l'utilisation d'un environnement de bureau sans être attaché à un emplacement physique.
Le dernier point implique une connexion et un routage uniquement via l'interface sans fil intégrée.
Et bien sûr, créer un guide exhaustif ainsi qu'une analyse des technologies correspondantes dans la mesure de mes modestes connaissances.

Ce qui sera abordé dans cet article :

git — nous allons télécharger les dépôts des projets tun2socks, nécessaire pour le routage du trafic TCP vers SOCKS, et create_ap — un script pour automatiser la configuration d'un point d'accès virtuel à l'aide de hostapd.
tun2socks — nous allons construire et installer le service systemd dans le système.
systemd-networkd — nous allons configurer les interfaces sans fil et virtuelles, les tables de routage statiques et le redirection des paquets.
create_ap — nous allons installer le service systemd dans le système, configurer et démarrer le point d'accès virtuel.

Étapes facultatives :

ntp — nous allons installer et configurer un serveur pour synchroniser le temps sur les clients du point d'accès virtuel.
dnscrypt-proxy — nous allons crypter les requêtes DNS, les router vers SOCKS et désactiver les domaines publicitaires pour le réseau local.

Pourquoi tout cela ?

C'est l'un des moyens d'organiser la protection des connexions TCP du réseau local. L'avantage principal est que toutes les connexions passent par SOCKS, sauf si un routage statique a été établi via la passerelle d'origine. Cela signifie qu'il n'est pas nécessaire de configurer le serveur SOCKS pour des programmes séparés ou pour les clients du réseau local — ils passent tous par SOCKS par défaut, puisque c'est la passerelle par défaut, jusqu'à ce que nous indiquions le contraire.

En essence, nous ajoutons un deuxième routeur cryptant en tant que portable devant le routeur d'origine et utilisons la connexion Internet du routeur d'origine pour les requêtes SOCKS déjà cryptées du portable, qui, à son tour, route et chiffre les requêtes des clients du réseau local.

Du point de vue du fournisseur, nous sommes constamment connectés à un serveur avec du trafic crypté.

En conséquence, tous les appareils se connectent au point d'accès virtuel du portable.

Installez tun2socks dans le système

Tant que votre machine est connectée à Internet, téléchargez tous les outils nécessaires.

apt update

apt install git make cmake

Téléchargez le paquet badvpn

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

Un dossier apparaîtra dans votre système badvpn. Créez un dossier séparé pour la compilation

mkdir badvpn-build

Accédez-y

cd badvpn-build

Compilez tun2socks

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

Installez dans le système

make install

Paramètre -DBUILD_NOTHING_BY_DEFAULT=1 désactive la compilation de tous les composants du dépôt badvpn.
—DBUILD_TUN2SOCKS=1 active la compilation du composant tun2socks.
make install — installe l'exécutable tun2socks dans votre système à l'adresse /usr/local/bin/badvpn-tun2socks.

Installez le service tun2socks dans systemd

Créez un fichier /etc/systemd/system/tun2socks.service avec le contenu suivant :

[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 — accepte le nom de l'interface virtuelle que nous initialisons avec systemd-networkd.
--netif-ipaddr — l'adresse réseau du « routeur » tun2socks, à laquelle se connecte l'interface virtuelle. Il est préférable de créer un sous-réseau réservé distinct. sous-réseau réservé.
--socks-server-addr — accepte le socket (adresse:port du serveur SOCKS).

Si votre serveur SOCKS nécessite une authentification, vous pouvez spécifier les paramètres --username et --password.

Ensuite, enregistrez le service

systemctl daemon-reload

Et activez

systemctl enable tun2socks

Avant de lancer le service, assurons-nous qu'il dispose d'une interface réseau virtuelle.

Passons à systemd-networkd

Nous activons systemd-networkd:

systemctl enable systemd-networkd

Désactivons les services réseau actuels.

systemctl disable networking NetworkManager NetworkManager-wait-online

NetworkManager-wait-online — est un service qui attend la disponibilité d'une connexion réseau fonctionnelle avant que systemd ne continue à démarrer d'autres services dépendant de la présence du réseau. Nous le désactivons, car nous allons passer à l'équivalent systemd-networkd.

Activons-le tout de suite :

systemctl enable systemd-networkd-wait-online

Configurez l'interface réseau sans fil

Créez un fichier de configuration systemd-networkd pour l'interface réseau sans fil /etc/systemd/network/25-wlp6s0.network.

[Match]
Name=wlp6s0

[Network]
Address=192.168.1.2/24
IPForward=yes

Nom — est le nom de votre interface sans fil. Identifiez-le avec la commande ip a.
IPForward — est une directive qui active le transfert de paquets sur l'interface réseau.
Address est responsable de l'attribution de l'adresse IP à l'interface sans fil. Nous l'indiquons de manière statique car, avec la directive équivalente DHCP=yes, systemd-networkd crée une passerelle par défaut dans le système. Alors tout le trafic passera par la passerelle d'origine, et non par la future interface virtuelle dans un sous-réseau différent. Vous pouvez vérifier la passerelle par défaut actuelle avec la commande ip r

Créez une route statique pour le serveur SOCKS distant

Si votre serveur SOCKS n'est pas local mais distant, vous devez créer une route statique pour celui-ci. Pour cela, ajoutez une section Route à la fin du fichier de configuration de votre interface sans fil avec le contenu suivant :

[Route]
Gateway=192.168.1.1
Destination=0.0.0.0

Gateway — est la passerelle par défaut ou l'adresse de votre point d'accès d'origine.
Destination — est l'adresse du serveur SOCKS.

Configurez wpa_supplicant pour systemd-networkd

systemd-networkd utilise wpa_supplicant pour se connecter à un point d'accès sécurisé. Lorsqu'il tente de « lever » l'interface sans fil, systemd-networkd lance le service wpa_supplicant@nom, où nom — c'est le nom de l'interface sans fil. Si vous n'avez pas utilisé systemd-networkd jusqu'à présent, ce service est probablement absent de votre système.

Donc, créez-le avec la commande :

systemctl enable wpa_supplicant@wlp6s0

J'ai utilisé wlp6s0 comme nom de votre interface sans fil. Ce nom peut être différent chez vous. Vous pouvez le découvrir avec la commande ip l.

Le service créé wpa_supplicant@wlp6s0 sera lancé lors de 'l'activation' de l'interface sans fil, mais il devra rechercher les paramètres SSID et le mot de passe du point d'accès dans le fichier /etc/wpa_supplicant/wpa_supplicant-wlp6s0. Vous devez donc le créer à l'aide de l'outil wpa_passphrase.

Pour cela, exécutez la commande :

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

où SSID — c'est le nom de votre point d'accès, password — le mot de passe, et wlp6s0 — c'est le nom de votre interface sans fil.

Initiez l'interface virtuelle pour tun2socks

Créez un fichier pour l'initialisation de la nouvelle interface virtuelle dans le système/etc/systemd/network/25-tun2socks.netdev

[NetDev]
Name=tun2socks
Kind=tun

Nom — c'est le nom que systemd-networkd attribuera à la future interface virtuelle lors de son initialisation.
Kind — c'est le type d'interface virtuelle. À partir du nom du service tun2socks, vous pouvez deviner qu'il utilise une interface de type tun.
netdev — c'est une extension de fichiers qui systemd-networkd est utilisée pour initialiser des interfaces réseau virtuelles. L'adresse et d'autres paramètres réseau pour ces interfaces sont spécifiés dans .network-les fichiers.

Créez un tel fichier /etc/systemd/network/25-tun2socks.network avec le contenu suivant :

[Match]
Name=tun2socks

[Network]
Address=172.16.1.2/24
Gateway=172.16.1.1

Nom — le nom de l'interface virtuelle que vous avez spécifié dans netdev-le fichier.
Address — l'adresse IP qui sera attribuée à l'interface virtuelle. Elle doit être dans le même réseau que l'adresse que vous avez spécifiée dans le service tun2socks
Gateway — l'adresse IP du « routeur » tun2socks, que vous avez spécifiée lors de la création du service systemd.

Ainsi, l'interface tun2socks a l'adresse 172.16.1.2, et le service tun2socks — 172.16.1.1, c'est-à-dire qu'il sert de passerelle pour toutes les connexions via l'interface virtuelle.

Configurez le point d'accès virtuel

Installez les dépendances :

apt install util-linux procps hostapd iw haveged

Clonez le dépôt create_ap sur votre machine :

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

Accédez au dossier du dépôt sur votre machine :

cd create_ap

Installez dans le système :

make install

Un fichier de configuration apparaîtra dans votre système /etc/create_ap.conf. Voici les principales options à modifier :

GATEWAY=10.0.0.1 — il est préférable de le faire dans un sous-réseau réservé.
NO_DNS=1 — désactivez-le, car ce paramètre sera géré par l'interface virtuelle systemd-networkd.
NO_DNSMASQ=1 — éteignez pour la même raison.
WIFI_IFACE=wlp6s0 — l'interface sans fil de l'ordinateur portable.
INTERNET_IFACE=tun2socks — l'interface virtuelle créée pour tun2socks.
SSID=hostapd — le nom du point d'accès virtuel.
PASSPHRASE=12345678 — le mot de passe.

N'oubliez pas d'activer le service :

systemctl enable create_ap

Activez le serveur DHCP dans systemd-networkd

Le service create_ap initialise dans le système l'interface virtuelle ap0. En théorie, dnsmasq est actif sur cette interface, mais pourquoi installer des services supplémentaires si systemd-networkd contient un serveur DHCP intégré ?

Pour l’activer, définissez les paramètres du réseau pour le point virtuel. Pour cela, créez un fichier /etc/systemd/network/25-ap0.network avec le contenu suivant :

[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

Après que le service create_ap a initialisé l'interface virtuelle ap0, systemd-networkd lui attribuera automatiquement une adresse IP et activera le serveur DHCP.

Les lignes EmitDNS=yes et DNS=10.0.0.1 transmettent les paramètres du serveur DNS aux appareils connectés au point d'accès.

Si vous ne prévoyez pas d'utiliser un serveur DNS local — dans mon cas, c'est dnscrypt-proxy — vous pouvez définir DNS=10.0.0.1 dans DNS=192.168.1.1, où 192.168.1.1 — l'adresse de votre passerelle d'origine. Les requêtes DNS de votre hôte et du réseau local seront alors envoyées en clair via les serveurs de votre fournisseur.

EmitNTP=yes et NTP=192.168.1.1 transmettent les paramètres NTP.

Il en va de même pour la ligne NTP=10.0.0.1.

Installez et configurez le serveur NTP

Installez dans le système :

apt install ntp

Modifiez le fichier de configuration /etc/ntp.conf. Commentez les adresses des pools standard :

#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

Ajoutez les adresses des serveurs publics, comme ceux de Google Public NTP :

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

Faites en sorte que le serveur soit accessible aux clients de votre réseau :

restrict 10.0.0.0 mask 255.255.255.0

Activez la diffusion dans votre réseau :

broadcast 10.0.0.255

Enfin, ajoutez les adresses de ces serveurs dans la table de routage statique. Pour cela, ouvrez le fichier de configuration de l'interface sans fil /etc/systemd/network/25-wlp6s0.network et ajoutez à la fin de la section 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

Vous pouvez trouver les adresses de vos serveurs NTP en utilisant l’utilitaire host comme suit :

host time1.google.com

Installez dnscrypt-proxy, enlever les publicités et masquer le trafic DNS de votre fournisseur

apt install dnscrypt-proxy

Pour servir les requêtes DNS de l’hôte et du réseau local, modifiez le socket /lib/systemd/system/dnscrypt-proxy.socket. Changez les lignes suivantes :

ListenStream=0.0.0.0:53
ListenDatagram=0.0.0.0:53

Redémarrez systemd:

systemctl daemon-reload

Modifiez le fichier de configuration /etc/dnscrypt-proxy/dnscrypt-proxy.toml:

server_names = ['adguard-dns']

Pour diriger les connexions dnscrypt-proxy via tun2socks, ajoutez ci-dessous :

force_tcp = true

Modifiez le fichier de configuration /etc/resolv.conf, qui informe le serveur DNS de l'hôte.

nameserver 127.0.0.1
nameserver 192.168.1.1

La première ligne inclut l'utilisation de dnscrypt-proxy, la deuxième utilise la passerelle d'origine, au cas où le serveur dnscrypt-proxy serait indisponible.

C'est fait !

Redémarrez ou arrêtez les services réseau en activité :

systemctl stop networking NetworkManager NetworkManager-wait-online

Et redémarrez tous les nécessaires :

systemctl restart systemd-networkd tun2socks create_ap dnscrypt-proxy ntp

Après le redémarrage ou le redémarrage, vous aurez un deuxième point d'accès qui routage l'hôte et les appareils du réseau local vers SOCKS.

Voici à quoi ressemble la sortie ip a d'un ordinateur portable standard :

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 fin de compte

Le fournisseur ne voit qu'une connexion chiffrée à votre serveur SOCKS, ce qui signifie qu'il ne voit rien.
Et pourtant, il voit vos requêtes NTP, pour éviter cela, supprimez les routes statiques pour les serveurs NTP. Cependant, rien ne garantit que votre serveur SOCKS prend en charge le protocole NTP.

Patch observé sur Debian 10

Si vous essayez de redémarrer le service réseau depuis la console, il échouera avec une erreur. Cela est dû au fait qu'une partie d'elle sous forme d'interface virtuelle est liée au service tun2socks, ce qui signifie qu'elle est utilisée. Pour redémarrer le service réseau, vous devez d'abord arrêter le service tun2socks. Mais je pense que si vous avez lu jusqu'à la fin, ce n'est définitivement pas un problème pour vous !

Liens

Source : habr.com