WireGuard opgedeilten Tunnel: astellen ouni Standardroute

En opgedeilten Tunnel gëtt duerch dat definéiert, wat Dir ewech loosst, an WireGuard hëlt déi Entscheedung an engem eenzegen Feld. D'AllowedIPs vum Client-Peer wielt gläichzäiteg, wéi eng Destinatiounen duerch den Tunnel ginn, a filtert, wéi eng intern Quelladressen akzeptéiert ginn, an wg-quick mécht déiselwecht Lëscht zu Host-Routen. Wann d'Lëscht falsch ass, schléckt den Tunnel alles oder dréit näischt.

Bestëmmt als éischt d'Präfixlëscht

Schreift d'Destinatiounen op, déi den Tunnel musse benotzen, ier Dir eng Konfiguratiounsdatei beréiert. Büro-Subnetzer, e Datebank-Beräich, en Administratiounsnetz: all ass e Präfix mat engem Grond. Alles, wat net op der Lëscht steet, bleift um physesche Wee, an dat ass de ganzen Zweck vum Design.

Wann d'Lëscht 0.0.0.0/0 oder ::/0 enthält, hutt Dir en vollstännegen Tunnel gebaut a sollt dat soen, well d'Feelermodusen an d'DNS-Erwaardungen ënnerschiddlech sinn.

Halt d'Lëscht kuerz genuch, datt en Iwwerpréifer se spéider mat der Routentabell vergläiche kann.

Client-Konfiguratioun: Peer, AllowedIPs, DNS

Den Interface-Block vum Client enthält seng eege Tunneladress an de private Schlëssel. Den Peer-Block enthält de ëffentleche Schlëssel vum Server, den Endpunkt an d'Präfixe vum éischte Schrëtt:

[Interface]
Address = 10.9.0.2/32
PrivateKey = <client-private-key>
DNS = 10.20.0.53

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16, 10.30.0.0/24
PersistentKeepalive = 25

AllowedIPs um Client ass de Set vun de wäiten Destinatiounen, net d'Adress vum Client selwer. D'DNS-Linn wierkt nëmmen iwwer d'Resolver-Integratioun vu wg-quick, dofir ignoréiert en Host ouni Ënnerstëtzung fir resolvconf oder systemd-resolved se. PersistentKeepalive hält eng NAT-Mapping lieweg an ass op engem direkte Wee iwwerflësseg.

Kommentéiert all Präfix mat dem Service, deem en déngt, soss ass déi nächst Ännerung eng Vermutung.

Server-Konfiguratioun: déi entgéintgesate Siicht

Um Server representéiert den Peer-Andrag de Client, dofir ass seng AllowedIPs d'Tunneladress vum Client, meeschtens eng /32. Et ass net de Büro-Subnet. D'Lëscht vum Client an den Server-Andrag ze kopéieren ass dee heefegste Feeler beim opgedeilten Tunnel, an et erweidert den Zougang oder brécht d'intern Quellpréifung beim Handshake.

D'Interface-Adress vum Server selwer, an d'Routen, déi en a Richtung Büro brauch, sinn getrennt vun all Peer-Andrag.

Zwee Dateien, zwou Siichten, ee Set Präfixen tëscht hinnen opgedeelt.

Hieft en erop a liest d'Routen

Start den Interface mat dem ënnerstëtzte Manager an dann kuckt, wat en installéiert huet, net wat Dir virgesinn hutt. wg-quick leet Routen aus AllowedIPs of; wann de Profil Table = off setzt, gëtt näischt installéiert an d'Routing ass Är Saach. Liest d'Route fir all Präfix a bestätegt, datt se op den WireGuard-Interface weist. Eng eidel Routelëscht bedeit meeschtens, datt de Profil, deen ugewannt gouf, net deen ass, deen Dir geännert hutt.

Kuckt och d'Handshake-Zähler, well en Peer ouni Handshake huet e Schlëssel-, Endpunkt- oder Erreechbarkeetsproblem, keen Routingproblem.

Schreift de geneeë Kommando op, deen Dir benotzt hutt, well déi nächst Persoun wäert en ënner Drock ausféieren.

Iwwerpréift béid Säiten, dann notéiert de Réckzuch

Test eng privat Adress, hiren internen Numm an eng Destinatioun, déi direkt musse bleiwen. Wann déi privat Adress funktionéiert an déi direkt elo duerch den Tunnel erausgeet, ass d'Präfixlëscht ze breet. Wann den Numm feelt, während d'Adress funktionéiert, ass d'DNS-Linn net a Kraaft getrueden. De Réckzuch ass ee Kommando, an en gehéiert an déiselwecht Notiz.

No enger Neiverbindung bestätegt, datt d'Routen nach do sinn, well e Manager, deen de Profil nei uwennt, manuell Routen ersetze kann.

Halt een eenzegen Konfiguratiounsbesëtzer, well zwee Manager, déi deeselwechten Interface produzéieren, wäerten sech schlussendlech widerspriechen. Den wg-quick-Handbuch dokumentéiert d'Route- an DNS-Verhalen, dat en ubitt.