WireGuardin isäntäetuliite: miksi yksi osoite toimii ja muut eivät

Tunneli on pystyssä, handshake tapahtuu kahden minuutin välein ja täsmälleen yksi osoite toisella puolella vastaa. Pingit peerin tunneliosoitteeseen toimivat; mikään sen takana ei toimi. Joku lukee liitännän konfiguraation, näkee isäntäetuliitteen ja päättelee, että maski on väärä. Sen leventäminen /24:ään korjaa pingin hetkeksi ja rikkoo sitten jotain muuta. Etuliite ei ollut koskaan syyllinen, eikä puuttuva reitti ole se, jota maski ohjaa.

Mitä liitännän etuliite oikeastaan luo

Linuxissa osoitteen liittäminen liitäntään luo kyseiselle etuliitteelle yhdistetyn reitin. Jos liität isäntäetuliitteen, yhdistetty reitti kattaa yhden osoitteen. Jos liität /24:n, se kattaa 256, ja jokaista niistä pidetään nyt kyseisen linkin kautta saavutettavana.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Isäntäetuliite on täysin tavallinen valinta pisteestä pisteeseen -tunnelille, koska toisessa päässä on täsmälleen yksi peer. Kolmas komento on se, joka vastaa käyttäjän kysymykseen: se kertoo, mitä liitäntää ydin käyttäisi kyseiseen kohteeseen, eikä se näytä mitään hyödyllistä, jos mikään reitti ei täsmää.

Siinä koko oireen selitys. Yksi osoite vastaa, koska sille on yhdistetty reitti, tai koska peerin sallittu luettelo sattuu sisältämään sen. Kaikella muulla ei ole reittiä, ja se pudotetaan ennen kuin WireGuard on edes mukana. Tunneli on terve koko ajan, minkä vuoksi handshake-laskuri näyttää yhä rauhoittavalta.

AllowedIPs on kaksi sääntöä yhden nimen alla

WireGuardin peerikohtainen sallittu luettelo tekee kahta työtä yhtä aikaa, ja konfiguraation syntaksi saa ne näyttämään yhdeltä. Saapuvassa suunnassa se sallii, mitä lähdeosoitteita peer saa esittää. Lähtevässä suunnassa se valitsee, mille peerille paketti lähetetään, löytämällä tarkimman vastaavuuden.

Kumpikaan näistä töistä ei ole reititystä. Ytimen on silti päätettävä, että paketti kuuluu tunnelin liitäntään, ennen kuin WireGuard katsoo sitä, ja tämä päätös tulee reititystaulusta. Peer-merkintä laajalla sallitulla luettelolla ei asenna reittiä itsestään.

Siksi konfiguraatio voi näyttää täydelliseltä ja käyttäytyä epäsymmetrisesti. Asiakas lähettää toiselle puolelle, koska reitti on olemassa, eivätkä vastaukset koskaan saavu, koska toisen puolen sallittu luettelo ei salli asiakkaan lähdettä tai koska toisella puolella ei ole paluureittiä. Molemmat suunnat ovat erillisiä päätöksiä erillisillä vikatiloilla. Sen kirjaaminen, kumpaa testaat, on puolet diagnoosista.

Mistä reitti tulee

Jos käytät wg-quickia, reitit luodaan puolestasi kunkin peerin sallitusta luettelosta, ellet ole asettanut Table = off ja ottanut hallintaa itse. Se on työkalun dokumentoima käyttäytyminen, ja syy siihen, miksi konfiguraatio ilman selkeitä reittiohjeita toimii silti.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Vertaile sallittua luetteloa reitteihin, jotka todella ovat olemassa. Peer, joka sallii kokonaisen aliverkon mutta loi vain isäntäreitin, tarkoittaa, että apuri ei koskaan ajanut, tai että hallitset liitäntää suoraan wg ja ip avulla, jolloin mikään ei luo reittejä puolestasi.

Kun hallitset sitä käsin, reitti on yksi rivi ja sen muoto on selkeä: kohde liitännän kautta, ilman yhdyskäytävää, koska linkki on pisteestä pisteeseen. Sen lisääminen ei ole kiertotie huonolle etuliitteelle; se on puuttuva puolisko suunnittelusta, joka päätti ottaa reitityksen itse.

Leveämpi etuliite ei lisää peer-merkintää

Houkutteleva korjaus on vaihtaa osoite /24:ksi, jotta yhdistetty reitti kattaisi palvelimen lähiverkon. Se näyttää toimivan, ja syy näyttää toimivalta on se, että yhdistetty reitti täsmää nyt, ei se, että WireGuard olisi oppinut jotain uutta.

Mitä myös teit, on koko alueen vaatiminen suoraan kyseisen linkin kautta tavoitettavaksi, mukaan lukien osoitteet, jotka kuuluvat muille peereille tai lähiverkolle, joka on todella palvelimen takana. Liikenne näihin osoitteisiin tulee nyt tunneliin, ja se, tuleeko se toisella puolella ulos, riippuu palvelimen omasta reitityksestä ja sallituista luetteloista.

Kryptografinen puoli ei ole millään tavalla vaikuttunut. WireGuard tarvitsee yhä sallittuun luetteloon merkinnän, joka kattaa kohteen peerin valitsemiseksi, ja toinen puoli tarvitsee yhä merkinnän, joka kattaa lähteesi sen hyväksymiseksi. Leveämpi liitännän etuliite ei voi tarjota kumpaakaan.

Vahvista molemmat suunnat ennen kuin muutat mitään

Käsittele kaksi päätä erikseen ja kirjaa, mitä kumpikin sanoo. Asiakkaassa reitti ja peer-merkintä; palvelimessa peilikuva plus sen oma paluureitti:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

Kaappaus on se, joka ratkaisee suunnasta käytävät kiistat. Jos lähtevät paketit ilmestyvät tunnelin liitäntään eikä palvelin kirjaa mitään, kauempi pää hylkää ne, yleensä siksi, että lähteesi on sen sallitun luettelon ulkopuolella. Jos mitään ei ilmesty lainkaan, reitti puuttuu tai osoittaa muualle.

Korjaa sitten kapeampi pää. Merkintä sallitussa luettelossa palvelimen puolella asiakkaasi osoitteelle ja merkintä asiakkaan puolella kohdealiverkolle on tavallinen muoto, ja se jättää liitännän etuliitteen rauhaan. Levennä etuliitettä vain, jos osoitesuunnitelma todella haluaa jaetun aliverkon kyseiselle linkille, ja tee se suunnitelman muutoksena eikä virheenkorjausvaiheena.