IPIP dins de WireGuard: els 20 bytes extra que ningú no va pressupostar

Els pings petits travessen el túnel tot el dia, arriba la benvinguda SSH i, just quan comença una transferència de fitxers, la sessió es congela. Aquest patró assenyala un pressupost de bytes comptat a la capa equivocada, on el túnel exterior es va dimensionar per al seu propi sobrecost i ningú no va restar el interior. Un paquet IPIP imbricat és només un altre paquet IP per a WireGuard, i per això mateix consumeix bytes que mai no vau reservar. La correcció és aritmètica, i cap en tres ordres i una taula.

El símptoma que ho delata

Els problemes de fragmentació s'anuncien per la mida, mai per les adreces. El vostre parell respon un ping de 56 bytes durant una hora i després calla a 1400 bytes mentre el túnel continua aixecat i cap ruta no ha canviat. L'apretada de mans hi cap, la primera finestra TCP completa no, i la transferència s'atura segons després d'haver semblat sana.

Mesureu el sostre abans de tocar res, perquè un sostre no mesurat és el que perseguireu dues vegades. Envieu una sonda per sota de la mida sospitosa amb el bit do-not-fragment activat, ping -M do -s 1000 10.9.0.2, i repetiu-la després amb una mida que ja sabeu que és massa gran. Quan el canvi segueix la mida de la càrrega mentre la destinació no es mou, l'encaminament fa la seva feina i al pressupost li falta una capçalera.

Compteu cada capçalera una vegada, a la capa correcta

Partiu de l'MTU més petit del camí i no de la interfície del túnel, perquè la paret és per sobre dels dos extrems. WireGuard gasta 60 bytes en un transport exterior IPv4: 20 per a IP, 8 per a UDP i 32 per a la seva pròpia capçalera, i 80 bytes quan aquest transport és IPv6. Un wg0 de 1420 bytes guarda 20 bytes de marge sota els 1440 que un camí de 1500 bytes pot lliurar de veritat, i per això la xifra copiada d'una wiki encara hi encaixa. Dibuixeu tot el conjunt al diagrama, perquè qui canviï l'MTU després triarà un número rodó nou i heretarà el vostre error si no ho feu.

La cinquena fila és on fallen els pressupostos, perquè els 1400 bytes que porta una interfície imbricada ja inclouen els 40 bytes de capçaleres del paquet original. Només 1360 d'aquests bytes arriben al procés que llegeix el fitxer. Tracteu 1400 com a càrrega de l'aplicació, com us convida a fer qualsevol diagrama sense aquesta columna, i el dispositiu interior acaba 40 bytes massa generós contra una paret que no s'ha mogut.

Fixeu els dos MTU per separat

El portador i el dispositiu imbricat són objectes separats, així que cadascun necessita el seu propi valor. Apliqueu-los en aquest ordre, perquè el dispositiu imbricat no hereta res del portador:

ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400

La regla que val la pena memoritzar: MTU interior = MTU exterior - 20 quan el paquet que porta el túnel IPIP és IPv4, i - 40 quan qualsevol costat del paquet interior és IPv6, perquè la capçalera imbricada creix de 20 bytes a 40. Res més no pertany a aquesta resta. El sobrecost de WireGuard ja es va gastar quan vau triar 1420, i cobrar-lo dues vegades produeix un túnel que funciona perfectament i es queda lent mentre ningú no el mesura. Un desplegament on tots dos dispositius porten un 1400 rodó és l'empremta exacta d'aquest error.

IPv6 a qualsevol costat del paquet imbricat invalida cada xifra anterior, així que recalculeu en lloc de copiar un número d'un lloc semblant. Les capçaleres restades són de 40 bytes cadascuna quan IPv6 apareix al camí exterior o al datagrama original, i la xifra de càrrega baixa exactament tant.

La regla de tallafocs que probablement no necessiteu

Entre dos parells de WireGuard l'únic que hi ha al cable és UDP, així que una regla d'entrada per al protocol 4, el número que RFC 2003 assigna a l'encapsulació IPv4-dins-IPv4, ni crea el camí imbricat ni el manté viu. La capçalera IPIP viu dins de la càrrega xifrada, on cap tallafocs de vora no la veu. Obrir el protocol 4 igualment no compra res més enllà d'una via permesa més cap a l'amfitrió.

La política que esmenta les fonts i destinacions del paquet original pertany després de la desencapsulació, a les interfícies del túnel i a la taula d'encaminament. Posa-la allà i la regla de vora pot quedar tancada.

Què valida realment WireGuard

AllowedIPs jutja l'origen del paquet que WireGuard porta, i el que porta és el paquet encapsulat en IPIP. Un origen IPIP permès s'accepta fins i tot quan la capçalera interior anomena un amfitrió que preferiríeu no encaminar. L'origen original, doncs, no és el que el parell ha comprovat per vosaltres, i aquesta parella interior d'adreces necessita la seva pròpia aplicació després de la desencapsulació.

L'embolcall aporta estructura d'encaminament, no una segona capa de criptografia. Anomenar IPIP protecció extra dins de WireGuard descriu un disseny diferent.

Verifiqueu amb una escala, no amb un sol ping

Sondegeu mides que envoltin la frontera que heu calculat i confirmeu després què creu el nucli sobre tots dos dispositius. Amb 1360 bytes de càrrega més 40 bytes de capçaleres que fan 1400, el primer eco de sota hi cap i el segon se situa un byte més enllà del sostre:

ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0

Un pas net per sota del sostre i un fracàs a la primera mida per sobre volen dir que l'aritmètica es manté de punta a punta. Després torneu a executar la transferència que originalment s'havia encallat, perquè una sonda sintètica demostra el pressupost i no diu res sobre les mides d'escriptura del remitent. Si el camí imbricat encara es trenca a una mida que heu demostrat que hi cap, inspeccioneu la desencapsulació i les rutes de l'extrem llunyà abans de retallar deu bytes més de l'MTU.