Näin ohjaat yhden verkkosivuston WireGuard-tunnelisi ulkopuolelle
Yksi /32-reitti LAN-yhdyskäytävän kautta pitää yhden sivuston normaalilla yhteydelläsi, edellyttäen että palomuuri sallii sen ja DNS on samaa mieltä osoitteesta.
Isäntänimen jättäminen pois on jotain, mitä tunneli ei voi tehdä. Reitti voi kuitenkin ohjata yhden osoitteen tunnelin ohi ja ulos kodin yhdyskäytävän kautta, ja se riittää yleensä yhdelle sivustolle. Hankaluus on siinä, että kaiken reitistä alavirtaan on oltava samaa mieltä: palomuurin on päästettävä paketti ulos, DNS:n on palautettava reitittämäsi osoite ja sivuston on jatkettava tuon osoitteen käyttöä. Kun mikä tahansa kolmesta ajautuu, poikkeus lakkaa toimimasta ilmoittamatta siitä.
Lue kohdeosoite ennen kuin kosket tunneliin
Lataa sivusto kerran tunnelin ollessa päällä ja katso sitten vertaisosoitetta, johon selain todella yhdisti. Linuxissa ss -tunp luettelee jokaisen avoimen pistokkeen etäosoitteen ja dig +short samalla nimellä näyttää, mitä resolveri palautti. Pidä molemmat numerot edessäsi.
Kaksi vastausta ovat usein eri mieltä, ja juuri se erimielisyys on koko ongelma. Suuret sivustot laittavat sisältöverkon alkuperänsä eteen, joten resolverin nyt palauttama osoite ei välttämättä ole se, jota selain käytti minuutti sitten. Reititä se, minkä näit pistokkeella, älä sitä, mitä vanhempi opas luettelee. Jos vastaukset pyörivät jatkuvasti alueiden välillä, osoitepoikkeus on väärä työkalu juuri sille sivustolle.
Suorita haku toisen kerran toisesta verkosta ja kirjaa IPv6-vastaus ylös IPv4-vastauksen kanssa. Tunneli, joka kuljettaa molempia perheitä, tarvitsee poikkeuksen molempiin, muuten selain putoaa hiljaa takaisin IPv6-polulle, jota et koskaan koskenut. Kirjoita osoitteet ja päivämäärä jonnekin, johon katsot uudelleen.
Aseta yksi isäntäreitti asiakkaalle
Oletetaan, että liitäntä on nimeltään home-wg ja LAN-reititin on osoitteessa 192.168.1.1. NetworkManager ottaa reitin, jonka yhdyskäytävä on tuo reititin ja jonka etuliitteen pituus kattaa kaikki 32 bittiä, ja ydin suosii sitä, koska pisimmän etuliitteen sääntö voittaa.
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
Yhdyskäytävän on oltava tavoitettavissa ilman tunnelia; seuraavan hypyn osoittaminen tunnelin osoitteeseen tekee tyhjäksi tarkoituksen, koska paketti palaisi liitäntään, jota yrität välttää. Kun yhteys nousee taas, ip route get poikkeuksen kohdalla pitäisi tulostua LAN-yhdyskäytävä, ja saman komennon julkiselle resolverille pitäisi yhä tulostaa tunnelin laite.
wg-quick-profiilissa ei ole reittikenttää, joten sama poikkeus elää rivillä PostUp , joka lisää isäntäreitin päätauluun LAN-liitännän ollessa sen laite. Laske liitäntä alas ja nosta uudelleen muokkauksen jälkeen, koska käynnissä oleva liitäntä ei koskaan lue tiedostoaan uudelleen. wg-quickin asentamat fwmark-säännöt ohjaavat vain sen omia kapseloituja paketteja, joten tavallinen selainliikenne seuraa yhä päätaulua ja löytää /32-osoitteesi.
Kill switch on seuraava asia, joka estää sen
Palomuurikäytäntö, joka sallii liikenteen vain tunnelin liitännällä, pudottaa poikkeuksen, vaikka reitti olisi täsmälleen oikein. Lue kytkimen takana olevat säännöt sen sijaan, että luottaisit kytkimeen, koska kill switchin toteuttavat säännöt on yleensä rajattu liitännän nimeen.
Haluat kapean luvan fyysiselle liitännälle ja sille yhdelle kohteelle, sijoitettuna ennen pudotusta, kun taas oletuskäytäntö pysyy koskemattomana. Kill switchin pysäyttäminen kokonaan todistaa asian, mutta jättää koneen myös alttiiksi niin kauaksi kuin unohdat kytkeä sen takaisin päälle.
Testaa kaksi suuntaa erikseen. Pyynnön poikkeusosoitteeseen pitäisi onnistua, kun taas pyyntö asiaankuulumattomaan sivustoon lähtee yhä tunnelin kautta. Jos molemmat onnistuvat mutta toinen ilmoittaa kodin osoitteen, palomuurin sääntöjen järjestys on väärä eikä reitti.
DNS päättää, mihin osoitteeseen selain soittaa
Kun nimi ratkaistaan tunnelin sisällä, palveluntarjoajan resolveri voi vastata eri osoitteella kuin paikallinen. Reittisi koskee silloin osoitetta, johon selain ei koskaan ota yhteyttä, ja sivu latautuu tunnelin kautta kuin mitään ei olisi muuttunut. Tämä vika näyttää rikkinäiseltä poikkeukselta, vaikka reititystaulu on oikein.
Lähetä myös tuon nimen kyselyt paikallisen resolverin kautta tai ohita nimet kokonaan ja testaa osoitetta suoraan. Osoitteen jakaminen samalla kun DNS jää tunnelin sisään on tämän asetelman yleisin puolivalmis versio, ja se on myös vaikein huomata, koska sivusto toimii edelleen, vain ei niin kuin tarkoitit.
Sama poikkeus reitittimellä, kerran, joka laitteelle
Kun tunneli pyörii reitittimellä, isäntäreitti kuuluu reitittimen politiikkareititystauluun ja osoittaa WAN-yhdyskäytävään LAN-yhdyskäytävän sijaan. Jokainen laite sen takana perii poikkeuksen, millä on merkitystä suoratoistolaatikolle tai työläppärille, jonka verkkoasetuksia et voi muuttaa.
Jätä tunneli oletuspoistumaksi kaikille muille asiakkaille ja varmista sitten asiakaskoneelta, älä reitittimen konsolista. Lataa poikkeussivusto ja toinen sivusto samassa selainistunnossa ja vertaa poistumisosoitteita; jos toinen näyttää yhä tunnelin, politiikkataulu tekee sen, mitä pyysit.
Kirjoita osoite, päivämäärä ja syy reitittimen muistiinpanoihin. Poikkeus, joka on rakennettu osoitteen ympärille ja joka myöhemmin siirtyy, muuttuu viaksi, jota kukaan ei pysty selittämään vuoden päästä, ja korjaus näyttää aina arvoitukselta, kunnes joku löytää vanhan muistiinpanon.