🥇Costruire un router SOCKS su un laptop con Debian 10

Per un anno (o due) ho rimandato la pubblicazione di questo articolo per una ragione principale: avevo già pubblicato due articoli in cui descrivevo il processo di creazione di un router SOCKS da un normale laptop con Debian.

Tuttavia, da allora la versione stabile di Debian è stata aggiornata a Buster, e molte persone mi hanno contattato in privato chiedendo aiuto nella configurazione, il che significa che i miei articoli precedenti non sono esaustivi. D'altra parte, sapevo già che i metodi descritti non coprivano tutte le sfumature della configurazione di Linux per la routing in SOCKS. Inoltre, erano scritti per Debian Stretch, e dopo l'aggiornamento a Buster, ho notato piccoli cambiamenti nell'interazione dei servizi nel sistema di init systemd. E nelle mie articoli non ho utilizzato systemd-networkd, anche se è la più adatta per configurazioni di rete complesse.

Oltre ai cambiamenti sopra citati, la mia configurazione ha incluso servizi come hostapd — il servizio per virtualizzare un punto di accesso, ntp per sincronizzare il tempo dei client nella rete locale, dnscrypt-proxy per la crittografia delle connessioni tramite il protocollo DNS e per disabilitare la pubblicità sui client della rete locale, come ho menzionato in precedenza, systemd-networkd per la configurazione delle interfacce di rete.

Ecco uno schema semplice del funzionamento interno di un router del genere.

Quindi, vorrei ricordare quali obiettivi si propone di raggiungere questo ciclo di articoli:

Instradare tutte le connessioni del sistema operativo SOCKS, così come le connessioni di tutti i dispositivi che si trovano nella stessa rete del laptop.
Il laptop, nel mio caso, deve rimanere completamente mobile. In altre parole, deve consentire l'uso dell'ambiente desktop senza essere vincolato a una posizione fisica.
L'ultimo punto implica la connessione e l'instradamento solo attraverso l'interfaccia wireless integrata.
E naturalmente, creare una guida completa, oltre a esaminare le tecnologie pertinenti per quanto riguarda le mie modeste conoscenze.

Cosa verrà esaminato in questo articolo:

git — scaricheremo i repository dei progetti tun2socks, necessario per instradare il traffico TCP in SOCKS, e create_ap — uno script per automatizzare la configurazione di un punto di accesso virtuale utilizzando hostapd.
tun2socks — costruiremo e installeremo il servizio systemd nel sistema.
systemd-networkd — configureremo interfacce wireless e virtuali, tabelle di routing statico e inoltro dei pacchetti.
create_ap — installeremo il servizio systemd nel sistema, configureremo e avvieremo il punto di accesso virtuale.

Passi facoltativi:

ntp — installeremo e configureremo un server per la sincronizzazione dell'ora sui client del punto di accesso virtuale.
dnscrypt-proxy — crittografiamo le richieste DNS, le instraderemo in SOCKS e disattiviamo i domini pubblicitari per la rete locale.

Perché tutto questo?

È uno dei modi per organizzare la protezione delle connessioni TCP nella rete locale. Il principale vantaggio è che tutte le connessioni vanno in SOCKS, a meno che non sia stato creato un routing statico attraverso il gateway originale. Questo significa che non è necessario configurare le impostazioni del server SOCKS né per i programmi singoli né per i client nella rete locale: vanno tutti in SOCKS per impostazione predefinita, poiché è il gateway predefinito, finché non indichiamo il contrario.

In sostanza, aggiungiamo un secondo router crittografico come un laptop davanti al router originale e utilizziamo la connessione Internet del router originale per le richieste SOCKS già crittografate dal laptop, che a sua volta instrada e crittografa le richieste dei clienti nella rete locale.

Dal punto di vista del provider, siamo costantemente connessi a un server con traffico crittografato.

Di conseguenza, tutti i dispositivi si connettono al punto di accesso virtuale del laptop.

Installare tun2socks nel sistema

Finché il tuo computer ha accesso a Internet, scarica tutti gli strumenti necessari.

apt update

apt install git make cmake

Scarica il pacchetto badvpn

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

Nella tua sistema apparirà una cartella badvpn. Crea una cartella separata per la compilazione

