🥇Budujemy router w SOCKS na laptopie z Debianem 10

Przez cały rok (a nawet dwa) odkładałem publikację tego artykułu z jednego głównego powodu — opublikowałem już dwa artykuły, w których opisałem proces tworzenia routera w SOCKS z zwykłego laptopa z Debianem.

Jednakże od tego czasu stabilna wersja Debiana została zaktualizowana do Buster, a ja otrzymałem wystarczającą liczbę wiadomości prywatnych od ludzi z prośbą o pomoc w konfiguracji, co oznacza, że moje wcześniejsze artykuły nie są wyczerpujące. Cóż, sam się domyślałem, że metody przedstawione w nich nie w pełni ujawniają wszystkie niuanse konfiguracji Linuxa do routingu w SOСKS. Do tego są one napisane dla Debiana Stretch, a po aktualizacji do Buster, w systemie inicjalizacji systemd zauważyłem drobne zmiany w interakcji usług. Zresztą nie używałem systemd-networkd w artykułach, chociaż jest to najlepsze rozwiązanie do skomplikowanych konfiguracji sieciowych.

Oprócz wyżej wymienionych zmian moja konfiguracja wzbogaciła się o takie usługi jak hostapd — usługa do wirtualizacji punktu dostępowego, ntp do synchronizacji czasu klientów w lokalnej sieci, dnscrypt-proxy do szyfrowania połączeń w protokole DNS i blokady reklam na klientach lokalnej sieci, a także, jak wspomniałem wcześniej, systemd-networkd do konfiguracji interfejsów sieciowych.

Oto najprostsza blokada schematyczna wewnętrznego urządzenia takiego routera.

Przypomnę, jakie cele przyświecają serii tych artykułów:

Zrutowanie wszystkich połączeń systemu operacyjnego SOCKS oraz połączeń wszystkich urządzeń w tej samej sieci co laptop.
Laptop w moim przypadku musi pozostać całkowicie mobilny. To znaczy, że powinien umożliwiać korzystanie z środowiska pulpitu i nie być związany z fizyczną lokalizacją.
Ostatni punkt oznacza podłączenie i routing tylko przez wbudowany interfejs bezprzewodowy.
No i oczywiście, stworzenie wyczerpującego przewodnika oraz omówienie odpowiednich technologii w miarę mojej skromnej wiedzy.

Co będzie omówione w tym artykule:

sshpass — pobierzemy repozytoria projektów tun2socks, niezbędnego do routingu ruchu TCP w SOCKS, i create_ap — skryptu do automatyzacji konfiguracji wirtualnego punktu dostępowego z użyciem hostapd.
tun2socks — zbudujemy i zainstalujemy usługę systemd w systemie.
systemd-networkd — skonfigurujemy interfejsy bezprzewodowe i wirtualne, tabele statycznego routingu oraz przekazywanie pakietów.
create_ap — zainstalujemy usługę systemd w systemie, skonfigurujemy i uruchomimy wirtualny punkt dostępu.

Opcjonalne kroki:

ntp — zainstalujemy i skonfigurujemy serwer do synchronizacji czasu na klientach wirtualnego punktu dostępu.
dnscrypt-proxy — zaszyfrujemy zapytania DNS, przekierujemy je do SOCKS i wyłączymy reklamy w domenach dla sieci lokalnej.

Po co to wszystko?

To jeden ze sposobów organizacji ochrony połączeń TCP w sieci lokalnej. Główną zaletą jest to, że wszystkie połączenia przebiegają przez SOCKS, chyba że dla nich zbudowana jest statyczna trasa przez oryginalny bramę. Oznacza to, że nie trzeba konfigurować ustawień serwera SOCKS dla oddzielnych aplikacji czy klientów sieci lokalnej — wszystkie domyślnie kierują do SOCKS, ponieważ jest on domyślną bramą, dopóki nie wskażemy inaczej.

W zasadzie dodajemy drugi szyfrujący router jako laptop przed oryginalnym routerem i wykorzystujemy połączenie internetowe oryginalnego routera do już zaszyfrowanych zapytań SOCKS laptopa, który z kolei kieruje i szyfruje zapytania klientów sieci lokalnej.

Z perspektywy dostawcy jesteśmy nieprzerwanie podłączeni do jednego serwera z zaszyfrowanym ruchem.

