🥇Router im SOCKS auf einem Laptop mit Debian 10 aufbauen

Ein ganzes Jahr (oder zwei) habe ich die Veröffentlichung dieses Artikels aus einem einfachen Grund aufgeschoben – ich hatte bereits zwei Artikel veröffentlicht, in denen ich den Prozess der Erstellung eines SOCKS-Routers aus einem ganz gewöhnlichen Laptop mit Debian beschrieben habe.

Seitdem hat sich jedoch die stabile Version von Debian auf Buster aktualisiert, und ich habe zahlreiche Anfragen von Leuten erhalten, die um Unterstützung bei der Konfiguration gebeten haben, was bedeutet, dass meine vorherigen Artikel nicht umfassend sind. Nun, ich hatte auch vermutet, dass die in ihnen dargelegten Methoden die Feinheiten der Linux-Konfiguration für die SOCKS-Routing nicht vollständig abdecken. Außerdem wurden sie für Debian Stretch geschrieben, und nach dem Update auf Buster habe ich in der Systemd-Init-Umgebung einige kleine Änderungen in der Interaktion der Dienste bemerkt. Und in den Artikeln selbst habe ich systemd-networkd nicht verwendet, obwohl es am besten für komplexe Netzwerk-Konfigurationen geeignet ist.

Neben den oben genannten Änderungen wurden meiner Konfiguration auch Dienste wie hinzugefügt hostapd — ein Dienst zur Virtualisierung des Access Points, ntp zur Synchronisation der Zeit der Clients im lokalen Netzwerk, dnscrypt-proxy zur Verschlüsselung der Verbindungen über das DNS-Protokoll und zur Blockierung von Werbung auf Clients im lokalen Netzwerk, sowie, wie ich bereits erwähnt habe, systemd-networkd zur Konfiguration der Netzwerk-Interfaces.

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

Also, ich möchte an die Ziele erinnern, die dieser Artikelzyklus verfolgt:

Die gesamte OS-Verbindungen sowie die Verbindungen aller Geräte, die sich im selben Netzwerk mit dem Laptop befinden, über SOCKS zu routen.
In meinem Fall muss der Laptop vollständig mobil bleiben. Das bedeutet, dass er es ermöglichen sollte, die Desktop-Umgebung zu nutzen und nicht an einen physischen Standort gebunden zu sein.
Der letzte Punkt bedeutet, dass die Verbindung und das Routing nur über die integrierte drahtlose Schnittstelle erfolgen soll.
Und natürlich die Erstellung eines umfassenden Handbuchs sowie die Analyse der entsprechenden Technologien in dem Maße, wie es meinen bescheidenen Kenntnissen entspricht.

Was in diesem Artikel behandelt wird:

git — wir laden die Repositories der Projekte herunter tun2socks, die für das Routing von TCP-Verkehr zu SOCKS notwendig sind, und create_ap — ein Skript zur Automatisierung der Konfiguration eines virtuellen Access Points mithilfe von hostapd.
tun2socks — wir werden den systemd-Dienst im System aufbauen und installieren.
systemd-networkd — wir konfigurieren die drahtlosen und virtuellen Interfaces, die Tabellen für statisches Routing und die Weiterleitung von Paketen.
create_ap – Wir richten den systemd-Dienst im System ein, konfigurieren und starten den virtuellen Access Point.

Optionale Schritte:

ntp – Wir richten einen Server zur Zeitsynchronisation bei den Clients des virtuellen Access Points ein und konfigurieren ihn.
dnscrypt-proxy – Wir verschlüsseln DNS-Anfragen, leiten sie über SOCKS weiter und deaktivieren Werbedomains für das lokale Netzwerk.

Warum das Ganze?

Dies ist eine der Methoden zur Absicherung von TCP-Verbindungen im lokalen Netzwerk. Der Hauptvorteil besteht darin, dass alle Verbindungen über SOCKS laufen, wenn für sie kein statischer Pfad über das ursprüngliche Gateway eingerichtet wurde. Das bedeutet, dass es nicht notwendig ist, die SOCKS-Servereinstellungen für einzelne Programme oder Clients im lokalen Netzwerk zu konfigurieren – sie alle gehen standardmäßig über SOCKS, da dieser das Standardgateway ist, bis wir das Gegenteil angeben.

Im Wesentlichen fügen wir einen zweiten verschlüsselnden Router in Form eines Laptops vor dem ursprünglichen Router hinzu und nutzen die Internetverbindung des ursprünglichen Routers für bereits verschlüsselte SOCKS-Anfragen des Laptops, der wiederum die Anfragen der Clients im lokalen Netzwerk weiterleitet und verschlüsselt.

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