mkdir badvpn-build

Entraci dentro

cd badvpn-build

Compila tun2socks

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

Installa nel sistema

make install

Caratteristica -DBUILD_NOTHING_BY_DEFAULT=1 disabilita la compilazione di tutti i componenti del repository badvpn.
—DBUILD_TUN2SOCKS=1 attiva la compilazione del componente tun2socks.
make install installerà il binario tun2socks nel tuo sistema all'indirizzo /usr/local/bin/badvpn-tun2socks.

Installa il servizio tun2socks in systemd

Crea un file /etc/systemd/system/tun2socks.service con il seguente contenuto:

[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 — specifichiamo il nome dell'interfaccia virtuale che inizializziamo con systemd-networkd.
--netif-ipaddr — l'indirizzo IP del «router» tun2socks a cui si connette l'interfaccia virtuale. È meglio utilizzare una sottorete riservata.
--socks-server-addr — prende il socket (indirizzo:porta del server SOCKS).

Se il tuo server SOCKS richiede autenticazione, puoi specificare i parametri --username e --password.

Dopo registriamo il servizio

systemctl daemon-reload

E abilitiamo

systemctl enable tun2socks

Prima di avviare il servizio, assicuriamoci di avere un'interfaccia di rete virtuale.

Passiamo a systemd-networkd

Attiviamo systemd-networkd:

systemctl enable systemd-networkd

Disabilitiamo i servizi di rete attuali.

systemctl disable networking NetworkManager NetworkManager-wait-online

NetworkManager-wait-online — è un servizio che attende che ci sia una connessione di rete funzionante prima che systemd continui a avviare altri servizi che dipendono dalla rete. Lo disabilitiamo, poiché passeremo all'equivalente di systemd-networkd.

Attiviamolo subito:

systemctl enable systemd-networkd-wait-online

Configura l'interfaccia di rete wireless

Crea un file di configurazione systemd-networkd per l'interfaccia di rete wireless /etc/systemd/network/25-wlp6s0.network.

[Match]
Name=wlp6s0

[Network]
Address=192.168.1.2/24
IPForward=yes

Name — è il nome della tua interfaccia wireless. Identificala con il comando ip a.
IPForward — direttiva che abilita il forwarding dei pacchetti sull'interfaccia di rete.
Indirizzo assegna un indirizzo IP all'interfaccia wireless. Lo specifichiamo in modo statico perché con la direttiva equivalente DHCP=yes, systemd-networkd crea un gateway predefinito nel sistema. Allora, tutto il traffico passerà attraverso il gateway originale, e non attraverso il futuro interfaccia virtuale in una rete diversa. Puoi controllare il gateway predefinito attuale con il comando ip r

Crea una rotta statica per il server SOCKS remoto

Se il tuo server SOCKS non è locale, ma remoto, devi creare una rotta statica per esso. A questo scopo, aggiungi la sezione Route alla fine del file di configurazione dell'interfaccia wireless che hai creato con il seguente contenuto:

[Route]
Gateway=192.168.1.1
Destination=0.0.0.0

Gateway — è il gateway predefinito o l'indirizzo del tuo punto di accesso originale.
Destination — l'indirizzo del server SOCKS.

Configura wpa_supplicant per systemd-networkd

systemd-networkd utilizza wpa_supplicant per connettersi a un punto di accesso protetto. Quando tenta di 'attivare' un'interfaccia wireless, systemd-networkd avvia il servizio wpa_supplicant@nome, dove nome è il nome dell'interfaccia wireless. Se non hai utilizzato systemd-networkd fino a questo momento, è probabile che questo servizio non sia presente nel tuo sistema.

Perciò, creala con il comando:

systemctl enable wpa_supplicant@wlp6s0

Ho usato wlp6s0 come nome della mia interfaccia wireless. Questo nome potrebbe variare per te. Puoi scoprirlo con il comando ip l.

Ora il servizio creato wpa_supplicant@wlp6s0 si avvierà quando verrà 'attivata' l'interfaccia wireless; tuttavia, cercherà le impostazioni SSID e la password del punto di accesso nel file /etc/wpa_supplicant/wpa_supplicant-wlp6s0. Pertanto, è necessario crearlo utilizzando l'utilità wpa_passphrase.

Per fare ciò, esegui il comando:

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

dove SSID è il nome del tuo punto di accesso, password è la password, e wlp6s0 è il nome della tua interfaccia wireless.

Inizializza l'interfaccia virtuale per tun2socks

Crea un file per inizializzare la nuova interfaccia virtuale nel sistema/etc/systemd/network/25-tun2socks.netdev

[NetDev]
Name=tun2socks
Kind=tun

Name — è il nome che systemd-networkd assegnerà al futuro'interfaccia virtuale durante la sua inizializzazione.
Tipo — è il tipo di interfaccia virtuale. Dato il nome del servizio tun2socks, puoi dedurre che utilizza un'interfaccia di tipo tun.
netdev — è l'estensione dei file che systemd-networkd utilizza per inizializzare le interfacce di rete virtuali. L'indirizzo e altre impostazioni di rete per queste interfacce sono indicati in .network-file.

Crea un file del genere /etc/systemd/network/25-tun2socks.network con il seguente contenuto:

[Match]
Name=tun2socks

[Network]
Address=172.16.1.2/24
Gateway=172.16.1.1

Name — il nome dell'interfaccia virtuale che hai specificato nel netdev-file.
Indirizzo — l'indirizzo IP che sarà assegnato all'interfaccia virtuale. Deve essere nella stessa rete dell'indirizzo specificato nel servizio tun2socks
Gateway — l'indirizzo IP del "router" tun2socks, che hai indicato durante la creazione del servizio systemd.

In questo modo, l'interfaccia tun2socks ha l'indirizzo 172.16.1.2, e il servizio tun2socks — 172.16.1.1, che funge da gateway per tutte le connessioni dall'interfaccia virtuale.

Configura il punto di accesso virtuale

Installa le dipendenze:

apt install util-linux procps hostapd iw haveged

Clona il repository create_ap sulla tua macchina:

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

Vai alla cartella del repository sulla tua macchina:

cd create_ap

Installa nel sistema:

make install

Il tuo sistema avrà una configurazione /etc/create_ap.conf. Ecco le opzioni principali da modificare:

GATEWAY=10.0.0.1 — è meglio creare una rete riservata separata.
NO_DNS=1 — disattivalo, poiché questo parametro sarà gestito dall'interfaccia virtuale systemd-networkd.
NO_DNSMASQ=1 — disattivalo per lo stesso motivo.
WIFI_IFACE=wlp6s0 — interfaccia wireless del laptop.
INTERNET_IFACE=tun2socks — interfaccia virtuale creata per tun2socks.
SSID=hostapd — nome del punto di accesso virtuale.
PASSPHRASE=12345678 — password.

Non dimenticare di abilitare il servizio:

systemctl enable create_ap

Abilita il server DHCP in systemd-networkd

Il servizio create_ap inizializza l'interfaccia virtuale nel sistema ap0. L'interfaccia dovrebbe avere dnsmasq attaccata, ma perché installare servizi inutili se systemd-networkd ha un server DHCP integrato?

Per abilitarlo, definiamo le impostazioni di rete per il punto di accesso virtuale. A tal fine, crea un file /etc/systemd/network/25-ap0.network con il seguente contenuto:

[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

Dopo che il servizio create_ap ha inizializzato l'interfaccia virtuale ap0, systemd-networkd assegnerà automaticamente un indirizzo IP e attiverà il server DHCP.

Le righe EmitDNS=yes e DNS=10.0.0.1 trasmettono le impostazioni del server DNS ai dispositivi connessi al punto di accesso.

Se non hai intenzione di utilizzare un server DNS locale — nel mio caso è dnscrypt-proxy — puoi installare DNS=10.0.0.1 in DNS=192.168.1.1, dove 192.168.1.1 — l'indirizzo del tuo gateway originale. Allora le richieste DNS del tuo host e della rete locale passeranno in chiaro attraverso i server del provider.

EmitNTP=yes e NTP=192.168.1.1 trasmettono le impostazioni NTP.

Lo stesso vale per la stringa NTP=10.0.0.1.

Configura e imposta il server NTP

Installa nel sistema:

apt install ntp

Modifica il file di configurazione /etc/ntp.conf. Commenta gli indirizzi dei pool 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

Aggiungi gli indirizzi dei server pubblici, ad esempio Google Public NTP:

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

Consenti l'accesso al server ai client della tua rete:

restrict 10.0.0.0 mask 255.255.255.0

Abilita la diffusione nella tua rete:

broadcast 10.0.0.255

Infine, aggiungi gli indirizzi di questi server nella tabella di routing statico. Per fare ciò, apri il file di configurazione dell'interfaccia wireless /etc/systemd/network/25-wlp6s0.network e aggiungi alla fine della sezione 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

Puoi scoprire gli indirizzi dei tuoi server NTP utilizzando l'utility host nel seguente modo:

host time1.google.com

Installa dnscrypt-proxy, rimuovi la pubblicità e nascondi il traffico DNS dal provider

apt install dnscrypt-proxy

Per servire le richieste DNS dell'host e della rete locale, modifica il socket /lib/systemd/system/dnscrypt-proxy.socket. Modifica le seguenti righe:

ListenStream=0.0.0.0:53
ListenDatagram=0.0.0.0:53

Riavvia systemd:

systemctl daemon-reload

Modifica il file di configurazione /etc/dnscrypt-proxy/dnscrypt-proxy.toml:

server_names = ['adguard-dns']

Per indirizzare le connessioni dnscrypt-proxy tramite tun2socks, aggiungi qui sotto:

force_tcp = true

Modifica il file di configurazione /etc/resolv.conf, che informa il server DNS dell'host.

nameserver 127.0.0.1
nameserver 192.168.1.1

La prima riga include l'uso di dnscrypt-proxy, la seconda utilizza il gateway originale, nel caso in cui il server dnscrypt-proxy non sia disponibile.

Fatto!

Riavvia o interrompi i servizi di rete attivi:

systemctl stop networking NetworkManager NetworkManager-wait-online

E riavvia tutti i necessari:

systemctl restart systemd-networkd tun2socks create_ap dnscrypt-proxy ntp

Dopo il riavvio o il restart avrai un secondo punto di accesso, che inoltra l'host e i dispositivi della rete locale in SOCKS.

Ecco come appare l'output ip a di un normale laptop:

1: lo:  mtu 65536 qdisc noqueue stato SCONOSCIUTO gruppo 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 per sempre preferred_lft per sempre
    inet6 ::1/128 scope host 
       valid_lft per sempre preferred_lft per sempre
2: tun2socks:  mtu 1500 qdisc pfifo_fast stato SU grupo default qlen 500
    link/none 
    inet 172.16.1.2/24 brd 172.16.1.255 scope global tun2socks
       valid_lft per sempre preferred_lft per sempre
    inet6 fe80::122b:260:6590:1b0e/64 scope link stable-privacy 
       valid_lft per sempre preferred_lft per sempre
3: enp4s0:  mtu 1500 qdisc pfifo_fast stato GIÙ gruppo default qlen 1000
    link/ether e8:11:32:0e:01:50 brd ff:ff:ff:ff:ff:ff
4: wlp6s0:  mtu 1500 qdisc noqueue stato SU gruppo 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 per sempre preferred_lft per sempre
    inet6 fe80::4eed:deff:fecb:cf85/64 scope link 
       valid_lft per sempre preferred_lft per sempre
5: ap0:  mtu 1500 qdisc noqueue stato SU gruppo 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 per sempre preferred_lft per sempre
    inet6 fe80::4eed:deff:fecb:cf86/64 scope link 
       valid_lft per sempre preferred_lft per sempre

In conclusione

Il provider vede solo una connessione criptata al tuo server SOCKS, quindi non vede nulla.
Eppure vede le vostre richieste NTP; per prevenire ciò, rimuovete le route statiche per i server NTP. Tuttavia, non è certo che il vostro server SOCKS consenta il protocollo NTP.

Fix noto su Debian 10

Se provi a riavviare il servizio di rete dalla console, esso fallirà con un errore. Questo è dovuto al fatto che una sua parte, sotto forma di interfaccia virtuale, è legata al servizio tun2socks, il che significa che è in uso. Per riavviare il servizio di rete, è necessario prima fermare il servizio tun2socks. Ma, penso che se sei arrivato fin qui, per te non sarà un problema!