WireGuard opdelt tunnel: sæt den op uden en standardrute

En opdelt tunnel er den præfikseliste, du udelader. Læg fjernområderne på klientens peer, klientens adresse på serverens peer, og læs derefter ruterne.

En opdelt tunnel defineres af det, du udelader, og WireGuard træffer den beslutning i ét felt. AllowedIPs på klientens peer vælger på samme tid, hvilke destinationer der går gennem tunnelen, og filtrerer, hvilke indre kildeadresser der accepteres, og wg-quick omdanner den samme liste til værtsruter. Tager du fejl af listen, sluger tunnelen enten alt eller bærer intet.

Fastlæg præfikselisten først

Skriv de destinationer ned, der skal bruge tunnelen, før du rører en konfigurationsfil. Kontorundernet, et databaseområde, et administrationsnetværk: hver er et præfiks med en grund. Alt, der ikke står på listen, bliver på den fysiske vej, og det er hele pointen med designet.

Hvis listen indeholder 0.0.0.0/0 eller ::/0, har du bygget en fuld tunnel og bør sige det, fordi fejltilstandene og DNS-forventningerne er anderledes.

Hold listen kort nok til, at en anmelder senere kan kontrollere den mod rutetabellen.

Klientkonfiguration: peer, AllowedIPs, DNS

Klientens interfaceblok indeholder dens egen tunneladresse og private nøgle. Peerblokken indeholder serverens offentlige nøgle, endpoint og præfikserne fra første trin:

[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 på klienten er sættet af fjern destinationer, ikke klientens egen adresse. DNS-linjen virker kun gennem wg-quicks resolverintegration, så en vært uden understøttelse af resolvconf eller systemd-resolved ignorerer den. PersistentKeepalive holder en NAT-mapping i live og er unødvendig på en direkte vej.

Kommenter hvert præfiks med den tjeneste, det betjener, ellers bliver næste redigering gætteri.

Serverkonfiguration: det modsatte synspunkt

På serveren repræsenterer peerposten klienten, så dens AllowedIPs er klientens tunneladresse, normalt en /32. Det er ikke kontorundernet. At kopiere klientens liste ind i serverposten er den mest almindelige fejl ved opdelt tunnel, og den udvider enten adgangen eller ødelægger den indre kildekontrol ved håndtrykket.

Serverens egen interfaceadresse og de ruter, den har brug for mod kontoret, er adskilt fra enhver peerpost.

To filer, to synspunkter, ét sæt præfikser delt mellem dem.

Bring den op og læs ruterne

Start interfacet med den understøttede håndtering og se derefter på, hvad den installerede, i stedet for hvad du havde tænkt. wg-quick udleder ruter fra AllowedIPs; hvis profilen sætter Table = off, installeres intet, og routing er dit ansvar. Læs ruten for hvert præfiks, og bekræft at den peger på WireGuard-interfacet. En tom ruteliste betyder normalt, at den anvendte profil ikke er den, du redigerede.

Tjek også håndtrykstællerne, fordi en peer uden håndtryk har et nøgle-, endpoint- eller tilgængelighedsproblem snarere end et routingproblem.

Skriv den præcise kommando ned, du brugte, fordi den næste person kører den under pres.

Verificer begge sider, og noter derefter tilbagerulningen

Test en privat adresse, dens interne navn og en destination, der skal forblive direkte. Hvis den private adresse virker, og den direkte nu forlader gennem tunnelen, er præfikselisten for bred. Hvis navnet fejler, mens adressen virker, trådte DNS-linjen ikke i kraft. Tilbagerulning er én kommando, og den hører i samme note.

Efter en genopkobling skal du bekræfte, at ruterne stadig er der, fordi en håndtering, der anvender profilen igen, kan erstatte manuelle ruter.

Hold én konfigurationsejer, fordi to håndteringer, der producerer samme interface, før eller siden bliver uenige. wg-quick-manualen dokumenterer den rute- og DNS-adfærd, den leverer.

Relaterede artikler