Cum să direcționezi un singur site în afara tunelului WireGuard

A exclude un nume de gazdă este ceva ce un tunel nu poate face. O rută însă poate trimite o singură adresă pe lângă tunel și afară prin gateway-ul de acasă, iar pentru un singur site de obicei este suficient. Problema este că tot ce se află în aval de rută trebuie să fie de acord: firewall-ul trebuie să lase pachetul să iasă, DNS-ul trebuie să returneze adresa pe care ai direcționat-o, iar site-ul trebuie să continue să folosească acea adresă. Când oricare dintre cele trei derivează, excepția încetează să mai funcționeze fără să anunțe.

Citește adresa de destinație înainte să atingi tunelul

Încarcă site-ul o dată cu tunelul activ, apoi uită-te la adresa perechii cu care browserul s-a conectat de fapt. Pe Linux, ss -tunp listează adresa la distanță pentru fiecare socket deschis, iar dig +short pe același nume arată ce a returnat resolver-ul. Ține ambele numere în fața ta.

Cele două răspunsuri nu coincid des, iar această nepotrivire este toată problema. Site-urile mari pun o rețea de conținut în fața originii lor, așa că adresa pe care resolver-ul o returnează acum poate să nu fie cea pe care browserul a folosit-o acum un minut. Direcționează ce ai observat pe socket, nu ce listează un ghid mai vechi. Dacă răspunsurile continuă să se rotească între regiuni, o excepție de adresă este instrumentul greșit pentru acel site anume.

Rulează căutarea a doua oară din altă rețea și notează răspunsul IPv6 împreună cu cel IPv4. Un tunel care transportă ambele familii are nevoie de o excepție în amândouă, altfel browserul revine în tăcere pe calea IPv6 pe care nu ai atins-o niciodată. Notează adresele și data undeva unde vei mai privi.

Pune o rută de gazdă pe client

Să presupunem că interfața se numește home-wg și că routerul LAN stă la 192.168.1.1. NetworkManager preia o rută al cărei gateway este acel router și a cărei lungime de prefix acoperă toți cei 32 de biți, iar kernelul o preferă pentru că prefixul cel mai lung câștigă.

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

Gateway-ul trebuie să fie accesibil fără tunel; să îndrepți următorul salt spre adresa tunelului anulează scopul, pentru că pachetul ar intra din nou în interfața de care încerci să eviți. După ce conexiunea urcă din nou, ip route get pentru excepție ar trebui să afișeze gateway-ul LAN, iar aceeași comandă pentru un resolver public ar trebui să afișeze în continuare dispozitivul tunelului.

Un profil wg-quick nu are câmp de rute, așa că aceeași excepție trăiește într-o linie PostUp care adaugă ruta de gazdă în tabelul principal cu interfața LAN drept dispozitiv. Oprește și ridică din nou interfața după editare, pentru că o interfață aflată în funcțiune nu își recitește niciodată fișierul. Regulile fwmark pe care le instalează wg-quick dirijează doar propriile pachete încapsulate, așa că traficul obișnuit al browserului urmează în continuare tabelul principal și găsește /32-ul tău.

Kill switch-ul este următorul lucru care îl blochează

O politică de firewall care admite trafic doar pe interfața tunelului va arunca excepția chiar și atunci când ruta este perfect corectă. Citește regulile din spatele comutatorului în loc să te bazezi pe comutator, pentru că cele care implementează un kill switch sunt de obicei limitate la un nume de interfață.

Ce vrei este o permisiune îngustă pentru interfața fizică și acea singură destinație, plasată înainte de aruncare, în timp ce politica implicită rămâne neatinsă. A pune kill switch-ul pe pauză complet demonstrează ideea, dar lasă și mașina expusă atât timp cât uiți să îl repornești.

Testează cele două direcții separat. O cerere către adresa excepției ar trebui să reușească, în timp ce o cerere către un site nelegat iese în continuare prin tunel. Dacă ambele reușesc dar a doua raportează adresa de acasă, ordinea regulilor de firewall este greșită, nu ruta.

DNS-ul decide către ce adresă apelează browserul

Când numele este rezolvat în interiorul tunelului, resolver-ul furnizorului poate răspunde cu o adresă diferită de cea pe care a dat-o cel local. Ruta ta se aplică atunci unei adrese pe care browserul nu o contactează niciodată, iar pagina se încarcă prin tunel ca și cum nimic nu s-ar fi schimbat. Această defecțiune arată ca o excepție stricată chiar și atunci când tabelul de rutare este corect.

Trimite interogările acelui nume și prin resolver-ul local, sau sari complet peste nume și testează adresa direct. Separarea adresei în timp ce DNS-ul rămâne în interiorul tunelului este cea mai obișnuită versiune pe jumătate terminată a acestei configurări, și totodată cea mai greu de observat, pentru că site-ul continuă să funcționeze, doar nu așa cum ai vrut.

Aceeași excepție pe router, o dată, pentru fiecare dispozitiv

Când tunelul rulează pe router, ruta de gazdă aparține tabelului de rutare pe politici al routerului și indică gateway-ul WAN în loc de cel LAN. Fiecare dispozitiv din spate moștenește excepția, ceea ce contează pentru o cutie de streaming sau un laptop de muncă ale cărui setări de rețea nu le poți schimba.

Lasă tunelul ca ieșire implicită pentru toți ceilalți clienți, apoi verifică de pe o mașină client, nu din consola routerului. Încarcă site-ul excepției și un al doilea site în aceeași sesiune de browser și compară adresele de ieșire; dacă al doilea arată în continuare tunelul, tabelul de politici face ce ai cerut.

Notează adresa, data și motivul în notițele routerului. O excepție construită în jurul unei adrese care se mută mai târziu devine o defecțiune pe care nimeni nu o poate explica peste un an, iar remedierea arată mereu ca un mister până când cineva găsește nota veche.