W architekturze Split-Tunneling (dzielonego tunelowania)<\/strong> Raspberry Pi pe\u0142ni funkcj\u0119 utwardzonej bramy bezpiecze\u0144stwa. Zamiast kierowa\u0107 ca\u0142y ruch internetowy klienta przez sie\u0107 domow\u0105 \u2013 co ogranicza pr\u0119dko\u015b\u0107 po\u0142\u0105cze\u0144 mobilnych \u2013 tunel selektywnie przesy\u0142a tylko okre\u015blone podsieci docelowe (np. wewn\u0119trzne zasoby laboratorium domowego w adresacji W celu umo\u017cliwienia przekazywania pakiet\u00f3w pomi\u0119dzy fizycznym interfejsem sieciowym ( Zastosowanie zmodyfikowanych parametr\u00f3w j\u0105dra natychmiast bez konieczno\u015bci restartu hosta:<\/p>\n Instalacja narz\u0119dzi j\u0105drowych WireGuard oraz generowanie pary kluczy publicznych i prywatnych z rygorystycznymi uprawnieniami w systemie plik\u00f3w:<\/p>\n G\u0142\u00f3wny plik konfiguracyjny definiuje port nas\u0142uchu serwera, alokacj\u0119 podsieci oraz zintegrowane regu\u0142y zapory sieciowej. Stosowany jest domy\u015blny port UDP WireGuard ( Na urz\u0105dzeniu zdalnym parametr Po uruchomieniu us\u0142ugi systemd poleceniem Co da si\u0119 osi\u0105gn\u0105\u0107 dzi\u0119ki instrukcji:<\/strong> Wdro\u017cenie utwardzonej bramy VPN WireGuard dzia\u0142aj\u0105cej w przestrzeni j\u0105dra systemu na platformie Raspberry Pi z selektywnym tunelowaniem dzielonym i automatycznym maskowaniem zapory sieciowej.<\/p>\n Resultuj\u0105cy warto\u015b\u0107 dodana:<\/strong><\/p>\n Raczej nie. WireGuard nie odpowiada na \u017caden pakiet, kt\u00f3ry nie niesie wa\u017cnego uzgodnienia po\u0142\u0105czenia (handshake) ze znanym kluczem, wi\u0119c skan port\u00f3w nie odr\u00f3\u017cni tego portu od filtrowanego, niezale\u017cnie od jego numeru. Utwardzenie polega na milczeniu protoko\u0142u, a nie na numerze portu, a 51820 i tak jest zwyk\u0142ym domy\u015blnym portem WireGuard.<\/p>\n Tak, bo Split-Tunneling to decyzja klienta. AllowedIPs po stronie klienta okre\u015bla tylko, kt\u00f3re cele trafiaj\u0105 do tunelu. Je\u015bli klient wpisze tam 0.0.0.0\/0, ca\u0142y jego ruch trafi do Raspberry Pi, a ten przeka\u017ce go dalej: przekazywanie pakiet\u00f3w jest w\u0142\u0105czone, a regu\u0142a maskowania obejmuje wszystko, co opuszcza eth0, tak\u017ce drog\u0119 do internetu.<\/p>\n Na bramie konfiguracja ogranicza jedynie adres \u017ar\u00f3d\u0142owy: AllowedIPs = 10.100.0.2\/32 w pliku serwera oznacza, \u017ce od tego peera przyjmowane s\u0105 tylko pakiety z tym adresem \u017ar\u00f3d\u0142owym. O celach ta linia nic nie m\u00f3wi.<\/p>\n Je\u015bli brama ma wymusza\u0107 Split-Tunneling, potrzebny jest \u0142a\u0144cuch filtruj\u0105cy na haku forward: przepuszcza\u0107 ruch z wg0 do sieci domowej 192.168.10.0\/24 oraz odpowiedzi na nawi\u0105zane po\u0142\u0105czenia, a ca\u0142\u0105 reszt\u0119 z wg0 odrzuca\u0107. Tabela rodziny inet obejmuje przy tym IPv4 i IPv6 w jednym \u0142a\u0144cuchu.<\/p>\n Przestaje dzia\u0142a\u0107 razem z nim. Przy DNS = 192.168.10.1 klient pyta serwer w sieci domowej, a ten adres le\u017cy w AllowedIPs. Ka\u017cde zapytanie o nazw\u0119 idzie wi\u0119c przez tunel, tak\u017ce o strony, kt\u00f3rych ruch poza tym p\u0142ynie bezpo\u015brednio do internetu. Gdy brama jest nieosi\u0105galna, og\u00f3lny ruch wprawdzie p\u0142ynie dalej bezpo\u015brednio, ale \u017cadna nazwa nie zostaje ju\u017c rozwi\u0105zana, a dla osoby korzystaj\u0105cej z urz\u0105dzenia wygl\u0105da to jak ca\u0142kowita awaria.<\/p>\n Drugie ograniczenie dotyczy sieci, w kt\u00f3rej klient akurat si\u0119 znajduje. Je\u015bli sie\u0107 hotelowa albo sie\u0107 dla go\u015bci sama u\u017cywa 192.168.10.0\/24, o te same adresy konkuruj\u0105 dwie trasy i zale\u017cnie od routingu klient nie osi\u0105gnie albo sieci domowej, albo lokalnej bramy. Mniej rozpowszechniona podsie\u0107 dla sieci domowej zmniejsza to ryzyko.<\/p>\n<\/div>\n Techniczny przewodnik po wdro\u017ceniu bezpiecznej, wysokowydajnej bramy VPN WireGuard na Raspberry Pi z selektywnym tunelowaniem dzielonym i zapor\u0105 nftables.<\/p>\n","protected":false},"author":1,"featured_media":14087,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[92634],"tags":[92370,92373,92223,92238,92448,92487],"class_list":["post-535","post","type-post","status-publish","format-standard","hentry","category-tutorials-pl-raspberry-pi-pl","tag-firewall-pl","tag-network-security-pl","tag-raspberry-pi-pl","tag-tutorial-pl","tag-vpn-pl","tag-wireguard-pl"],"yoast_head":"\n192.168.10.0\/24<\/code>) przez zaszyfrowany interfejs WireGuard. Analogicznie, brama mo\u017ce zosta\u0107 skonfigurowana do szyfrowania wybranych urz\u0105dze\u0144 w sieci lokalnej za po\u015brednictwem zewn\u0119trznego dostawcy VPN, pozostawiaj\u0105c pozosta\u0142y ruch LAN bez zmian.<\/p>\n![\"Routing](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/wireguard-split-tunnel-brama-pl.png\")
wg0<\/code> przechodz\u0105 wy\u0142\u0105cznie dwie sieci wymienione w AllowedIPs<\/code>. Brama przekazuje je na poziomie j\u0105dra i maskuje na eth0<\/code>; pozosta\u0142y ruch opuszcza klienta bezpo\u015brednio.<\/figcaption><\/figure>\nInstrukcja wdro\u017cenia krok po kroku<\/h2>\n
Krok 1: W\u0142\u0105czenie przekazywania pakiet\u00f3w w j\u0105drze Linux (IP Forwarding)<\/h3>\n
eth0<\/code>) a wirtualnym interfejsem WireGuard (wg0<\/code>), konieczne jest trwa\u0142e aktywowanie przekazywania ruchu IPv4 i IPv6 w konfiguracji j\u0105dra:<\/p>\n# \/etc\/sysctl.d\/99-wireguard-forwarding.conf\nnet.ipv4.ip_forward = 1\nnet.ipv6.conf.all.forwarding = 1\nnet.ipv4.conf.all.rp_filter = 1\nnet.ipv4.conf.default.rp_filter = 1<\/code><\/pre>\nsysctl --system<\/code><\/pre>\nKrok 2: Generowanie kluczy kryptograficznych i instalacja pakiet\u00f3w<\/h3>\n
apt update && apt install -y wireguard wireguard-tools nftables\nmkdir -p \/etc\/wireguard && cd \/etc\/wireguard\nchmod 700 \/etc\/wireguard\nwg genkey | tee server_private.key | wg pubkey > server_public.key\nchmod 600 server_private.key<\/code><\/pre>\nKrok 3: Konfiguracja utwardzonego interfejsu serwera (wg0.conf)<\/h3>\n
51820<\/code>) w po\u0142\u0105czeniu z rygorystycznymi regu\u0142ami maskowania nftables<\/code>:<\/p>\n# \/etc\/wireguard\/wg0.conf\n[Interface]\nAddress = 10.100.0.1\/24\nListenPort = 51820\nPrivateKey = <SERVER_PRIVATE_KEY>\n\n# Automatyczne maskowanie zapory sieciowej za pomoc\u0105 nftables\nPostUp = nft add table ip wireguard; nft add chain ip wireguard nat { type nat hook postrouting priority 100\\; policy accept\\; }; nft add rule ip wireguard nat oifname \"eth0\" masquerade\nPostDown = nft delete table ip wireguard\n\n# Przyk\u0142adowa konfiguracja klienta (Peer) w trybie Split-Tunnel\n[Peer]\nPublicKey = <CLIENT_PUBLIC_KEY>\nAllowedIPs = 10.100.0.2\/32<\/code><\/pre>\nKrok 4: Konfiguracja routingu Split-Tunnel na urz\u0105dzeniu klienta<\/h3>\n
AllowedIPs<\/code> decyduje o tym, czy po\u0142\u0105czenie dzia\u0142a jako pe\u0142ny tunel, czy tunel dzielony. Ustawienie warto\u015bci AllowedIPs = 192.168.10.0\/24, 10.100.0.0\/24<\/code> wymusza przesy\u0142anie przez zaszyfrowany tunel wy\u0142\u0105cznie pakiet\u00f3w skierowanych do sieci domowej, podczas gdy publiczne przegl\u0105danie stron internetowych odbywa si\u0119 bezpo\u015brednio przez lokalne \u0142\u0105cze klienta:<\/p>\n# Konfiguracja po stronie klienta (Tryb Split-Tunneling)\n[Interface]\nPrivateKey = <CLIENT_PRIVATE_KEY>\nAddress = 10.100.0.2\/24\nDNS = 192.168.10.1\n\n[Peer]\nPublicKey = <SERVER_PUBLIC_KEY>\nEndpoint = vpn.lukaswojcik.com:51820\nAllowedIPs = 192.168.10.0\/24, 10.100.0.0\/24\nPersistentKeepalive = 25<\/code><\/pre>\nKrok 5: Kontrola jako\u015bci i walidacja przepustowo\u015bci<\/h3>\n
systemctl enable --now wg-quick@wg0<\/code>, weryfikacj\u0119 infrastruktury nale\u017cy przeprowadzi\u0107 w oparciu o trzy etapy diagnostyczne:<\/p>\n\n
wg show wg0<\/code> w terminalu Raspberry Pi w celu potwierdzenia obecno\u015bci aktualnych znacznik\u00f3w czasu (handshake) i statystyk transferu dla aktywnych klient\u00f3w.<\/li>\nip route show<\/code>), co pozwala upewni\u0107 si\u0119, \u017ce domy\u015blna brama internetowa pozostaje niezmieniona, a trasy statyczne dla 192.168.10.0\/24<\/code> kieruj\u0105 ruch \u015bci\u015ble na interfejs wg0<\/code>.<\/li>\niperf3<\/code> pomi\u0119dzy zdalnym klientem a serwerem w sieci domowej w celu sprawdzenia, czy transfer osi\u0105ga maksymalne nasycenie \u0142\u0105cza bez fragmentacji pakiet\u00f3w.<\/li>\n<\/ol>\nPodsumowanie i mierzalna warto\u015b\u0107 dodana<\/h2>\n
\n
Pytania i odpowiedzi<\/h2>\n
Czy port UDP inny ni\u017c 51820 czyni bram\u0119 mniej widoczn\u0105 dla skan\u00f3w?<\/h3>\n
Czy klient mo\u017ce obej\u015b\u0107 Split-Tunneling i wysy\u0142a\u0107 ca\u0142y sw\u00f3j ruch przez sie\u0107 domow\u0105?<\/h3>\n
Co dzieje si\u0119 z rozwi\u0105zywaniem nazw na kliencie, gdy tunel przestaje dzia\u0142a\u0107?<\/h3>\n
\u0179r\u00f3d\u0142a<\/h2>\n
\n