🥇 Einen Router in SOCKS auf einem Laptop mit Debian 10 erstellen

Das ganze Jahr (oder zwei) habe ich die Veröffentlichung dieses Artikels aufgeschoben, weil ich bereits zwei Artikel veröffentlicht habe, in denen ich den Prozess der Erstellung eines SOCKS-Routers aus einem ganz normalen Laptop mit Debian beschrieben habe.

Seitdem ist die stabile Version von Debian auf Buster aktualisiert worden, und ich habe genug Anfragen in meinem persönlichen Postfach erhalten, um bei der Einrichtung zu helfen. Das bedeutet, dass meine vorherigen Artikel nicht vollständig sind. Ich hätte es mir gedacht, dass die in ihnen beschriebenen Methoden alle Feinheiten der Linux-Einrichtung für die SOCKS-Routing nicht vollständig abdecken. Außerdem sind sie für Debian Stretch geschrieben, und nach dem Update auf Buster habe ich kleine Änderungen im Dienstmanagement unter systemd bemerkt. In meinen Artikeln habe ich zudem systemd-networkd nicht verwendet, obwohl sie sich am besten für komplexe Netzwerk-Konfigurationen eignet.

Zusätzlich zu den genannten Änderungen habe ich meiner Konfiguration folgende Dienste hinzugefügt: hostapd — Dienst für die Virtualisierung des Zugangspunktes, ntp zur Zeit-Synchronisation der Clients im lokalen Netzwerk, dnscrypt-proxy zum Verschlüsseln von Verbindungen über das DNS-Protokoll und zur Deaktivierung von Werbung auf Geräten im lokalen Netzwerk, sowie, wie bereits erwähnt, systemd-networkd zur Konfiguration von Netzwerkinterfaces.

Hier ist ein einfaches Blockdiagramm der internen Struktur eines solchen Routers.

Ich möchte daher die Ziele, die dieser Artikelzyklus verfolgt, erneut in Erinnerung rufen:

Alle Verbindungen des Betriebssystems sowie die Verbindungen aller Geräte, die mit dem Laptop in einem Netzwerk verbunden sind, über SOCKS zu leiten.
Der Laptop muss in meinem Fall vollständig mobil bleiben. Das heißt, er sollte die Nutzung der Desktop-Umgebung ermöglichen und nicht an einen festen Standort gebunden sein.
Der letzte Punkt beinhaltet eine Verbindung und das Routing ausschließlich über das integrierte WLAN-Interface.
Und natürlich die Erstellung eines umfassenden Leitfadens sowie die Erörterung der entsprechenden Technologien in dem Umfang meiner bescheidenen Kenntnisse.

In diesem Artikel werden wir folgendes behandeln:

git — die Repositories der Projekte herunterladen tun2socks, notwendig für das Routing von TCP-Datenverkehr zu SOCKS, und create_ap — ein Skript zur Automatisierung der Konfiguration eines virtuellen Access Points mit Hilfe von hostapd.
tun2socks — wir werden den systemd-Dienst im System erstellen und installieren.
systemd-networkd — Wir richten drahtlose und virtuelle Schnittstellen, statische Routing-Tabellen und Paketweiterleitungen ein.
create_ap — Wir installieren den Systemdienst systemd, konfigurieren und starten den virtuellen Zugangspunkt.

Optionale Schritte:

ntp — Wir installieren und konfigurieren einen Zeit-Synchronisationsserver für die Clients des virtuellen Zugangspunkts.
dnscrypt-proxy — Wir verschlüsseln DNS-Anfragen, leiten sie über SOCKS und deaktivieren Werbedomains im lokalen Netzwerk.

Warum das alles?

Das ist eine Möglichkeit, den Schutz von TCP-Verbindungen im lokalen Netzwerk zu organisieren. Der Hauptvorteil ist, dass alle Verbindungen über SOCKS gehen, es sei denn, es gibt eine statische Route über das ursprüngliche Gateway. Das bedeutet, dass SOCKS-Server-Einstellungen nicht separat für Programme oder Clients im lokalen Netzwerk konfiguriert werden müssen – sie gehen standardmäßig über SOCKS, da dieser das Standardgateway ist, bis wir etwas anderes angeben.

Im Grunde fügen wir einen zweiten verschlüsselnden Router in Form eines Laptops vor dem ursprünglichen Router hinzu und nutzen die Internetverbindung des originalen Routers für bereits verschlüsselte SOCKS-Anfragen des Laptops, der wiederum die Anfragen der Netzwerkclients routet und verschlüsselt.

Aus Sicht des Anbieters sind wir ständig mit einem Server verbunden, der verschlüsselten Datenverkehr hat.

