👨🏿‍⚖️ 🏺 👩🏾‍🤝‍👨🏽 Construire un routeur dans SOCKS sur un ordinateur portable avec Debian 10 🧝 ◻️ 🏂🏽

Pendant un an (ou deux), j'ai reporté la publication de cet article pour la raison principale - j'ai déjà publié deux articles dans lesquels j'ai décrit le processus de création d'un routeur dans SOCKS à partir d'un ordinateur portable ordinaire avec Debian.

Cependant, depuis lors, la version stable de Debian a été mise à jour vers Buster, un nombre suffisant de personnes m'ont envoyé une demande personnelle pour aider à la configuration, ce qui signifie que mes articles précédents ne sont pas exhaustifs. Eh bien, j'ai moi-même deviné que les méthodes qui y étaient décrites ne révélaient pas complètement toutes les subtilités de la configuration de Linux pour le routage dans SOSKS. De plus, ils ont été écrits pour Debian Stretch, et après la mise à niveau vers Buster, dans le système d'initialisation systemd, j'ai remarqué de petits changements dans l'interaction des services. Oui, et dans les articles eux-mêmes, je n'ai pas utilisé systemd-networkd, bien qu'il soit mieux adapté aux configurations réseau complexes.

En plus des changements ci-dessus, des services comme hostapd ont été ajoutés à ma configuration - un service pour la virtualisation des points d'accès, ntp pour synchroniser l'heure des clients du réseau local, dnscrypt-proxy pour crypter les connexions DNS et désactiver la publicité sur les clients du réseau local, ainsi que, comme je l'ai mentionné auparavant, systemd-networkd pour configurer les interfaces réseau.

Voici le schéma de principe le plus simple de la structure interne d'un tel routeur.

Je vous rappelle donc quels sont les objectifs du cycle de ces articles:

Acheminez toutes les connexions du système d'exploitation vers SOCKS, ainsi que les connexions de tous les appareils qui se trouvent sur le même réseau que l'ordinateur portable.
L'ordinateur portable dans mon cas doit rester entièrement mobile. Autrement dit, pour donner la possibilité d'utiliser l'environnement de bureau et de ne pas être lié à un emplacement physique.
Le dernier point implique la connexion et le routage uniquement via l'interface sans fil intégrée.
Eh bien, bien sûr, la création d'un guide exhaustif, ainsi que l'analyse des technologies appropriées au mieux de mes modestes connaissances.

Ce qui sera considéré dans cet article:

git - télécharger les tun2socks projettent des référentiels nécessaires pour acheminer le trafic TCP SOCKS et create_ap - un script pour automatiser la configuration d'un point d'accès virtuel à l' aide hostapd .
tun2socks - compile et installe le service systemd sur le système .
systemd-networkd - configurez les interfaces sans fil et virtuelles, les tables de routage statiques et le transfert de paquets.
create_ap - installe le service systemd sur le système, configure et lance le point d'accès virtuel.

Étapes facultatives:

ntp - installe et configure le serveur pour synchroniser l'heure sur les clients du point d'accès virtuel.
dnscrypt-proxy - crypter les requêtes DNS, les acheminer vers SOCKS et désactiver les domaines publicitaires pour le réseau local.

Pourquoi tout ça?

C'est une façon de sécuriser les connexions TCP sur un réseau local. Le principal avantage est que toutes les connexions vont à SOCKS si une route statique via la passerelle d'origine n'est pas créée pour eux. Cela signifie qu'il n'est pas nécessaire de prescrire les paramètres du serveur SOCKS à des programmes individuels ou à des clients sur le réseau local - ils vont tous à SOCKS par défaut, car c'est la passerelle par défaut jusqu'à ce que nous spécifions le contraire.

En fait, nous ajoutons le deuxième routeur de chiffrement en tant qu'ordinateur portable devant le routeur d'origine et utilisons la connexion Internet du routeur d'origine pour les demandes SOCKS déjà chiffrées de l'ordinateur portable, qui, à leur tour, achemine et chiffre les demandes des clients du réseau local.