Dementsprechend verbinden sich alle Geräte mit dem virtuellen Access Point des Laptops.

Installieren Sie tun2socks im System

Solange Ihr Computer über Internetverbindung verfügt, laden Sie alle benötigten Werkzeuge herunter.

apt update

apt install git make cmake

Laden Sie das badvpn-Paket 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 den Code 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-Komponenten tun2socks.
make install – wird das Binary tun2socks in Ihrem System unter folgender Adresse installieren /usr/local/bin/badvpn-tun2socks.

Richten Sie den Dienst tun2socks in systemd ein

eine Datei erstellen /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 der virtuellen Schnittstelle, die wir mit systemd-networkd initialisieren.
--netif-ipaddr – die Netzwerkadresse des "Routers" tun2socks, an die die virtuelle Schnittstelle angeschlossen ist. Besser, sie als separate reservierte 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. --benutzername und --passwort.

Registrieren Sie den Dienst weiter

systemctl daemon-reload

Und aktivieren Sie

systemctl enable tun2socks

Bevor wir den Dienst starten, stellen wir sicher, dass er über eine virtuelle Netzwerkschnittstelle verfügt.

Wechseln Sie zu systemd-networkd

Aktivieren von 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 funktionierende Netzwerkverbindung wartet, bevor systemd die Ausführung anderer von der Netzwerkverfügbarkeit abhängigen Dienste fortsetzt. Wir deaktivieren ihn, da wir zu systemd-networkd wechseln.

Lassen Sie uns ihn gleich aktivieren:

systemctl enable systemd-networkd-wait-online

Konfigurieren Sie die drahtlose Netzwerkschnittstelle

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

[Match]
Name=wlp6s0

[Network]
Address=192.168.1.2/24
IPForward=yes

Name ist der Name Ihrer drahtlosen Schnittstelle. Identifizieren Sie sie mit dem Befehl ip a.
IPForward ist die Direktive, die das Weiterleiten von Paketen an der Netzwerkschnittstelle aktiviert.
Adresse verantwortlich für die Zuweisung der IP-Adresse zur drahtlosen Schnittstelle. Wir geben sie statisch an, weil bei entsprechender Direktive DHCP=yes, systemd-networkd ein Standardgateway im System erstellt. Dann wird der gesamte Datenverkehr über das ursprüngliche Gateway und nicht über die zukünftige virtuelle Schnittstelle in einem anderen Subnetz geleitet. Sie können das aktuelle Standardgateway mit dem Befehl überprüfen ip r

Erstellen Sie eine statische Route für den 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 ans Ende der von Ihnen erstellten Konfigurationsdatei für die drahtlose Schnittstelle 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 Access Points.
Destination ist die Adresse des SOCKS-Servers.

Konfigurieren Sie wpa_supplicant für systemd-networkd

systemd-networkd verwendet wpa_supplicant, um sich mit dem geschützten Access Point zu verbinden. Beim Versuch, die drahtlose Schnittstelle zu 'aktivieren', startet systemd-networkd den Dienst wpa_supplicant@name

name ist der Name der drahtlosen Schnittstelle. Wenn Sie bis zu diesem Zeitpunkt systemd-networkd nicht verwendet haben, fehlt dieser Dienst wahrscheinlich in Ihrem System.

Erstellen Sie ihn daher mit dem Befehl:

systemctl enable wpa_supplicant@wlp6s0

Ich habe wlp6s0 als Name Ihrer drahtlosen Schnittstelle. Ihr Name kann davon abweichen. Sie können ihn mit dem Befehl erfahren ip l.

Jetzt wurde der Dienst erstellt wpa_supplicant@wlp6s0 wird gestartet, wenn das drahtlose Interface „gehoben“ wird, sucht jedoch seinerseits die SSID-Einstellungen und das Passwort des Access Points in der Datei /etc/wpa_supplicant/wpa_supplicant-wlp6s0. Daher müssen Sie es mit dem Dienstprogramm erstellen wpa_passphrase.

Führen Sie dazu den Befehl aus:

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

wo SSID — ist der Name Ihres Access Points, password — das Passwort, und wlp6s0 — 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 der Initialisierung zuweisen wird.
Kind — ist der Typ des virtuellen Interfaces. Basierend auf dem Namen des Dienstes tun2socks können Sie erraten, dass es ein Interface vom Typ tun.
netdev — ist die Erweiterung von Dateien, die systemd-networkd für die Initialisierung virtueller Netzwerkinterfaces verwendet werden. Die Adresse und andere Netzwerkeinstellungen für diese Interfaces werden 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-Datei angegeben haben.
Adresse — die IP-Adresse, die dem virtuellen Interface zugewiesen wird. Muss im selben Netzwerk sein wie die Adresse, 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, das heißt, es ist das Gateway für alle Verbindungen vom virtuellen Interface.

