Yksi sovellus WireGuardin läpi: sitominen ei ole reititystä

Asetus näyttää sovelluskohtaiselta kytkimeltä, joten ihmiset sitovat asiakkaan WireGuard-rajapintaan ja odottavat, että vain se asiakas käyttää tunnelia. Itse sitominen valitsee lähdeosoitteen. Sen jälkeen ydin etsii reitin kohteelle, löytää tavallisen oletusreitin ja lähettää paketin fyysisen linkin kautta tunneliosoite siihen liitettynä. Vain kyseiselle lähdeosoitteelle valittu reitti toteuttaa aikeen.

Mekanismissa on kaksi puoliskoa: reititystaulu, jota vain tunnelin liikenteen pitäisi käyttää, ja sääntö, joka lähettää vastaavan lähteen sinne.

Sitominen asettaa lähdeosoitteen eikä mitään muuta

Linux valitsee lähtevän rajapinnan etsimällä kohteen reititystaulusta sen jälkeen, kun käytäntösäännöt ovat saaneet tilaisuuden ohjata haku toisaalle. Säännöt voivat valita lähdeosoitteen, palomuurimerkin, saapuvan rajapinnan, UID:n tai jopa portin perusteella; kukin on toinen tapa sanoa tämä liikenne kaiken sijaan. VPN-asiakkaan kokoonpano valitsee taulun, jossa tunnelin reitit ovat; sääntö valitsee, mikä liikenne saa käyttää sitä. Pelkkä sitominen ei anna kumpaakaan.

Siksi vika näyttää niin oudolta. Sovellus käyttää varmasti tunneliosoitetta, tunneli on varmasti ylhäällä ja liikenne lähtee varmasti väärästä rajapinnasta. Jokainen väite on totta, ja yhdessä ne kuvaavat järjestelmää, jossa mikään ei yhdistänyt osoitetta reittiin.

Anna tunnelille oma taulu

wg-quick asentaa reitit sinne, mihin profiili käskee. Table = 40-rivin lisääminen [Interface]-osion alle siirtää ne tauluun 40 päätaulun sijaan. Nosta rajapinta ja varmista, että ne saapuivat: ip -4 route ls table 40:n pitäisi näyttää tunnelin reitit, ja ip -4 route get 10.66.127.142 näyttää, miten ydin tällä hetkellä ratkaisee yhden niistä. Kun reitit ovat omassa taulussaan, päätaulu jatkaa toimintaansa kaikelle muulle.

Tee sama IPv6:lle sen sijaan, että sovittaisit leveää etuliitettä. ip -6 rule add from fd00::2/128 lookup 40 kiinnittää yhden osoitteen; fc00::/8 voi törmätä isännän muihin rajapintoihin ja tuottaa säännön, joka osuu useampaan kuin oli tarkoitus.

Lisää lähdesääntö ja seuraa laskureita

Yhdistä sitten puoliskot: ip -4 rule add from 10.66.127.142/32 lookup 40, sama osoite WireGuard-rajapintaan liitettynä. Laita molemmat säännöt PostUp-kohtaan, jotta uudelleenyhdistäminen palauttaa ne. Tarkista todellisella pyynnöllä äläkä asetuksella: ip route get 1.1.1.1 from 10.66.127.142:n pitäisi nimetä tunnelilaite, ja curl --interface wg0 ifconfig.me:n pitäisi raportoida tunnelin osoite eikä kotiosoitetta.

Kun se ei vieläkään toimi, lue ip -s rule. Sääntö, joka on olemassa mutta ei ole koskaan osunut, näyttää nollalaskurit, ja se erottaa väärän säännön siitä, ettei sääntöä ole lainkaan. Se yksi komento säästää paljon arvailua siitä, jättikö sovellus rajapinta-asetuksensa huomiotta.

Käänteinen tapaus: pidä SSH tunnelin ulkopuolella

Vastakkainen ongelma on yhtä yleinen: wg-quick omistaa oletusreitin ja SSH-istunto palvelimelle kuolee kesken istunnon. Sen säännöt ovat matalalla prioriteettinumerolla, joten poikkeus on arvioitava niitä aiemmin. ip rule add dport 22 ipproto tcp table main priority 123 tekee sen tuoreessa iproute2:ssa; missä valitsin ei ole käytettävissä, merkitse virtaus nftablesissa ja sovita merkkiä.

Tarkista myös vastauspolku. SSH-istunto, joka muodostuu ja sitten vaikenee, kulkee yleensä epäsymmetrisesti: toinen suunta lähtee tunnelin ja toinen fyysisen rajapinnan kautta. ip route get palvelimen osoitteelle kertoo, mihin suuntaan vastaus menisi.

Kirjaa taulun numero, lähdesääntö ja poikkeus itse profiiliin. Kaikki kolme kuuluvat yhteen suunnitelmaan ja niitä muokataan yhdessä.