Du point de vue du fournisseur, nous sommes constamment connectés au même serveur avec un trafic crypté.

Par conséquent, tous les appareils se connectent au point d'accès virtuel d'un ordinateur portable.

Avant de commencer

Presque toutes les configurations sont disponibles dans le référentiel .

Installez tun2socks dans le système

Tant que vous avez Internet sur votre machine, téléchargez tous les outils nécessaires.

apt update

apt install git make cmake

Téléchargez le package badvpn

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

Le dossier badvpn apparaîtra sur votre système . Créer un dossier de build séparé

mkdir badvpn-build

Aller vers elle

cd badvpn-build

Construire des tun2socks

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

Installer sur le système

make install

Le paramètre -DBUILD_NOTHING_BY_DEFAULT = 1 désactive l'assemblage de tous les composants du référentiel badvpn .
DBUILD_TUN2SOCKS = 1 inclut les composants tun2socks dans l'assemblage .
make install - installe le binaire tun2socks sur votre système à / usr / local / bin / badvpn-tun2socks.

Installer le service tun2socks dans systemd

Créez le 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 - adresse réseau du tuner «routeur» auquel l'interface virtuelle est connectée. Il est préférable de créer un sous-réseau réservé distinct .
--socks-server-addr - accepte un 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 allume

systemctl enable tun2socks

Avant de démarrer le service, nous lui fournirons une interface réseau virtuelle.

Accédez à systemd-networkd

Activez systemd-networkd :

systemctl enable systemd-networkd

Désactivez les services réseau actuels.

systemctl disable networking NetworkManager NetworkManager-wait-online

NetworkManager-wait-online est un service qui attend une connexion réseau fonctionnelle avant que systemd ne continue à démarrer d'autres services qui dépendent du réseau. Nous le désactivons lorsque nous passons à l'analogue systemd-networkd .

Allumons-le tout de suite:

systemctl enable systemd-networkd-wait-online

Configurer une 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
IPMasquerade=yes

Le nom est le nom de votre interface sans fil. Identifiez-le avec la commande ip a .
IPMasquerade est une directive qui inclut le masquage et le transfert de paquets sur une interface réseau.
L'adresse est responsable de l'attribution d'une adresse IP à l'interface sans fil. Nous le spécifions statiquement car avec la directive équivalente DHCP = yes , systemd-networkd crée une passerelle par défaut dans le système. Ensuite, tout le trafic passera par la passerelle d'origine, et non par la future interface virtuelle dans un excellent sous-réseau. Vous pouvez vérifier la passerelle par défaut actuelle avec la commande
```
ip r
```

Créer une route statique pour le serveur SOCKS distant

Si votre serveur SOCKS n'est pas local, mais distant, vous devez lui créer un itinéraire statique. Pour ce faire, ajoutez la section Route à la fin du fichier de configuration sans fil que vous avez créé avec le contenu suivant:

[Route]
Gateway=192.168.1.1
Destination=0.0.0.0

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

Configurer wpa_supplicant pour systemd-networkd

systemd-networkd utilise wpa_supplicant pour se connecter à un point d'accès sécurisé. Lorsque vous essayez de "relancer" l'interface sans fil, systemd-networkd démarre le service wpa_supplicant @ name , où nom est le nom de l'interface sans fil. Si vous n'avez pas utilisé systemd-networkd avant ce point, ce service n'est certainement pas disponible sur votre système.

Par conséquent, créez-le avec la commande:

systemctl enable wpa_supplicant@wlp6s0

J'ai utilisé wlp6s0 comme nom de mon interface sans fil. Votre nom peut être différent. Vous pouvez le découvrir par son équipe

ip l

.

Maintenant, le service créé wpa_supplicant @ wlp6s0 démarrera lorsque l'interface sans fil sera «levée», cependant, à son tour, il recherchera les paramètres SSID et mot de passe du point d'accès dans le fichier / etc / wpa_supplicant / wpa_supplicant-wlp6s0 . Par conséquent, vous devez le créer à l'aide de l'utilitaire wpa_passphrase .

Pour ce faire, exécutez la commande:

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

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

