🥇Costruire un router SOCKS su un laptop con Debian 10

Per un anno (o due) ho rimandato la pubblicazione di questo articolo per un motivo 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, ho ricevuto un numero sufficiente di richieste in privato da parte di persone che chiedevano aiuto nella configurazione, il che significa che i miei articoli precedenti non sono esaustivi. Del resto, sospettavo che i metodi descritti in essi non spiegassero del tutto le complessità della configurazione di Linux per la routinizzazione in SOCKS. Inoltre, sono stati scritti per Debian Stretch e, dopo l'aggiornamento a Buster, nel sistema di init systemd ho notato alcune piccole modifiche nell'interazione dei servizi. Inoltre, nei miei articoli non ho utilizzato systemd-networkd, anche se è la più adatta per configurazioni di rete complesse.

Oltre ai cambiamenti sopraindicati, nella mia configurazione sono state aggiunte queste risorse: hostapd — un servizio per la virtualizzazione del punto di accesso, ntp per la sincronizzazione dell'orario dei client della rete locale, dnscrypt-proxy per la crittografia delle connessioni DNS e per la disattivazione della pubblicità sui client della rete locale, e come ho accennato in precedenza, systemd-networkd per la configurazione delle interfacce di rete.

Ecco un semplice diagramma di flusso dell'architettura di un tale router.

Quindi, ricapitolando, quali obiettivi intende raggiungere questo ciclo di articoli:

Routinizzare in SOCKS tutte le connessioni del sistema operativo, così come le connessioni di tutti i dispositivi collegati alla rete con il laptop.
Il laptop, nel mio caso, deve rimanere completamente mobile. Cioè, permettere di utilizzare l'ambiente desktop e non essere vincolato a una posizione fisica.
L'ultimo punto implica il collegamento e la routinizzazione solo attraverso l'interfaccia wireless integrata.
E naturalmente, creare una guida esaustiva e analizzare le tecnologie pertinenti secondo le mie modeste conoscenze.

Cosa verrà trattato in questo articolo:

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

Passaggi facoltativi:

ntp Installeremo e configureremo il server per la sincronizzazione dell'ora sui client del punto di accesso virtuale.
dnscrypt-proxy Crittografiamo le richieste DNS, le instradiamo in SOCKS e disattiviamo i domini pubblicitari per la rete locale.

Perché tutto questo?

È uno dei modi per organizzare la protezione delle connessioni TCP della rete locale. Il principale vantaggio è che tutte le connessioni vanno in SOCKS, se non viene costruito un percorso statico attraverso il gateway originale. Ciò significa che non è necessario configurare le impostazioni del server SOCKS a programmi separati o ai client della rete locale — tutti vanno in SOCKS per impostazione predefinita, poiché è il gateway predefinito, finché non indichiamo il contrario.

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

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

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

Installa 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 sistemazione apparirà una cartella badvpn. Crea una cartella separata per la compilazione

mkdir badvpn-build

Passa a essa

cd badvpn-build

Compila tun2socks

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

Installa nel sistema

make install

Parametro -DBUILD_NOTHING_BY_DEFAULT=1 disabilita la compilazione di tutti i componenti del repository badvpn.
—DBUILD_TUN2SOCKS=1 includerà nella compilazione il 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 accetta il nome dell'interfaccia virtuale che stiamo inizializzando con systemd-networkd.
--netif-ipaddr l'indirizzo di rete del "router" tun2socks a cui si collega l'interfaccia virtuale. È meglio farlo su una sottorete riservata.
--socks-server-addr accetta 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

Abilitiamo 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 sia disponibile una connessione di rete prima che systemd continui a avviare altri servizi che dipendono dalla rete. Lo disabilitiamo, poiché passeremo a una soluzione equivalente di systemd-networkd.

Abilitiamolo 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 è una direttiva che abilita l'inoltro dei pacchetti sull'interfaccia di rete.
Address è responsabile dell'assegnazione di un indirizzo IP all'interfaccia wireless. Lo indichiamo staticamente poiché con la direttiva equivalente DHCP=yes, systemd-networkd crea un gateway di default nel sistema. Tutto il traffico passerà quindi per il gateway originale, e non per il futuro interfaccia virtuale in una rete diversa. Puoi controllare l'attuale gateway di default 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. Aggiungi quindi 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 di default 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 "alzare" l'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 punto, è probabile che questo servizio non sia presente nel tuo sistema.

