ProHoster > Blog > administration > Construire un routeur dans SOCKS sur un ordinateur portable avec Debian 10

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'avais déjà publié deux articles dans lesquels je décrivais le processus de création d'un routeur dans SOCKS à partir d'un ordinateur portable très ordinaire avec Debian.

Cependant, depuis que la version stable de Debian a été mise à jour vers Buster, un nombre suffisant de personnes m'ont contacté en privé pour demander de l'aide pour l'installation, 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 sont décrites ne révèlent pas pleinement toutes les subtilités de la configuration de Linux pour le routage dans SOCKS. De plus, ils sont é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. 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 modifications ci-dessus, les services suivants ont été ajoutés à ma configuration : hébergeur - service de virtualisation des points d'accès, ntp pour synchroniser l'heure des clients du réseau local, proxy-dnscrypt pour chiffrer les connexions via DNS et désactiver la publicité sur les clients du réseau local, et aussi, comme je l'ai mentionné plus tôt, systemd-networkd pour configurer les interfaces réseau.

Voici un schéma fonctionnel simple de la structure interne d’un tel routeur.

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

Alors laissez-moi vous rappeler quels sont les objectifs de cette série d’articles :

  1. Acheminez toutes les connexions du système d'exploitation vers SOCKS, ainsi que les connexions de tous les appareils sur le même réseau que l'ordinateur portable.
  2. L'ordinateur portable dans mon cas doit rester totalement mobile. Autrement dit, pour donner la possibilité d'utiliser l'environnement de bureau et de ne pas être lié à un emplacement physique.
  3. Le dernier point implique la connexion et le routage uniquement via l'interface sans fil intégrée.
  4. Et bien sûr, la création d'un guide complet, ainsi qu'une analyse des technologies pertinentes au meilleur de mes modestes connaissances.

Ce qui sera couvert dans cet article :

  1. jet — télécharger les référentiels de projets tun2socksrequis pour acheminer le trafic TCP vers SOCKS, et créer_ap — un script pour automatiser la configuration d'un point d'accès virtuel à l'aide hébergeur.
  2. tun2socks - créez et installez le service systemd sur le système.
  3. systemd-networkd — configurez les interfaces sans fil et virtuelles, les tables de routage statiques et la redirection des paquets.
  4. créer_ap — installez le service systemd sur le système, configurez et lancez un point d'accès virtuel.

Étapes facultatives :

  • ntp — installer et configurer un serveur pour synchroniser l'heure sur les clients de points d'accès virtuels.
  • proxy-dnscrypt — nous chiffrerons les requêtes DNS, les acheminerons vers SOCKS et désactiverons les domaines publicitaires pour le réseau local.

Pourquoi tout ça?

C'est l'un des moyens de sécuriser les connexions TCP sur un réseau local. Le principal avantage est que toutes les connexions sont établies dans SOCKS, à moins qu'une route statique ne soit construite pour elles via la passerelle d'origine. Cela signifie que vous n'avez pas besoin de spécifier les paramètres du serveur SOCKS pour les programmes individuels ou les clients du réseau local - ils vont tous à SOCKS par défaut, puisqu'il s'agit de la passerelle par défaut jusqu'à ce que nous indiquions le contraire.

Essentiellement, nous ajoutons un deuxième routeur de cryptage en tant qu'ordinateur portable devant le routeur d'origine et utilisons la connexion Internet du routeur d'origine pour les requêtes SOCKS déjà cryptées de l'ordinateur portable, qui à son tour achemine et crypte les requêtes des clients LAN.

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

En conséquence, tous les appareils sont connectés au point d’accès virtuel de l’ordinateur portable.

Installez tun2socks sur le système

Tant que votre machine dispose d'Internet, 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

Un dossier apparaîtra sur votre système badvpn. Créer un dossier séparé pour la build

mkdir badvpn-build

Allez-y

cd badvpn-build

Collecter tun2socks

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

Installer sur le système

make install
  • Paramètre -DBUILD_NOTHING_BY_DEFAULT=1 désactive la construction de tous les composants du référentiel badvpn.
  • -DBUILD_TUN2SOCKS=1 inclut un composant dans l'assemblage tun2socks.
  • make install — installera le binaire tun2socks sur votre système à /usr/local/bin/badvpn-tun2socks.

Installez le service tun2socks dans systemd

Créer 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 - prend le nom de l'interface virtuelle que l'on initialise avec systemd-networkd.
  • --netif-ipaddr — l'adresse réseau du « routeur » tun2socks auquel l'interface virtuelle est connectée. Il vaut mieux le séparer sous-réseau réservé.
  • --socks-server-addr - accepte la prise (адрес:порт serveurs SOCKS).

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

Ensuite, enregistrez le service

systemctl daemon-reload

Et allume-le

systemctl enable tun2socks

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

Passer à systemd-networkd

Allumez systemd-networkd:

systemctl enable systemd-networkd

Désactivez les services réseau actuels.

systemctl disable networking NetworkManager NetworkManager-wait-online
  • NetworkManager-attendre-en ligne est un service qui attend une connexion réseau fonctionnelle avant que systemd continue de démarrer d'autres services qui dépendent de la présence d'un réseau. Nous le désactivons lorsque nous passons à l'analogue systemd-networkd.

Activons-le tout de suite :

systemctl enable systemd-networkd-wait-online

Configurer 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 - une directive qui permet la redirection des paquets sur une interface réseau.
  • Adresse est responsable de l’attribution d’une adresse IP à l’interface sans fil. On le précise statiquement car avec la directive équivalente DHCP=yes, systemd-networkd crée une passerelle par défaut sur le système. Ensuite, tout le trafic passera par la passerelle d'origine, et non par la future interface virtuelle sur un sous-réseau différent. 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 alors créer une route statique pour celui-ci. Pour ce faire, ajoutez une section Route à la fin du fichier de configuration de l'interface sans fil que vous avez créé avec le contenu suivant :

