WireGuard verkkonimiavaruudessa: miksi socket jäi taakse

Rajapinta on listattu haluamassasi nimiavaruudessa, sovellus on sidottu siihen, eikä tunneliliikennettä silti koskaan näy. Tämä on Linux-ytimen WireGuard-laitteen tunnusmerkki, kun se on luotu yhdessä nimiavaruudessa ja siirretty toiseen: rajapinta siirtyi, sen salattu UDP-socket ei. Molempien on oltava oikeassa paikassa ennen kuin sisäinen liikenne merkitsee mitään. Tarkistus on nopea, kun tietää, että on katsottava kahta kontekstia yhden sijaan.

Oire: oikea nimiavaruus, ei paketteja

Nimiavaruuden sisällä tunneli näyttää terveeltä. Laite on olemassa, osoitteet on määritetty ja vertaiskonfiguraatio on paikallaan. Ulkopuolella odotettu UDP-vaihto ei koskaan ilmesty rajapinnalle, jota seurasit, ja vastapuoli ilmoittaa, ettei kättelyä tapahtunut.

Syy on siinä, että sovelluksen sisäiset paketit saapuvat siirretylle laitteelle, ja laite yrittää lähettää ne socketin kautta, joka kuuluu toiseen verkkokontekstiin. Käyttämänsä aliverkon reitti ja jokainen siihen soveltuva palomuurisääntö ovat ne, jotka ovat siinä nimiavaruudessa, jossa laite luotiin.

Tämä ei ole siirron virhe eikä vertaisen väärä kokoonpano. Ytimen toteutus toimii näin, ja WireGuardin nimiavaruuksia koskeva dokumentaatio kuvaa luontisäännön suoraan.

Miksi socketilla on syntymäpaikka

WireGuard-laitteella on yksi UDP-socket salattua siirtoaan varten, ja tämä socket avataan siinä nimiavaruudessa, jossa laite luodaan. Rajapinnan siirtäminen linkkikomennolla siirtää näkyvän laitteen mutta jättää siirron sinne, missä se alkoi. Silloin kahdella objektilla on eri omistajat.

Seuraus on helppo jättää huomaamatta, koska puoliskot tarkastetaan eri paikoissa. Sisäinen reitti päätetään siinä nimiavaruudessa, jossa sovellus toimii, ja ulkoinen reitti päätetään siellä, missä socket elää. Vain toisen tarkistaminen antaa itsevarman mutta väärän johtopäätöksen. Molempien tarkistaminen yleensä lopettaa tutkinnan yhdellä kierroksella.

Luokaa se sinne, minne haluatte socketin

Ratkaisu on luoda laite kohdenimiavaruuden sisällä sen sijaan, että sen loisi ulkopuolella ja siirtäisi. Olettaen, että hyväksytty nimiavaruus on jo olemassa ja nimi on käyttämätön:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

Nyt sekä rajapinta että sen socket kuuluvat tähän kontekstiin, joten aliverkon reitti ja sovellettavat suodatussäännöt ovat siellä määritetyt. Jos suunnittelu tarvitsee selvän puolen muualla, aseta ensin alirajapinta nimiavaruuteen ja luo tunneli sen jälkeen. Järjestys on osa suunnittelua, ei toteutuksen yksityiskohta.

Käsittele näitä verkon hallinnan komentoina, älä reseptinä. Ne luovat laitteen ja näyttävät tilan; avaimet, vertaiset, osoitteet ja reitit on silti saatava hyväksytystä kokoonpanosta, eikä olemassa olevaa tuotantorajapintaa pitäisi koskaan sijoittaa esimerkkiin.

Lukekaa polun molemmat puolet

Kun laite on oikeassa paikassa, tarkista kaksi päätöstä erikseen. Aloita sisäisestä hausta sovelluksen kontekstista ja tarkista sitten ulkoinen polku kontekstista, jolle socket kuuluu:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

Jos sisäinen haku ratkeaa tunnelin kautta ja ulkoinen tallenne näyttää salatun vaihdon, molemmat puoliskot ovat yhtä mieltä. Jos tallenne on tyhjä, socket on vielä muualla tai sen nimiavaruuden aliverkon reitti ei yllä päätepisteeseen.

Vielä yksi tarkistus kuuluu tallenteeseen: miten laite luodaan uudelleenkäynnistyksen jälkeen. Hallintaohjelma, joka luo rajapinnan uudelleen eri luontikontekstissa, muuttaa socketin syntymäpaikkaa. Kerran toiminut manuaalinen siirto ei ole todiste hallitusta polusta.