Odpowiednio, wszystkie urządzenia łączą się z wirtualnym punktem dostępu laptopa.

Zainstaluj tun2socks w systemie

Dopóki na Twoim komputerze jest internet, pobierz wszystkie potrzebne narzędzia.

apt update

apt install git make cmake

Pobierz pakiet badvpn

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

W Twoim systemie pojawi się folder badvpn. Utwórz oddzielny folder do kompilacji

mkdir badvpn-build

Przejdź do niego

cd badvpn-build

Skonfiguruj tun2socks

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

Zainstaluj w systemie

make install

Parametr -DBUILD_NOTHING_BY_DEFAULT=1 wyłącza kompilację wszystkich komponentów repozytorium badvpn.
—DBUILD_TUN2SOCKS=1 włącza w kompilacji komponent tun2socks.
make install — zainstaluje binarkę tun2socks w Twoim systemie pod adresem /usr/local/bin/badvpn-tun2socks.

Zainstaluj usługę tun2socks w systemd

Utwórz plik /etc/systemd/system/tun2socks.service z następującą zawartością:

[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 — przyjmuje nazwę wirtualnego interfejsu, który inicjalizujemy za pomocą systemd-networkd.
--netif-ipaddr — adres sieciowy «routera» tun2socks, do którego łączy się wirtualny interfejs. Lepiej stworzyć oddzielną zarezerwowaną podsiecć.
--socks-server-addr — przyjmuje gniazdo (adres:port serwera SOCKS).

Jeśli twój serwer SOCKS wymaga uwierzytelnienia, możesz podać parametry --username i --password.

Następnie zarejestruj usługę

systemctl daemon-reload

I włącz

systemctl enable tun2socks

Zanim uruchomisz usługę, zapewnij jej wirtualny interfejs sieciowy.

Przechodzimy do systemd-networkd

Włączamy systemd-networkd:

systemctl enable systemd-networkd

Wyłączamy obecne usługi sieciowe.

systemctl disable networking NetworkManager NetworkManager-wait-online

NetworkManager-wait-online — to usługa, która czeka na dostępność działającego połączenia sieciowego, zanim systemd zacznie uruchamiać inne usługi zależne od dostępu do sieci. Wyłączamy ją, ponieważ przechodzimy na analog systemd-networkd.

Od razu włączmy ją:

systemctl enable systemd-networkd-wait-online

Skonfiguruj interfejs sieciowy bezprzewodowy

Utwórz plik konfiguracyjny systemd-networkd dla interfejsu sieciowego bezprzewodowego /etc/systemd/network/25-wlp6s0.network.

[Match]
Name=wlp6s0

[Network]
Address=192.168.1.2/24
IPForward=yes

Nazwa — to nazwa twojego interfejsu bezprzewodowego. Zidentyfikuj go za pomocą polecenia ip a.
IPForward — dyrektywa umożliwiająca przekazywanie pakietów na interfejsie sieciowym.
Address jest odpowiedzialna za przypisywanie adresu IP interfejsowi bezprzewodowemu. Podajemy go statycznie, ponieważ w przypadku równoważnej dyrektywy DHCP=yes, systemd-networkd tworzy w systemie domyślną bramę. Wtedy cały ruch będzie kierowany przez oryginalną bramę, a nie przez przyszły wirtualny interfejs w innej podsieci. Możesz sprawdzić obecną bramę domyślną poleceniem ip r

Utwórz statyczną trasę dla zdalnego serwera SOCKS

Jeśli twój serwer SOCKS nie jest lokalny, a zdalny, musisz dla niego utworzyć statyczną trasę. W tym celu dodaj sekcję Route na końcu utworzonego przez ciebie pliku konfiguracyjnego interfejsu bezprzewodowego z następującą zawartością:

[Route]
Gateway=192.168.1.1
Destination=0.0.0.0

Gateway — to domyślna brama lub adres twojego oryginalnego punktu dostępowego.
Cel — adres serwera SOCKS.

Skonfiguruj wpa_supplicant dla systemd-networkd

systemd-networkd korzysta z wpa_supplicant do łączenia z zabezpieczonym punktem dostępu. Przy próbie 'uruchomienia' interfejsu bezprzewodowego systemd-networkd uruchamia usługę wpa_supplicant@nazwa, gdzie nazwa — to nazwa interfejsu bezprzewodowego. Jeśli do tej pory nie korzystałeś z systemd-networkd, zapewne ta usługa nie jest obecna w twoim systemie.

Dlatego stwórz ją poleceniem:

systemctl enable wpa_supplicant@wlp6s0

Użyłem wlp6s0 jako nazwę swojego interfejsu bezprzewodowego. Może ona się różnić. Możesz poznać jej nazwę za pomocą polecenia ip l.

Teraz utworzona usługa wpa_supplicant@wlp6s0 będzie uruchamiana przy "podnoszeniu" interfejsu bezprzewodowego, jednak w zamian będzie szukać ustawień SSID i hasła punktu dostępu w pliku /etc/wpa_supplicant/wpa_supplicant-wlp6s0. Dlatego konieczne jest jego utworzenie za pomocą narzędzia wpa_passphrase.

Aby to zrobić, wykonaj polecenie:

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

gdzie SSID to nazwa twojego punktu dostępu, password to hasło, a wlp6s0 to nazwa twojego interfejsu bezprzewodowego.

Zainicjuj wirtualny interfejs dla tun2socks

Utwórz plik do inicjacji nowego wirtualnego interfejsu w systemie/etc/systemd/network/25-tun2socks.netdev

[NetDev]
Name=tun2socks
Kind=tun

Nazwa to nazwa, którą systemd-networkd przypisze przyszłemu wirtualnemu interfejsowi podczas jego inicjalizacji.
Kind to typ wirtualnego interfejsu. Z nazwy usługi tun2socks możesz się domyślić, że używa ona interfejsu typu tun.
netdev to rozszerzenie plików, które systemd-networkd służy do inicjowania wirtualnych interfejsów sieciowych. Adres i inne ustawienia sieciowe dla tych interfejsów są podane w .network-plikach.

Utwórz taki plik /etc/systemd/network/25-tun2socks.network z następującą zawartością:

[Match]
Name=tun2socks

[Network]
Address=172.16.1.2/24
Gateway=172.16.1.1

Nazwa to nazwa wirtualnego interfejsu, którą podałeś w netdev-pliku.
Address to adres IP, który zostanie przypisany do wirtualnego interfejsu. Musi być w tej samej sieci co adres, który podałeś w usłudze tun2socks
Gateway to adres IP "routera" tun2socks, który podałeś przy tworzeniu usługi systemd.

W ten sposób interfejs tun2socks ma adres 172.16.1.2, a usługa tun2socks — 172.16.1.1, to jest bramą dla wszystkich połączeń z wirtualnego interfejsu.

Skonfiguruj wirtualny punkt dostępu

Zainstaluj zależności:

apt install util-linux procps hostapd iw haveged

Pobierz repozytorium create_ap na swoją maszynę:

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

Przejdź do folderu repozytorium na swojej maszynie:

cd create_ap

Zainstaluj w systemie:

make install

W twoim systemie pojawi się plik konfiguracyjny /etc/create_ap.conf. Oto główne opcje do edycji:

GATEWAY=10.0.0.1 lepiej zrobić to jako oddzielną zarezerwowaną podsieć.
NO_DNS=1 wyłącz, ponieważ ten parametr będzie kontrolowany przez wirtualny interfejs systemd-networkd.
NO_DNSMASQ=1 wyłącz z tej samej przyczyny.
WIFI_IFACE=wlp6s0 to interfejs bezprzewodowy laptopa.
INTERNET_IFACE=tun2socks to wirtualny interfejs stworzony dla tun2socks.
SSID=hostapd to nazwa wirtualnego punktu dostępu.
PASSPHRASE=12345678 to hasło.

Nie zapomnij włączyć usługi:

systemctl enable create_ap

Włącz serwer DHCP w systemd-networkd

Usługa create_ap inicjalizuje w systemie wirtualny interfejs ap0. Teoretycznie, w tym interfejsie działa dnsmasq, ale po co instalować dodatkowe usługi, skoro systemd-networkd zawiera wbudowany serwer DHCP?

Aby go włączyć, zdefiniujmy ustawienia sieci dla wirtualnego punktu dostępu. W tym celu utwórz plik /etc/systemd/network/25-ap0.network z następującą zawartością:

[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

Po tym, jak usługa create_ap zainicjuje wirtualny interfejs ap0, systemd-networkd automatycznie przypisze mu adres IP i włączy serwer DHCP.

Linie EmitDNS=yes i DNS=10.0.0.1 przekazują ustawienia serwera DNS urządzeniom podłączonym do punktu dostępu.

Jeśli nie planujesz używać lokalnego serwera DNS — w moim przypadku jest to dnscrypt-proxy — możesz ustawić DNS=10.0.0.1 do DNS=192.168.1.1, gdzie 192.168.1.1 — adres twojego pierwotnego bramy. W takim przypadku zapytania DNS twojego hosta i lokalnej sieci będą przesyłane w nieszyfrowanej formie przez serwery dostawcy.

EmitNTP=yes i NTP=192.168.1.1 przekazują ustawienia NTP.

To samo dotyczy wiersza NTP=10.0.0.1.

Zainstaluj i skonfiguruj serwer NTP

Zainstaluj w systemie:

apt install ntp

Edytuj konfigurację /etc/ntp.conf. Skomentuj adresy standardowych pul:

#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

Dodaj adresy publicznych serwerów, na przykład Google Public NTP:

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

Zapewnij dostęp do serwera klientom w twojej sieci:

restrict 10.0.0.0 mask 255.255.255.0

Włącz broadcast w twojej sieci:

broadcast 10.0.0.255

Na koniec dodaj adresy tych serwerów do tabeli statycznego routingu. W tym celu otwórz plik konfiguracyjny interfejsu bezprzewodowego /etc/systemd/network/25-wlp6s0.network i dodaj na końcu sekcji 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

Możesz dowiedzieć się o adresach swoich serwerów NTP, używając narzędzia Najciekawsza linia — ostatnia. w następujący sposób:

host time1.google.com

Zainstaluj dnscrypt-proxy, usuń reklamy i ukryj ruch DNS przed dostawcą

apt install dnscrypt-proxy

Aby obsługiwać zapytania DNS hosta i sieci lokalnej, edytuj socket /lib/systemd/system/dnscrypt-proxy.socket. Zmień następujące linie:

ListenStream=0.0.0.0:53
ListenDatagram=0.0.0.0:53

Uruchom ponownie systemd:

systemctl daemon-reload

Edytuj konfigurację /etc/dnscrypt-proxy/dnscrypt-proxy.toml:

server_names = ['adguard-dns']

Aby skierować połączenia dnscrypt-proxy przez tun2socks, dodaj poniżej:

force_tcp = true

Edytuj konfigurację /etc/resolv.conf, co informuje serwer DNS o hoście.

nameserver 127.0.0.1
nameserver 192.168.1.1

Pierwsza linia włącza użycie dnscrypt-proxy, druga — korzysta z pierwotnej bramy, w przypadku, gdy serwer dnscrypt-proxy jest niedostępny.

Gotowe!

Zrestartuj lub zatrzymaj działające usługi sieciowe:

systemctl stop networking NetworkManager NetworkManager-wait-online

I uruchom ponownie wszystkie potrzebne:

systemctl restart systemd-networkd tun2socks create_ap dnscrypt-proxy ntp

Po ponownym uruchomieniu lub restarcie pojawi się drugi punkt dostępu, który kieruje hosta i urządzenia sieci lokalnej do SOCKS.

Tak wygląda wyjście ip a zwykłego laptopa:

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

W konsekwencji,

Dostawca widzi tylko zaszyfrowane połączenie z twoim serwerem SOCKS, co oznacza, że nic nie widzi.
Jednak widzi twoje zapytania NTP, aby temu zapobiec, usuń statyczne trasy do serwerów NTP. Jednak nie ma pewności, że twój serwer SOCKS obsługuje protokół NTP.

Obejście zauważone w Debain 10

Jeśli spróbujesz ponownie uruchomić usługę sieciową z konsoli, zakończy się to błędem. Jest to związane z tym, że jej część w postaci wirtualnego interfejsu jest powiązana z usługą tun2socks, co oznacza, że jest używana. Aby ponownie uruchomić usługę sieciową, najpierw trzeba zatrzymać usługę tun2socks. Ale myślę, że jeśli dotarłeś do końca, to na pewno nie jest to dla ciebie problem!