Een gesplitste tunnel wordt bepaald door wat u weglaat, en WireGuard neemt die beslissing in één veld. De AllowedIPs van de client-peer kiest tegelijk welke bestemmingen door de tunnel gaan en filtert welke interne bronadressen worden geaccepteerd, en wg-quick maakt dezelfde lijst tot hostroutes. Is de lijst verkeerd, dan slikt de tunnel alles in of draagt hij niets.

Bepaal eerst de prefixlijst

Schrijf de bestemmingen op die de tunnel moeten gebruiken voordat u een configuratiebestand aanraakt. Kantoorsubnetten, een databasereeks, een beheernetwerk: elk is een prefix met een reden. Alles wat niet op de lijst staat, blijft op het fysieke pad, en dat is het hele punt van het ontwerp.

Als de lijst 0.0.0.0/0 of ::/0 bevat, hebt u een volledige tunnel gebouwd en moet u dat zeggen, want de faalmodi en DNS-verwachtingen verschillen.

Houd de lijst kort genoeg zodat een controleur hem later tegen de routetabel kan leggen.

Clientconfiguratie: peer, AllowedIPs, DNS

Het interfaceblok van de client bevat zijn eigen tunneladres en privésleutel. Het peerblok bevat de publieke sleutel van de server, het eindpunt en de prefixes van stap één:

[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 op de client is de verzameling externe bestemmingen, niet het eigen adres van de client. De DNS-regel werkt alleen via de resolverintegratie van wg-quick, dus een host zonder ondersteuning voor resolvconf of systemd-resolved negeert hem. PersistentKeepalive houdt een NAT-mapping in leven en is overbodig op een direct pad.

Becommentarieer elke prefix met de dienst die hij dient, anders is de volgende wijziging giswerk.

Serverconfiguratie: het tegenovergestelde gezichtspunt

Op de server vertegenwoordigt de peer-regel de client, dus zijn AllowedIPs is het tunneladres van de client, meestal een /32. Dat is niet het kantoorsubnet. De lijst van de client naar de server-regel kopiëren is de meest voorkomende fout bij een gesplitste tunnel, en hij verbreedt de toegang of breekt de interne broncontrole bij de handshake.

Het eigen interfaceadres van de server en de routes die hij naar het kantoor nodig heeft, staan los van elke peer-regel.

Twee bestanden, twee gezichtspunten, één set prefixes tussen beide verdeeld.

Breng hem op en lees de routes

Start de interface met de ondersteunde beheerder en kijk dan wat hij heeft geïnstalleerd, niet wat u bedoelde. wg-quick leidt routes af uit AllowedIPs; als het profiel Table = off zet, wordt niets geïnstalleerd en is de routering aan u. Lees de route voor elke prefix en bevestig dat hij naar de WireGuard-interface wijst. Een lege routelijst betekent meestal dat het toegepaste profiel niet het profiel is dat u hebt bewerkt.

Controleer ook de handshake-tellers, want een peer zonder handshake heeft een sleutel-, eindpunt- of bereikbaarheidsprobleem, geen routeringsprobleem.

Schrijf het exacte commando op dat u gebruikte, want de volgende persoon voert het onder druk uit.

Controleer beide kanten en leg dan de terugrol vast

Test een privéadres, de interne naam ervan en een bestemming die direct moet blijven. Als het privéadres werkt en de directe bestemming nu via de tunnel vertrekt, is de prefixlijst te breed. Als de naam faalt terwijl het adres werkt, heeft de DNS-regel geen effect gehad. Terugrollen is één commando, en het hoort in dezelfde notitie.

Bevestig na een herverbinding dat de routes er nog zijn, want een beheerder die het profiel opnieuw toepast, kan handmatige routes vervangen.

Houd één configuratie-eigenaar, want twee beheerders die dezelfde interface produceren, zullen het uiteindelijk oneens worden. De wg-quick-handleiding documenteert het route- en DNS-gedrag dat hij biedt.

Gerelateerde artikelen