Hogyan irányítsunk egyetlen webhelyet a WireGuard-alagútunkon kívülre

Egy gazdagépnév kizárása olyasmi, amit egy alagút nem tud megtenni. Egy útvonal viszont átirányíthat egyetlen címet az alagúton kívülre és ki a otthoni átjárón, és ez általában elég egy oldalhoz. A bökkenő az, hogy mindennek, ami az útvonal után van, egyet kell értenie: a tűzfalnak ki kell engednie a csomagot, a DNS-nek vissza kell adnia a címet, amit átirányítottál, és az oldalnak továbbra is ezt a címet kell használnia. Amikor bármelyik a három közül elcsúszik, a kivétel bejelentés nélkül felhagy a működéssel.

Olvasd el a célcímet, mielőtt hozzányúlsz az alagúthoz

Töltsd be az oldalt egyszer, az alagút bekapcsolt állapotában, aztán nézd meg azt a partner-címet, amelyhez a böngésző valóban csatlakozott. Linuxon, ss -tunp listázza minden nyitott socket távoli címét, és a dig +short ugyanarra a névre megmutatja, mit adott vissza a feloldó. Tartsd mindkét számot magad előtt.

A két válasz gyakran nem egyezik, és ez az eltérés maga a probléma. A nagy oldalak tartalomhálózatot tesznek az eredetük elé, ezért előfordulhat, hogy a feloldó által most visszaadott cím nem az, amelyet a böngésző egy perce használt. Azt irányítsd, amit a socketen megfigyeltél, ne azt, amit egy régebbi útmutató felsorol. Ha a válaszok folyton vándorolnak a régiók között, a címkivétel rossz eszköz ahhoz az adott oldalhoz.

Futtasd a keresést másodszor is egy másik hálózatról, és jegyezd fel az IPv6-os választ az IPv4-essel együtt. Az alagútnak, amely mindkét családot szállítja, mindkettőben kivétel kell, különben a böngésző csendben visszaesik arra az IPv6-os útra, amelyhez soha nem nyúltál. Írd fel a címeket és a dátumot valahová, ahová újra benézel.

Tegyél egy gazdagép-útvonalat az ügyfélre

Tegyük fel, hogy az interfész neve home-wg, és a LAN-router a 192.168.1.1-en áll. A NetworkManager olyan útvonalat vesz fel, amelynek átjárója ez a router, és amelynek előtaghossza lefedi a teljes 32 bitet, a kernel pedig azért részesíti előnyben, mert a leghosszabb előtag győz.

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

Az átjárónak az alagút nélkül is elérhetőnek kell lennie; a következő ugrásnak az alagút címére mutatása meghiúsítja a célt, mert a csomag újra belépne abba az interfészbe, amelyet el akarsz kerülni. Miután a kapcsolat újra feláll, ip route get a kivételnél a LAN-átjárót kell kiírnia, és ugyanennek a parancsnak egy nyilvános feloldónál továbbra is az alagút eszközét kell kiírnia.

A wg-quick profilnak nincs útvonalmezője, ezért ugyanaz a kivétel egy olyan PostUp sorban él, amely a gazdagép-útvonalat a fő táblához adja, a LAN-interfészt téve meg eszközének. Szerkesztés után szedd le és hozd fel újra az interfészt, mert egy futó interfész soha nem olvassa újra a fájlját. A wg-quick által telepített fwmark-szabályok csak a saját beágyazott csomagjait terelik, ezért a szokásos böngészőforgalom továbbra is a fő táblát követi, és megtalálja a /32-edet.

A kill switch a következő dolog, ami blokkolja

Egy olyan tűzfalszabály, amely csak az alagút interfészén enged forgalmat, akkor is eldobja a kivételt, ha az útvonal pontosan helyes. A kapcsoló mögötti szabályokat olvasd, ne a kapcsolóban bízz, mert a kill switchet megvalósítók általában egy interfésznévhez kötöttek.

Amit szeretnél, az egy szűk engedély a fizikai interfészre és arra az egy célra, az eldobás elé helyezve, miközben az alapértelmezett szabályzat érintetlen marad. A kill switch teljes szüneteltetése bizonyítja a pontot, de nyitva is hagyja a gépet mindaddig, amíg elfelejted visszakapcsolni.

Teszteld a két irányt külön. A kivétel címére menő kérésnek sikerülnie kell, miközben egy független oldalra menő kérés továbbra is az alagúton keresztül megy ki. Ha mindkettő sikerül, de a második az otthoni címet jelenti, akkor a tűzfalszabályok sorrendje rossz, nem az útvonal.

A DNS dönti el, melyik címre tárcsáz a böngésző

Amikor a név az alagúton belül oldódik fel, a szolgáltató feloldója más címet adhat, mint a helyi. Ekkor az útvonalad egy olyan címre vonatkozik, amelyet a böngésző soha nem keres fel, és az oldal az alagúton keresztül töltődik be, mintha semmi sem változott volna. Ez a hiba törött kivételnek látszik, pedig az útválasztási tábla helyes.

Küldd el a név lekérdezéseit a helyi feloldón keresztül is, vagy hagyd ki teljesen a neveket, és teszteld közvetlenül a címet. A cím felosztása, miközben a DNS az alagúton belül marad, a leggyakoribb félkész változata ennek a beállításnak, és ezt a legnehezebb észrevenni, mert az oldal tovább működik, csak nem úgy, ahogy szántad.

Ugyanaz a kivétel a routeren, egyszer, minden eszközre

Ha az alagút a routeren fut, a gazdagép-útvonal a router házirend-útválasztási táblájába tartozik, és a LAN-átjáró helyett a WAN-átjáróra mutat. Minden mögötte lévő eszköz örökli a kivételt, ami számít egy streamingdoboznál vagy egy munkalaptopnál, amelynek hálózati beállításait nem tudod megváltoztatni.

Hagyd az alagutat alapértelmezett kijáratként minden más ügyfélnek, majd ellenőrizd egy ügyfélgépről, ne a router konzoljáról. Töltsd be a kivétel oldalát és egy második oldalt ugyanabban a böngésző-munkamenetben, és hasonlítsd össze a kilépési címeket; ha a második még mindig az alagutat mutatja, a házirendtábla azt teszi, amit kértél.

Írd fel a címet, a dátumot és az okot a router jegyzeteibe. Egy olyan cím köré épített kivétel, amely később elmozdul, olyan hibává válik, amelyet egy év múlva senki sem tud megmagyarázni, és a javítás mindig rejtélynek tűnik, amíg valaki meg nem találja a régi jegyzetet.