Hoe je één website buiten je WireGuard-tunnel leidt
Eén /32-route via de LAN-gateway houdt één site op je normale verbinding, mits de firewall het toestaat en DNS het over het adres eens is.
Een hostnaam uitsluiten is iets wat een tunnel niet kan. Een route kan echter één adres langs de tunnel en via de thuisgateway naar buiten sturen, en dat is meestal genoeg voor één site. De complicatie is dat alles stroomafwaarts van de route het eens moet zijn: de firewall moet het pakket doorlaten, DNS moet het adres teruggeven dat je hebt gerouteerd, en de site moet dat adres blijven gebruiken. Wanneer een van de drie afwijkt, houdt de uitzondering op te werken zonder zich aan te kondigen.
Lees het bestemmingsadres voordat je de tunnel aanraakt
Laad de site één keer met de tunnel actief en kijk dan naar het peeradres waarmee de browser werkelijk verbinding maakte. Op Linux, ss -tunp toont de externe adressen voor elke open socket, en dig +short op dezelfde naam laat zien wat de resolver teruggaf. Houd beide getallen voor je.
De twee antwoorden kloppen vaak niet, en dat verschil is het hele probleem. Grote sites zetten een contentnetwerk voor hun oorsprong, dus het adres dat je resolver nu teruggeeft is misschien niet het adres dat de browser een minuut geleden gebruikte. Routeer wat je op de socket zag, niet wat een oudere gids opsomt. Als de antwoorden tussen regio's blijven roteren, is een adresuitzondering het verkeerde middel voor die specifieke site.
Voer de opzoeking een tweede keer uit vanaf een ander netwerk en noteer het IPv6-antwoord samen met het IPv4-antwoord. Een tunnel die beide families draagt, heeft in beide een uitzondering nodig, anders valt de browser stil terug op het IPv6-pad dat je nooit hebt aangeraakt. Schrijf de adressen en de datum ergens op waar je weer kijkt.
Zet één hostroute op de client
Stel dat de interface home-wg heet en dat de LAN-router op 192.168.1.1 staat. NetworkManager neemt een route waarvan de gateway die router is en waarvan de prefixlengte alle 32 bits dekt, en de kernel geeft er de voorkeur aan omdat de langste prefix wint.
nmcli connection modify home-wg +ipv4.routes "198.51.100.20/32 192.168.1.1"
nmcli connection up home-wg
ip route get 198.51.100.20
De gateway moet bereikbaar zijn zonder de tunnel; de volgende hop naar het tunneladres wijzen ondermijnt het doel, omdat het pakket weer de interface in zou gaan die je probeert te vermijden. Nadat de verbinding weer omhoog is, ip route get zou voor de uitzondering de LAN-gateway moeten worden afgedrukt, en hetzelfde commando voor een publieke resolver zou nog steeds het tunnelapparaat moeten afdrukken.
Een wg-quick-profiel heeft geen routeveld, dus dezelfde uitzondering leeft in een PostUp -regel die de hostroute met de LAN-interface als apparaat aan de hoofdtabel toevoegt. Haal de interface na het bewerken omlaag en weer omhoog, omdat een draaiende interface zijn bestand nooit opnieuw leest. De fwmark-regels die wg-quick installeert, sturen alleen zijn eigen ingekapselde pakketten, dus gewoon browserverkeer volgt nog steeds de hoofdtabel en vindt je /32.
De kill switch is het volgende dat het blokkeert
Een firewallbeleid dat alleen verkeer op de tunnelinterface toestaat, zal de uitzondering laten vallen, ook als de route precies goed is. Lees de regels achter de schakelaar in plaats van de schakelaar te vertrouwen, want degene die een kill switch implementeren zijn meestal beperkt tot een interfacenaam.
Wat je wilt is een smalle toestemming voor de fysieke interface en dat ene doel, geplaatst vóór de drop, terwijl het standaardbeleid onaangeroerd blijft. De kill switch helemaal pauzeren bewijst het punt, maar laat de machine ook openstaan zolang je vergeet hem weer aan te zetten.
Test de twee richtingen apart. Een verzoek naar het uitzonderingsadres zou moeten slagen, terwijl een verzoek naar een niet-gerelateerde site nog steeds door de tunnel naar buiten gaat. Als beide slagen maar de tweede het thuisadres meldt, dan is de volgorde van de firewallregels fout, niet de route.
DNS bepaalt welk adres de browser kiest
Wanneer de naam binnen de tunnel wordt opgelost, kan de resolver van de provider een ander adres antwoorden dan de lokale. Je route geldt dan voor een adres dat de browser nooit contacteert, en de pagina laadt via de tunnel alsof er niets is veranderd. Deze storing ziet eruit als een kapotte uitzondering, ook al is de routetabel correct.
Stuur de queries van die naam ook via de lokale resolver, of sla namen helemaal over en test het adres rechtstreeks. Het adres splitsen terwijl DNS in de tunnel blijft, is de meest voorkomende half afgemaakte versie van deze opzet, en het is ook het moeilijkst te merken, omdat de site blijft werken, alleen niet zoals je bedoelde.
Dezelfde uitzondering op de router, één keer, voor elk apparaat
Als de tunnel op de router draait, hoort de hostroute in de beleidsroutingtabel van de router en wijst die naar de WAN-gateway in plaats van de LAN-gateway. Elk apparaat erachter erft de uitzondering, wat uitmaakt voor een streamingbox of een werklaptop waarvan je de netwerkinstellingen niet kunt wijzigen.
Laat de tunnel de standaarduitgang zijn voor elke andere client en controleer daarna vanaf een clientmachine, niet vanaf de routerconsole. Laad de uitzonderingssite en een tweede site in dezelfde browsersessie en vergelijk de uitgangsadressen; als de tweede nog steeds de tunnel toont, doet de beleidstabel wat je vroeg.
Schrijf het adres, de datum en de reden in de notities van de router. Een uitzondering rond een adres dat later verhuist, wordt een fout die niemand over een jaar kan verklaren, en de oplossing lijkt altijd een raadsel tot iemand de oude notitie vindt.