Demnach verbinden sich alle Geräte mit dem virtuellen Zugangspunkt des Laptops.

Installieren Sie tun2socks im System.

Solange Ihre Maschine Internet hat, laden Sie alle benötigten Werkzeuge herunter.

apt update

apt install git make cmake

Laden Sie das Paket badvpn herunter.

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

In Ihrem System wird ein Ordner erscheinen. badvpn. Erstellen Sie einen separaten Ordner für den Build.

mkdir badvpn-build

Wechseln Sie in diesen Ordner.

cd badvpn-build

Bauen Sie es. tun2socks

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

Installieren Sie im System.

make install

Parameter -DBUILD_NOTHING_BY_DEFAULT=1 deaktiviert den Build aller Komponenten des badvpn-Repositories.
—DBUILD_TUN2SOCKS=1 aktiviert den Build der Komponente. tun2socks.
make install — wird das Binary tun2socks in Ihr System unter der Adresse installieren. /usr/local/bin/badvpn-tun2socks.

Installieren Sie den Dienst tun2socks in systemd.

aufrufen können. /etc/systemd/system/tun2socks.service mit folgendem Inhalt:

[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 — akzeptiert den Namen des virtuellen Interfaces, das wir mit systemd-networkd initialisieren.
--netif-ipaddr — die Netzwerkadresse des "Routers" tun2socks, mit dem das virtuelle Interface verbunden ist. Es ist besser, dies in einem separaten reservierten Subnetz.
--socks-server-addr — akzeptiert den Socket (Adresse:Port des SOCKS-Servers).

Wenn Ihr SOCKS-Server eine Authentifizierung erfordert, können Sie die Parameter angeben --username und --password.

Registrieren Sie dann den Dienst

systemctl daemon-reload

Und aktivieren Sie

systemctl enable tun2socks

Bevor Sie den Dienst starten, stellen wir sicher, dass er über das virtuelle Netzwerkinterface verfügt.

Wechseln Sie zu systemd-networkd

Aktivieren wir systemd-networkd:

systemctl enable systemd-networkd

Deaktivieren Sie die aktuellen Netzwerkdienste.

systemctl disable networking NetworkManager NetworkManager-wait-online

NetworkManager-wait-online — ist ein Dienst, der auf eine aktive Netzwerkverbindung wartet, bevor systemd mit dem Start anderer Dienste fortfährt, die von der Netzwerkanbindung abhängen. Wir deaktivieren ihn, da wir zu dem Äquivalent systemd-networkd wechseln werden.

Lassen Sie uns dies sofort aktivieren:

systemctl enable systemd-networkd-wait-online

Konfigurieren Sie das drahtlose Netzwerkinterface

Erstellen Sie eine Konfigurationsdatei für systemd-networkd für das drahtlose Netzwerkinterface /etc/systemd/network/25-wlp6s0.network.

[Match]
Name=wlp6s0

[Network]
Address=192.168.1.2/24
IPForward=yes

Name — das ist der Name Ihres drahtlosen Interfaces. Identifizieren Sie es mit dem Befehl ip a.
IPForward — ist eine Direktive, die das Weiterleiten von Paketen über ein Netzwerk-Interface aktiviert.
Adresse ist verantwortlich für die Zuweisung der IP-Adresse an das drahtlose Interface. Wir legen es statisch fest, weil bei einer entsprechenden Direktive DHCP=yes, erstellt systemd-networkd in Ihrem System ein Standardgateway. Dann wird der gesamte Verkehr über das ursprüngliche Gateway geleitet und nicht über das zukünftige virtuelle Interface im anderen Subnetz. Sie können das aktuelle Standardgateway mit dem Befehl überprüfen ip r

Erstellen Sie eine statische Route zum entfernten SOCKS-Server

Wenn Ihr SOCKS-Server nicht lokal, sondern remote ist, müssen Sie eine statische Route dafür erstellen. Fügen Sie dazu einen Abschnitt hinzu Route am Ende der von Ihnen erstellten Konfigurationsdatei für das drahtlose Interface mit folgendem Inhalt hinzu:

[Route]
Gateway=192.168.1.1
Destination=0.0.0.0

Gateway — ist das Standardgateway oder die Adresse Ihres ursprünglichen Zugangspunktes.
Ziel — die Adresse des SOCKS-Servers.

Konfigurieren Sie wpa_supplicant für systemd-networkd

systemd-networkd verwendet wpa_supplicant, um sich mit einem gesicherten Zugangspunkt zu verbinden. Wenn der drahtlose Interface von systemd-networkd "hochgefahren" wird, startet es den Dienst. wpa_supplicant@Name, wobei Name — ist der Name des drahtlosen Interfaces. Wenn Sie bis jetzt noch systemd-networkd verwendet haben, wird dieser Dienst wahrscheinlich nicht auf Ihrem System vorhanden sein.

Erstellen Sie ihn daher mit dem Befehl:

systemctl enable wpa_supplicant@wlp6s0

Ich habe verwendet wlp6s0 als Name für Ihr drahtloses Interface. Ihr Name kann jedoch davon abweichen. Sie können ihn mit dem Befehl herausfinden ip l.

Jetzt wird der erstellte Dienst wpa_supplicant@wlp6s0 beim „Hochfahren“ des drahtlosen Interfaces gestartet, sucht jedoch gleichzeitig die SSID- und Passwort-Einstellungen des Access Points in der Datei /etc/wpa_supplicant/wpa_supplicant-wlp6s0. Daher ist es notwendig, ihn mit dem Dienstprogramm wpa_passphrase.

zu erstellen. Führen Sie dazu den Befehl aus:

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

wobei SSID — ist der Name Ihres Access Points, password — das Passwort, und wlp6s0 — ist der Name Ihres drahtlosen Interfaces.

Initialisieren Sie das virtuelle Interface für tun2socks

Erstellen Sie eine Datei zur Initialisierung des neuen virtuellen Interfaces im System/etc/systemd/network/25-tun2socks.netdev

[NetDev]
Name=tun2socks
Kind=tun

Name — ist der Name, den systemd-networkd dem zukünftigen virtuellen Interface bei seiner Initialisierung zuweisen wird.
Kind — ist eine Art virtueller Schnittstelle. Aus dem Namen des Dienstes tun2socks können Sie schließen, dass er eine Schnittstelle vom Typ verwendet. tun.
netdev — ist eine Erweiterung von Dateien, die systemd-networkd zum Initialisieren virtueller Netzwerkinterfaces verwendet werden. Die Adresse und andere Netzwerkeinstellungen für diese Interfaces sind in .network-Dateien.

Erstellen Sie eine solche Datei /etc/systemd/network/25-tun2socks.network mit folgendem Inhalt:

[Match]
Name=tun2socks

[Network]
Address=172.16.1.2/24
Gateway=172.16.1.1

Name — der Name des virtuellen Interfaces, den Sie in netdev- der Datei angegeben haben.
Adresse — die IP-Adresse, die dem virtuellen Interface zugewiesen wird. Muss im selben Netzwerk wie die Adresse sein, die Sie im Dienst tun2socks angegeben haben.
Gateway — die IP-Adresse des „Routers“ tun2socks, die Sie bei der Erstellung des systemd-Dienstes angegeben haben.

Somit hat das Interface tun2socks die Adresse 172.16.1.2, und der Dienst tun2socks — 172.16.1.1, also fungiert es als Gateway für alle Verbindungen vom virtuellen Interface.

Richten Sie den virtuellen Access Point ein

Installieren Sie die Abhängigkeiten:

apt install util-linux procps hostapd iw haveged

Laden Sie das Repository herunter create_ap auf Ihren Rechner:

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

Wechseln Sie in das Verzeichnis des Repositories auf Ihrem Computer:

cd create_ap

Installieren Sie es im System:

make install

In Ihrem System wird eine Konfiguration erscheinen /etc/create_ap.conf. Hier sind die wichtigsten Optionen zum Bearbeiten:

GATEWAY=10.0.0.1 — es ist besser, ein separates reserviertes Subnetz zu erstellen.
NO_DNS=1 — deaktivieren Sie dies, da dieser Parameter vom virtuellen Interface systemd-networkd verwaltet wird.
NO_DNSMASQ=1 — deaktivieren Sie dies aus demselben Grund.
WIFI_IFACE=wlp6s0 — der drahtlose Interface des Laptops.
INTERNET_IFACE=tun2socks — das virtuelle Interface, das für tun2socks erstellt wurde.
SSID=hostapd — der Name des virtuellen Access Points.
PASSPHRASE=12345678 — das Passwort.

Vergessen Sie nicht, den Dienst zu aktivieren:

systemctl enable create_ap

Aktivieren Sie den DHCP-Server in systemd-networkd

Der Dienst create_ap initiiert in dem System das virtuelle Interface ap0. Idealerweise wäre dnsmasq an diesem Interface "angebunden", aber warum unnötige Dienste installieren, wenn systemd-networkd einen integrierten DHCP-Server enthält?

Um ihn zu aktivieren, definieren wir die Netzwerkeinstellungen für den virtuellen Punkt. Dazu erstellen Sie eine Datei /etc/systemd/network/25-ap0.network mit folgendem Inhalt:

[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

Nachdem der Dienst create_ap das virtuelle Interface initialisiert hat ap0, wird systemd-networkd ihm automatisch eine IP-Adresse zuweisen und den DHCP-Server aktivieren.

Zeilen EmitDNS=yes und DNS=10.0.0.1 übertragen die Einstellungen des DNS-Servers an die Geräte, die mit dem Access Point verbunden sind.

Wenn Sie keinen lokalen DNS-Server - in meinem Fall dnscrypt-proxy - verwenden möchten, können Sie installieren DNS=10.0.0.1 in DNS=192.168.1.1, wobei 192.168.1.1 — die Adresse Ihres ursprünglichen Gateways. Dann werden die DNS-Anfragen Ihres Hosts und des lokalen Netzwerks unverschlüsselt über die Server des Providers geleitet.

EmitNTP=yes und NTP=192.168.1.1 Übertragen Sie die NTP-Konfiguration.

Das Gleiche gilt für die Zeile NTP=10.0.0.1.

Richten Sie den NTP-Server ein und konfigurieren Sie ihn

Installieren Sie es im System:

apt install ntp

Bearbeiten Sie die Konfiguration /etc/ntp.conf. Kommentieren Sie die Adressen der Standard-Pools aus:

#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

Fügen Sie die Adressen der öffentlichen Server hinzu, zum Beispiel Google Public NTP:

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

Gewähren Sie Benutzern aus Ihrem Netzwerk Zugang zum Server:

restrict 10.0.0.0 mask 255.255.255.0

Aktivieren Sie das Broadcasting in Ihrem Netzwerk:

broadcast 10.0.0.255

Fügen Sie schließlich die Adressen dieser Server in die Tabelle der statischen Routen ein. Öffnen Sie dazu die Konfigurationsdatei der drahtlosen Schnittstelle /etc/systemd/network/25-wlp6s0.network und fügen Sie am Ende des Abschnitts hinzu 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

Sie können die Adressen Ihrer NTP-Server mit dem Dienstprogramm host $ ../..../waf ...

host time1.google.com

Installieren Sie dnscrypt-proxy, entfernen Sie Werbung und verbergen Sie den DNS-Verkehr vor dem Provider.

apt install dnscrypt-proxy

Um DNS-Anfragen für den Host und das lokale Netzwerk zu bedienen, passen Sie den Socket an. /lib/systemd/system/dnscrypt-proxy.socket. Ändern Sie die folgenden Zeilen:

ListenStream=0.0.0.0:53
ListenDatagram=0.0.0.0:53

Starten Sie neu. systemd:

systemctl daemon-reload

Bearbeiten Sie die Konfiguration /etc/dnscrypt-proxy/dnscrypt-proxy.toml:

server_names = ['adguard-dns']

Um die Verbindungen von dnscrypt-proxy über tun2socks zu leiten, fügen Sie Folgendes hinzu:

force_tcp = true

Bearbeiten Sie die Konfiguration /etc/resolv.conf, was dem DNS-Server mitteilt, der den Host bearbeitet.

nameserver 127.0.0.1
nameserver 192.168.1.1

Die erste Zeile aktiviert die Nutzung von dnscrypt-proxy, die zweite verwendet das ursprüngliche Gateway für den Fall, dass der dnscrypt-proxy-Server nicht verfügbar ist.

Fertig!

Starten Sie neu oder stoppen Sie die aktiven Netzwerkdienste:

systemctl stop networking NetworkManager NetworkManager-wait-online

Und starten Sie alle notwendigen Dienste neu:

systemctl restart systemd-networkd tun2socks create_ap dnscrypt-proxy ntp

Nach dem Neustart oder der Wiederherstellung haben Sie einen zweiten Access Point, der den Host und die Geräte im lokalen Netzwerk über SOCKS weiterleitet.

So sieht der Output aus ip a eines gewöhnlichen Laptops aus:

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

Insgesamt

Der Anbieter sieht nur die verschlüsselte Verbindung zu Ihrem SOCKS-Server und kann daher nichts einsehen.
Er sieht jedoch Ihre NTP-Anfragen. Um dies zu verhindern, entfernen Sie die statischen Routen zu den NTP-Servern. Allerdings ist es ungewiss, ob Ihr SOCKS-Server das NTP-Protokoll erlaubt.

Ein Workaround, der bei Debian 10 aufgefallen ist

Versuchen Sie, den Netzwerkdienst über die Konsole neu zu starten, wird er mit einem Fehler abstürzen. Das liegt daran, dass ein Teil davon in Form eines virtuellen Interfaces an den Dienst tun2socks gebunden ist und somit verwendet wird. Um den Netzwerkdienst neu zu starten, muss zunächst der Dienst tun2socks gestoppt werden. Aber ich denke, wenn Sie bis hierher gelesen haben, ist das für Sie sicher kein Problem!