Sisäkkäiset VPN-tunnelit: miksi sisempi jumiutuu suurilla paketeilla

DNS ratkeaa, SSH-istunto pysyy pystyssä, ja sitten suuri lataus jumiutuu, kun ping samaan isäntään vastaa yhä. Tämä kahtiajako viittaa paketin kokoon eikä rikkinäiseen tunneliin. Sisäkkäiset tunnelit saavuttavat sen kokoina, joihin kumpikaan tunneli ei yksin yltäisi. Sisempi istunto on kunnossa; sille vain annetaan paketteja, jotka eivät enää mahdu.

Mihin polun MTU oikeastaan menee

Jokainen kapselointi kuluttaa tavuja ennen kuin seuraava kerros saa vuoronsa. Ethernet-polku tarjoaa ulommalle paketille 1500 tavua, ja ulompi tunneli ottaa osuutensa ennen kuin mitään sen sisällä voi osoittaa. Yksi arvattu yleiskustannusarvo on väärä täsmälleen sen verran kuin on merkitystä.

Luettele kerrokset järjestyksessä: yhteyspolku, ulompi kuljetus, ulompi tunneli, sisempi kuljetus, sisempi tunneli, sovellus. Laske jokainen otsake kerran ja pidä UDP erillään tunnelin omasta otsakkeesta ja tunnisteesta.

Kaksi WireGuard-kerrosta, laskettu kerran

Ota IPv4-yhteyspolku, jonka sisällä on yksi WireGuard-tunneli toisen sisällä. Ulompi kerros maksaa 20 tavua IPv4:ää, 8 UDP:tä ja 32 WireGuardin dataotsaketta sekä sen todennustunnistetta varten. Sen sisällä sisempi tunneli tarvitsee oman 20 tavun IPv4-otsakkeensa ja 8 tavun UDP-otsakkeensa ennen toista 32 tavuaan WireGuard-ylikustannusta. Jäljelle jäävä osa pitää sisällään IPv4-otsakkeen, TCP-otsakkeen ja datan. Ulompi IPv6-polku maksaa 40 eikä 20 ja jättää 1320.

Aritmetiikka päätyy 1340 tavuun. Yksi kerros samoilla säännöillä jättää TCP-hyötykuormalle 1400, eli 1500 miinus 20, 8, 32, 20 ja 20, ja 60 tavun ero on täsmälleen se sisempi kapselointi, jonka toinen tunneli lisää.

Käytä 1400:aa sisäkkäisellä polulla, niin sisemmältä tunnelilta puuttuu 60 tavua, näkymättömästi kunnes paketti on tarpeeksi suuri tarvitsemaan ne. Täyte ja protokollan oma pirstoutumisvaihtoehto siirtävät lukuja taas, joten luota taulukkoon.

MTU, MSS ja pirstoutuminen vaikuttavat eri paikoissa

Liitännän MTU rajoittaa sitä, mitä liitäntä lähettää, kun taas TCP:n MSS-puristus muuttaa sitä, mitä TCP-vastapuoli on valmis lähettämään. Puristus korjaa TCP-istunnot eikä tee mitään suurelle UDP-datagrammille, ja näin korjaus näyttää onnistuneelta yhdelle sovellukselle ja ohittaa seuraavan hiljaa. Protokollan oma pirstoutumisvaihtoehto on kolmas vipu omine epäonnistumisineen. Liitännän MTU on tavallinen ensiaskel ja kaikkein karkein.

Sillatut ja reititetyt tunnelit kuljettavat erilaisia kehyksiä, joten toisen käyttöönoton luvut siirtyvät harvoin. Polun MTU:n löytäminen, jota kuvataan RFC 8201:ssä, auttaa vain niin kauan kuin sen tarvitsemat ICMP-viestit päästetään läpi.

Vajaan kerroksen löytäminen

Tarkista jokainen tunneli erikseen ennen niiden sisäkkäistämistä, jos vaatimukset sallivat vertailun. Kiinteän koon anturi ratkaisee sen: ping -M do -s 1472 -c 3 10.8.0.1 lähettää täyden 1500 tavun IPv4-paketin kyseisen kerroksen sisällä. Lisää toinen kerros ja toista sama anturi, jotta mikä tahansa vika kuuluu tiedossa olevaan muutokseen.

Kun siirto jumiutuu, muuta yhtä dokumentoitua parametria kerrallaan ja kirjaa koko, jolla se epäonnistuu. Tarkista myös paluupolku, sillä sisäkkäinen reittien rekursio voi jäljitellä pakettikoko-ongelmaa tarpeeksi tarkasti maksaakseen iltapäivän. Suodatettu ICMP-vastaus voi piilottaa todellisen rajan, joten anturi on tärkeämpi kuin päättely.

Kirjoita budjetti sinne, mistä seuraava ihminen löytää sen

Taulukko, jossa on yksi rivi kerrosta kohden, elää pidempään kuin peukalosääntö. Pidä se tunnelikaavion vieressä, jotta kukaan ei tee aritmetiikkaa uudelleen paineen alla.

Useammat tunnelit tarkoittavat enemmän riippuvuuksia, joten peruutussuunnitelma ansaitsee paikkansa budjetin vieressä. Jos luvut eivät vieläkään täsmää, mittaa polku sen sijaan että arvaisit uudelleen. Tavoite on luku, jonka voit puolustaa, ei muistaa.