[Route]
Gateway=192.168.1.1
Destination=0.0.0.0
  • Gateway — il s'agit de la passerelle par défaut ou de l'adresse 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é. En essayant de "monter" l'interface sans fil, systemd-networkd démarre le service wpa_supplicant@имяOù nom est le nom de l'interface sans fil. Si vous n'avez pas utilisé systemd-networkd avant ce point, alors ce service est probablement absent sur votre système.

Créez-le donc avec la commande :

systemctl enable wpa_supplicant@wlp6s0

J'ai utilisé wlp6s0 comme nom de son interface sans fil. Votre nom peut être différent. Vous pouvez le reconnaître avec la commande ip l.

Maintenant le service créé wpa_supplicant@wlp6s0 sera lancé lorsque l'interface sans fil est « relevée », cependant, elle recherchera à son tour les paramètres SSID et de 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 — 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.
  • Genre est un type d'interface virtuelle. D'après le nom du service tun2socks, vous pouvez deviner qu'il utilise une interface comme tun.
  • Netdev est l'extension des fichiers qui systemd-networkd Utilisé pour initialiser les interfaces réseau virtuelles. L'adresse et les autres paramètres réseau de ces interfaces sont spécifiés dans .réseau-des dossiers.

Créez un fichier comme celui-ci /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
  • Name — le nom de l'interface virtuelle que vous avez spécifié dans Netdev-déposer.
  • Address — Adresse IP qui sera attribuée à l'interface virtuelle. Doit être sur le même réseau que l'adresse que vous avez spécifiée dans le service tun2socks
  • Gateway — Adresse IP du « routeur » tun2socks, que vous avez spécifié lors de la création du service systemd.

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

Configurer un point d'accès virtuel

Installer les dépendances :

apt install util-linux procps hostapd iw haveged

Téléchargez le référentiel créer_ap à votre voiture :

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

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

cd create_ap

Installer sur le système :

make install

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

  • GATEWAY=10.0.0.1 - il est préférable d'en faire un sous-réseau réservé distinct.
  • NO_DNS=1 - désactiver, puisque ce paramètre sera géré par l'interface virtuelle systemd-networkd.
  • NO_DNSMASQ=1 - éteignez-le pour la même raison.
  • WIFI_IFACE=wlp6s0 — interface sans fil pour ordinateur portable.
  • INTERNET_IFACE=tun2socks - une 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

Service create_ap initialise une interface virtuelle dans le système ap0. En théorie, 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, nous définirons les paramètres réseau du point virtuel. Pour ce faire, 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

Une fois que le service create_ap initialise l'interface virtuelle ap0, systemd-networkd lui attribuera automatiquement une adresse IP et activera le serveur DHCP.

Cordes EmitDNS=yes и DNS=10.0.0.1 transmettre 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 installer DNS=10.0.0.1 в DNS=192.168.1.1Où 192.168.1.1 — l'adresse de votre passerelle d'origine. Ensuite, les requêtes DNS pour votre hôte et votre réseau local seront non cryptées via les serveurs du fournisseur.

EmitNTP=yes и NTP=192.168.1.1 transférer les paramètres NTP.

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

Installer et configurer le serveur NTP

Installer sur le système :

apt install ntp

Modifier la configuration /etc/ntp.conf. Commentez les adresses des pools standards :

#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 des adresses de serveur publiques, 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

Donnez accès au serveur aux clients de votre réseau :

restrict 10.0.0.0 mask 255.255.255.0

Activez la diffusion sur votre 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 de l'interface sans fil /etc/systemd/network/25-wlp6s0.network et ajouter à 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 connaître les adresses de vos serveurs NTP à l'aide de l'utilitaire host comme suit:

host time1.google.com

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

apt install dnscrypt-proxy

Pour répondre aux 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

ерезапустите systemd:

systemctl daemon-reload

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

server_names = ['adguard-dns']

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

force_tcp = true

Modifier la 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 permet d'utiliser dnscrypt-proxy, la deuxième ligne utilise la passerelle d'origine au cas où le serveur dnscrypt-proxy serait indisponible.

Fait!

Redémarrez ou arrêtez l'exécution des services réseau :

systemctl stop networking NetworkManager NetworkManager-wait-online

Et redémarrez tout le nécessaire :

systemctl restart systemd-networkd tun2socks create_ap dnscrypt-proxy ntp

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

Voici à quoi ressemble le résultat ip a ordinateur portable classique :

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

En conséquence,

  1. Le fournisseur ne voit que la connexion cryptée à votre serveur SOCKS, ce qui signifie qu'il ne voit rien.
  2. Et pourtant, il voit vos requêtes NTP, pour éviter cela, supprimez les routes statiques pour les serveurs NTP. Il n'est cependant pas certain que votre serveur SOCKS autorise le protocole NTP.

Béquille repérée sur Debain 10

Si vous essayez de redémarrer le service réseau depuis la console, cela échouera avec une erreur. Cela est dû au fait qu'une partie sous la forme d'une 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 lisez jusqu’au bout, ce n’est certainement pas un problème pour vous !

références

  1. Routage statique sous Linux - IBM
  2. systemd-networkd.service - Freedesktop.org
  3. Tun2socks · Wiki ambrop72/badvpn · GitHub
  4. oblique/create_ap : ce script crée un point d'accès WiFi NATé ou ponté.
  5. dnscrypt-proxy 2 — Un proxy DNS flexible, avec prise en charge des protocoles DNS cryptés.

Source: habr.com