Konfigurieren Sie den virtuellen Access Point

Installieren Sie die Abhängigkeiten:

apt install util-linux procps hostapd iw haveged

Laden Sie das Repository create_ap auf Ihre Maschine herunter:

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

Wechseln Sie in das Repository-Verzeichnis auf Ihrer Maschine:

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 zur Bearbeitung:

GATEWAY=10.0.0.1 — besser, es als separates reserviertes Subnetz zu gestalten.
NO_DNS=1 — deaktivieren Sie, da dieses Parameter vom virtuellen Interface systemd-networkd verwaltet wird.
NO_DNSMASQ=1 — aus demselben Grund deaktivieren.
WIFI_IFACE=wlp6s0 — das 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 initialisiert im System das virtuelle Interface ap0. Idealerweise läuft dnsmasq auf dieser Schnittstelle, aber warum zusätzliche Dienste installieren, wenn systemd-networkd einen integrierten DHCP-Server hat?

Um ihn zu aktivieren, definieren wir die Netzwerkeinstellungen für den virtuellen Access Point. Erstellen Sie dazu 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 die virtuelle Schnittstelle initialisiert hat, ap0, wird systemd-networkd ihr automatisch eine IP-Adresse zuweisen und den DHCP-Server aktivieren.

Die Zeilen EmitDNS=yes und DNS=10.0.0.1 geben die DNS-Servereinstellungen an die Geräte weiter, die mit dem Access Point verbunden sind.

Wenn Sie keinen lokalen DNS-Server verwenden möchten — in meinem Fall ist das dnscrypt-proxy — können Sie DNS=10.0.0.1 in DNS=192.168.1.1

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 geben die NTP-Einstellungen an.

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

Installieren und konfigurieren Sie den NTP-Server

Installieren Sie es im System:

apt install ntp

Bearbeiten Sie die Konfiguration. /etc/ntp.confKommentieren Sie die Adressen der Standardpools 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, beispielsweise 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 den Clients aus Ihrem Netzwerk Zugriff auf den Server:

restrict 10.0.0.0 mask 255.255.255.0

Aktivieren Sie den Broadcast in Ihr Netzwerk:

broadcast 10.0.0.255

Fügen Sie schließlich die Adressen dieser Server in die statische Routingtabelle ein. Öffnen Sie dazu die Konfigurationsdatei für die drahtlose 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 Tool host folgendermaßen ausführen:

host time1.google.com

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

apt install dnscrypt-proxy

Um DNS-Anfragen für den Host und das lokale Netzwerk zu bedienen, bearbeiten Sie den Socket. /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 Verbindungen von dnscrypt-proxy über tun2socks zu leiten, fügen Sie Folgendes hinzu:

force_tcp = true

Bearbeiten Sie die Konfiguration. /etc/resolv.conf, der dem DNS-Server des Hosts mitteilt.

nameserver 127.0.0.1
nameserver 192.168.1.1

Die erste Zeile aktiviert die Verwendung von dnscrypt-proxy, die zweite verwendet das ursprüngliche Gateway, falls der dnscrypt-proxy-Server nicht verfügbar ist.

Fertig!

Starten Sie Ihren Computer neu oder stoppen Sie laufende 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 Neuanlage haben Sie einen zweiten Zugangspunkt, der den Host und die Geräte im lokalen Netzwerk zu SOCKS weiterleitet.

So sieht die Ausgabe aus ip a eines normalen Laptops:

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 damit nichts anderes.
Dennoch sieht er Ihre NTP-Anfragen. Um dies zu verhindern, entfernen Sie die statischen Routen für NTP-Server. Es steht jedoch nicht fest, ob Ihr SOCKS-Server das NTP-Protokoll unterstützt.

Workaround, entdeckt auf Debian 10

Wenn Sie versuchen, den Netzwerkdienst über die Konsole neu zu starten, schlägt dies mit einem Fehler fehl. Dies liegt daran, dass ein Teil davon in Form eines virtuellen Interfaces an den Dienst tun2socks gebunden ist, was bedeutet, dass es verwendet wird. Um den Netzwerkdienst neu zu starten, müssen Sie zuerst den Dienst tun2socks stoppen. Aber ich denke, wenn Sie bis hierhin gelesen haben, ist das für Sie sicher kein Problem!