WireGuard jumittuu: MTU-raja vai puuttuva välityssääntö?
Kaikki palvelimen tuolla puolen on välitys- tai paluureittiongelma. Pienet pyynnöt, jotka toimivat suurten jumittaessa, ovat pakettikoon allekirjoitus.
Tapana on laskea MTU heti, kun WireGuard alkaa käyttäytyä huonosti, ja tuo tapa peittää alleen toisen vian. Yhdyskäytävä, joka ei välitä, ja polku, joka ei kanna suuria paketteja, tuottavat erottuvia kuvioita: toinen epäonnistuu molempiin suuntiin ja kaikilla kooilla, toinen selviää pienistä pyynnöistä ja kuolee suurilla. Selvitä, kumpi muoto sinulla on, ennen kuin muutat mitään lukua. Testi on halpa, ja se poistaa puolet mahdollisista syistä.
Kaksi vikaa, kaksi eri muotoa
Välitysongelma näkyy heti palvelimen jälkeen. Kättely onnistuu, tunnelin osoite vastaa, eikä yhdyskäytävän takana oleviin päästä edes pienellä pyynnöllä. Paketti saapui palvelimelle eikä sitä välitetty eteenpäin, tai vastauksella ei ollut paluureittiä.
Koko-ongelma ilmenee vain kynnyksen yläpuolella. DNS, TCP-kättely ja pieni API-kutsu toimivat, kun taas tiedoston lataus tai suuri vastaus jumittuu. Mahtuneet paketit kulkivat päästä päähän, ja ne, jotka eivät mahtuneet, pudotettiin jossain ilman käyttökelpoista raporttia.
Nuo kuvaukset osoittavat eri ihmisiin ja eri asetustiedostoihin, siksi muodon mittaaminen on arvokkaampaa kuin arvailu. Yksittäinen ping yhdyskäytävälle ei pysty erottamaan niitä.
Sulje välitys pois ennen kuin pienennät mitään
Testaa kohde yhdyskäytävän tuolla puolen, älä itse yhdyskäytävää. Ping palvelimen tunneliosoitteeseen todistaa vain, että liitäntä on ylhäällä ja että pääset tunnelin päättävään koneeseen. Laajemman verkon liikenne riippuu siitä, että IP-välitys on kytketty päälle tuossa koneessa, ja palomuurista, joka sallii välitetyn virtauksen. Molempien on oltava totta, ja jos toinen on väärin, syntyy sama hiljaisuus.
Paluureititys on yhtä tärkeää. Jos kohdeverkko ei tiedä, miten asiakkaan tunneliosoitteeseen päästään, pyyntö saapuu ja vastaus katoaa, ja asiakas ilmoittaa aikakatkaisusta, joka näyttää samalta kuin pudotettu välitys.
Kun suunnittelu käyttää osoitteenmuunnosta, muuntosääntö on osa tuota paluupolkua. Sen poistaminen MTU-ongelmaa jahdatessa muuttaa toimivan suunnittelun rikkinäiseksi, joten lue olemassa olevat säännöt ennen niiden muokkaamista.
Mittaa, mistä katkos alkaa
Lue ensin välityksen tila ja suodatussäännöt. Nämä ovat vain lukemista varten, ja ne vastaavat halpaan kysymykseen:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9Testaa sitten koot don’t-fragment-bitillä, asiakkaasta, kohti yhdyskäytävän takana olevaa isäntää:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9Jos ensimmäinen koe toimii ja toinen epäonnistuu pirstoutumisvirheellä, polku kertoo käyttökelpoisen kokonsa. Jos kumpikaan ei toimi, katsot välitystä tai reititystä, eikä MTU ole muutettava muuttuja.
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
Korjaa kerros, jonka todistit
Kun välitys on vika, korjaus on välityssääntö tai reitti, ilmaistuna niin kapeasti kuin suunnittelu sallii. Kun koko on vika, korjaus on MTU, joka ottaa huomioon kapseloinnin juuri tällä polulla, kohdistettuna liitäntään, joka sitä tarvitsee, eikä jokaiseen kaluston sovittimeen.
Kummassa tapauksessa tahansa, toista sen jälkeen sama tehtävä samaan kohteeseen. Jos alkuperäinen suuri siirto nyt valmistuu, muutos käsitteli kerrosta, joka epäonnistui. Jos vain pieni koe parani, hoidit oiretta ja todellinen raja on yhä paikallaan.
Kirjoita muistiin, minkä muodon näit ennen muutosta. Se yksi rivi, korjauksen viereen merkittynä, on se, mikä estää seuraavaa ihmistä laskemasta MTU:ta, joka ei koskaan ollut ongelma.