Sisäkkäinen WireGuard: keskihyppy ei voi vastata omaan porttiinsa
Kun keskihyppy lähettää kaiken yhteen tunneliin, vastaukset sen saapuvaan palveluun lähtevät väärää reittiä. Rajapinnan lähdeporttisääntö korjaa sen.
Kolme WireGuard-hyppyä saavuttaa verkon, jolla ei ole julkista osoitetta, ja sitten keskimmäinen kone lakkaa vastaamasta portissa, jossa sen piti kuunnella. Tunneli eteenpäin toimii edelleen, kaukainen isäntä vastaa edelleen, ja vain keskimmäinen palvelin itse on vaiennut ulkopuolelta. Yhdistelmä on hämmentävä juuri siksi, että se on itse aiheutettu: keskihyppy noudattaa omaa reititystauluaan, ja taulu lähettää sen vastaukset väärään suuntaan.
Ketju, joka toimii, kunnes puhut keskimmäisen laatikon kanssa
Otetaan havainnollistava ketju: asiakas A saavuttaa palvelimen B UDP 500:ssa, ja B jatkaa palvelimelle C UDP 500:ssa. C hyväksyy liikennettä vain ainoan vertaisensa osoitteesta, mikä tekee siitä lehden ja pitää sen käytöksen yksinkertaisena. B ei ole lehti, ja kaikki kiinnostava tässä vikaantumisessa tapahtuu siellä.
Ero on tärkeä, koska lehden ja keskikohdan roolit vetävät vastakkaisiin suuntiin. Lehti voi lähettää kaiken yhteen tunneliin seurauksitta, koska mikään muu ei riipu siitä. Keskihyppy on samanaikaisesti sekä asiakkaiden päätepiste että asiakas kohti kaukaista puolta, ja ne kaksi työtä haluavat erilaista reititystä.
Miksi vastaus lähtee tunnelin kautta
B:ssä C:tä kohti oleva rajapinta kantaa AllowedIPs = 0.0.0.0/0 yhdessä vastaavan oletusreitin kanssa. Siksi jokainen B:n luoma paketti menee tuohon tunneliin, ellei jokin tarkempi saa etusijaa.
A:sta B:hen osoitettu paketti saapuu ja hyväksytään, koska B on kohde ja paikallinen toimitus tapahtuu ensin. Vastaus on aivan uusi paikallisesti luotu paketti, joka on suunnattu A:n julkiseen osoitteeseen, ja tuo kohde vastaa oletusreittiä tunneliin. C vastaanottaa sen, ei omista tuota osoitetta ja pudottaa sen.
Oire luetaan palomuuriongelmaksi tai avainten yhteensopimattomuudeksi, eikä kumpikaan pidä täällä paikkaansa. Kaappaus C:tä kohti olevalla tunnelilla näyttää vastausten menevän väärään suuntaan. Se yksi havainto säästää enemmän aikaa kuin mikään määrä kokoonpanon lukemista, joten kirjoita se muistiin ennen kuin alat vaihtaa avaimia. Jokainen, joka ei ole nähnyt kaappausta, olettaa, että itse tunneli on rikki.
Kapea korjaus: käytännön säännöt, jotka vastaavat lähdeporttia
B:n kuuntelevasta pistokkeesta lähtevät vastaukset lähtevät lähdeportilla 500. Käytäntösääntö voi vastata sitä ja ohjata ne paketit takaisin tavalliseen tauluun:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101Käytäntösäännöt käydään läpi prioriteettijärjestyksessä, ja päätaulu on kohdassa 32766, joten kohdassa 100 olevaa sääntöä kysytään ennen kuin tunnelin oletusreitti saa sanansa sanottua. Lisää yksi merkintä jokaista porttia kohden, jonka on pysyttävä saavutettavana ulkopuolelta, eikä mitään muuta, jotta edelleenlähetetty liikenne käyttää edelleen sitä tunnelia, jota varten se rakennettiin.
Tunne tämän tempun raja. Valitsin sport vastaa paikallisesti luotuja paketteja, mikä kattaa täsmälleen vastaustapauksen eikä tarkoituksella kata liikennettä, jonka B vain välittää jonkun toisen puolesta. B:n takana isännöity palvelu tarvitsee yhä oman vastauksensa, ja muun väittäminen tuottaa korjauksen, joka toimii ensimmäiselle palvelulle ja epäonnistuu toiselle.
Anna säännölle omistaja
Kehotteeseen kirjoitettu sääntö katoaa, kun rajapinta seuraavan kerran rakennetaan uudelleen. WireGuard-asennuksessa laita se sinne, missä rajapinta luodaan ja poistetaan:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100Jos rajapinnan omistaa NetworkManager, jakelun koukku tai kontin aloituspiste, pari kuuluu sille omistajalle eikä käsin muokattuun tiedostoon. Tarkista voimassa olevat säännöt uudelleenyhdistämisen jälkeen, älä vain ensimmäisen käynnistyksen jälkeen, koska ensimmäinen käynnistys on se tapaus, joka aina toimii.
Vertaa vaihtoehtoja rehellisesti
Lähdeporttisääntö on yksi neljästä ulospääsystä, ja se on niistä kapein. Sen etu on, ettei se koske tunnelikäytäntöön lainkaan, minkä vuoksi se yleensä selviää myöhemmistä muutoksista. Kapeat korjaukset myös epäonnistuvat äänekkäästi, kun ne lakkautuvat, kun taas laaja poikkeus jatkaa hiljaa toimimistaan kauan sen jälkeen, kun syy siihen on kadonnut. Tämä ero merkitsee enemmän kuin eleganssi, kun joku muu omistaa laatikon kahden vuoden kuluttua.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
Vahvista molemmista päistä kun olet valinnut. Käynnistä A:sta yhteys B:n porttiin ja pidä sitä hetken ajan varattuna. Pakota B:ssä ydin perustelemaan vastausreitti jollakin kuten ip route get <address-of-A> sport 500, ja vahvista, että se nimeää WAN-rajapinnan eikä tunnelia. Tarkista sen jälkeen, että jokin C:n takana vastaa yhä ketjun kautta, mikä todistaa, että poikkeus pysyi kapeana eikä muuttunut ohitukseksi. Kirjaa lopuksi portit suunnittelumuistiinpanoihin, tai seuraava ylläpitäjä löytää tämän uudelleen toisesta palvelusta.