Initialiser l'interface virtuelle pour tun2socks

Créez un fichier pour initialiser une nouvelle interface virtuelle dans le système /etc/systemd/network/25-tun2socks.netdev

[NetDev]
Name=tun2socks
Kind=tun

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

Créez un 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ée dans le fichier netdev .
Adresse - Adresse IP à attribuer à l'interface virtuelle. Doit être sur le même réseau que l'adresse que vous avez spécifiée dans tun2socks
Passerelle - l'adresse IP du «routeur» tun2socks que vous avez spécifié lors de la création du service systemd .

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

Configurer un point d'accès virtuel

Installez les dépendances:

apt install util-linux procps hostapd iw haveged

Téléchargez le référentiel create_ap sur votre machine:

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

Accédez au dossier du référentiel sur votre ordinateur:

cd create_ap

Installez dans le système:

make install

La configuration /etc/create_ap.conf apparaîtra sur votre système . Voici les principales options d'édition:

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

N'oubliez pas d'activer le service:

systemctl enable create_ap

Activer le serveur DHCP dans systemd-networkd

Le service create_ap initialise l'interface virtuelle ap0 sur le système . Théoriquement , dnsmasq se bloque 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 réseau du point virtuel. Pour ce faire, créez le 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

Une fois que le service sreate_ap a initialisé l'interface virtuelle Ap0 , systemd-NetworkD attribue automatiquement une adresse IP et active 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, il s'agit de dnscrypt-proxy - vous pouvez définir DNS = 10.0.0.1 sur DNS = 192.168.1.1 , où 192.168.1.1 est l'adresse de votre passerelle d'origine. Ensuite, les requêtes DNS de votre hôte et de votre réseau local ne seront pas cryptées via les serveurs du fournisseur.

EmitNTP = ouiet NTP = 192.168.1.1 transmettent les paramètres NTP.

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

Installer et configurer le serveur NTP

Installez dans le système:

apt install ntp

Modifiez la 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, par exemple, Google Public NTP:

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

Accordez l'accès au serveur aux clients de votre réseau:

restrict 10.0.0.0 mask 255.255.255.0

Transformez la diffusion en réseau:

broadcast 10.0.0.255

Enfin, ajoutez les adresses de ces serveurs à la table de routage statique. Pour ce faire, ouvrez le fichier de configuration sans fil /etc/systemd/network/25-wlp6s0.network et ajoutez la section Route à la fin .

[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 hôte comme suit:

host time1.google.com

Installez dnscrypt-proxy , supprimez les publicités et masquez le trafic DNS du 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 . Modifiez les lignes suivantes:

ListenStream=0.0.0.0:53
ListenDatagram=0.0.0.0:53

Redémarrer systemd:

systemctl daemon-reload

Modifiez la configuration /etc/dnscrypt-proxy/dnscrypt-proxy.toml :

server_names = ['adguard-dns']

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

force_tcp = true

Modifiez la configuration /etc/resolv.conf qui indique le serveur DNS à l'hôte.

nameserver 127.0.0.1
nameserver 192.168.1.1

La première ligne inclut l'utilisation de dnscrypt-proxy , la seconde - utilise la passerelle d'origine, au cas où le serveur dnscrypt-proxy ne serait pas disponible.

Terminé!

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

systemctl stop networking NetworkManager NetworkManager-wait-online

Et redémarrez tous ceux nécessaires:

systemctl restart systemd-networkd tun2socks create_ap dnscrypt-proxy ntp

Après le redémarrage ou le redémarrage, vous disposerez d'un deuxième point d'accès qui achemine l'hôte et les périphériques LAN vers SOCKS.

Voici à quoi ressemble la sortie.

ip a

ordinateur portable ordinaire:

1: lo: <LOOPBACK,UP,LOWER_UP> 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: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> 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: <NO-CARRIER,BROADCAST,MULTICAST,UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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

Finalement

Le fournisseur ne voit que la connexion crypté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, ce n'est pas un fait que votre serveur SOCKS autorise NTP.

Crutch vu sur Debain 10

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

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