Quindi crealo con il comando:

systemctl enable wpa_supplicant@wlp6s0

Ho usato wlp6s0 come nome della tua interfaccia wireless. Questo nome potrebbe essere diverso 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, a sua volta, 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 assegnarà alla futura interfaccia virtuale durante la sua inizializzazione.
Kind è il tipo di interfaccia virtuale. In base al nome del servizio tun2socks, puoi immaginare che utilizzi un'interfaccia di tipo tun.
netdev è l'estensione dei file che systemd-networkd viene utilizzata per inizializzare le interfacce di rete virtuali. L'indirizzo e altre impostazioni di rete per queste interfacce sono specificate nei .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.
Address è l'indirizzo IP che sarà assegnato all'interfaccia virtuale. Deve essere nella stessa rete dell'indirizzo che hai specificato nel servizio tun2socks
Gateway è l'indirizzo IP del "router" tun2socks, che hai specificato durante la creazione del servizio systemd.

Pertanto, l'interfaccia tun2socks ha l'indirizzo 172.16.1.2, e il servizio tun2socks — 172.16.1.1, ovvero 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

Scarica il repository create_ap sulla tua macchina:

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

Vai nella cartella del repository sulla tua macchina:

cd create_ap

Installa nel sistema:

make install

Nel tuo sistema apparirà un file di configurazione /etc/create_ap.conf. Ecco le opzioni principali da modificare:

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

Non dimenticate di attivare il servizio:

systemctl enable create_ap

Attivare il server DHCP in systemd-networkd

Servizio create_ap inizializza un'interfaccia virtuale nel sistema ap0. In teoria, su questa interfaccia è presente dnsmasq, ma perché installare servizi superflui se systemd-networkd ha un server DHCP integrato?

Per attivarlo, definiamo le impostazioni di rete per il punto 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 inizializza l'interfaccia virtuale ap0, systemd-networkd le 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 prevedi di utilizzare un server DNS locale — nel mio caso è dnscrypt-proxy — puoi impostare DNS=10.0.0.1 in DNS=192.168.1.1, dove 192.168.1.1 — l'indirizzo del tuo gateway originale. In tal caso, le richieste DNS del tuo host e della rete locale passeranno in forma non crittografata attraverso i server del provider.

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

Lo stesso vale per la riga NTP=10.0.0.1.

Installa e configura 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, come 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

Attiva il broadcasting nella tua rete:

broadcast 10.0.0.255

Infine, aggiungi gli indirizzi di questi server nella tabella di routing statica. A tal fine, 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 gestire le richieste DNS dell'host e della rete locale, modifica il socket /lib/systemd/system/dnscrypt-proxy.socket. Cambia 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 attiva l'uso di dnscrypt-proxy, la seconda utilizza il gateway originale, nel caso in cui il server dnscrypt-proxy non sia disponibile.

Fatto!

Riavvia il computer o interrompi i servizi di rete attivi:

systemctl stop networking NetworkManager NetworkManager-wait-online

E riavvia tutti quelli necessari:

systemctl restart systemd-networkd tun2socks create_ap dnscrypt-proxy ntp

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

Questo è un esempio di output ip a di un normale laptop:

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

In definitiva

Il fornitore vede solo una connessione crittografata al tuo server SOCKS, quindi non vede nulla.
Eppure può vedere le tue richieste NTP; per prevenire ciò, rimuovi le rotte statiche per i server NTP. Tuttavia, non è certo che il tuo server SOCKS consenta il protocollo NTP.

Corretta osservazione su Debian 10

Se si tenta di riavviare il servizio di rete dalla console, esso si fermerà con un errore. Questo è legato al fatto che una sua parte sotto forma di interfaccia virtuale è legata al servizio tun2socks e quindi è utilizzata. Per riavviare il servizio di rete, è prima necessario fermare il servizio tun2socks. Ma, penso che se sei arrivato fino a qui, per te non sarà certamente un problema!