WireGuard staak: ’n MTU-perk of ’n ontbrekende deurstuur-reël?

Die gewoonte is om die MTU te verlaag sodra WireGuard hom misdra, en daardie gewoonte verberg ’n ander fout. ’n Deurgang wat nie wil deurstuur nie en ’n pad wat nie groot pakkette wil dra nie, lewer onderskeibare patrone: die een faal in albei rigtings en by elke grootte, die ander oorleef klein versoeke en sterf op grootes. Bepaal watter vorm jy het voordat jy enige getal verander. Die toets is goedkoop en dit verwyder die helfte van die moontlike oorsake.

Twee foute, twee verskillende vorms

’n Deurstuurprobleem verskyn onmiddellik anderkant die bediener. Die handdruk slaag, die tonneladres antwoord, en niks agter die deurgang is bereikbaar nie, selfs nie met ’n klein versoek nie. Die pakket het die bediener bereik en is nie oorgedra nie, of die antwoord het geen roete terug gehad nie.

’n Grootteprobleem verskyn net bo ’n drempel. DNS, ’n TCP-handdruk en ’n klein API-oproep werk almal, terwyl ’n lêer-aflaai of ’n groot antwoord hang. Die pakkette wat pas, het van punt tot punt gereis, en die wat nie gepas het nie, is êrens laat val sonder ’n bruikbare verslag.

Daardie beskrywings wys na verskillende mense en verskillende konfigurasielêers, en daarom is die vorm meet eerder as raai die moeite werd. ’n Enkele ping na die deurgang kan hulle nie skei nie.

Sluit deurstuur uit voordat jy iets verklein

Toets ’n bestemming anderkant die deurgang, nie die deurgang self nie. ’n Ping na die bediener se tonneladres bewys net dat die koppelvlak op is en dat jy die masjien kan bereik wat die tonnel beëindig. Verkeer vir die wyer netwerk hang daarvan af dat IP-deurstuur op daardie masjien geaktiveer is en dat ’n vuurmuur die deurgestuurde vloei toelaat. Albei moet waar wees, en as een van hulle vals is, lewer dit dieselfde stilte.

Terugroetering maak net soveel saak. As die bestemmingsnetwerk nie weet hoe om die kliënt se tonneladres te bereik nie, kom die versoek aan en verdwyn die antwoord, en die kliënt rapporteer ’n tydsverloop wat identies lyk aan ’n laat-val deurstuur.

Waar die ontwerp adresvertaling gebruik, is die vertaalreël deel van daardie terugpad. Om dit te verwyder terwyl jy ’n MTU-probleem jaag, verander een werkende ontwerp in ’n gebreekte een, so lees die bestaande reëls voordat jy hulle wysig.

Meet waar die breek begin

Lees eers die deurstuurtoestand en die filterreëls. Dit is lees-alleen kontroles en hulle beantwoord die goedkoop vraag:

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

Probeer dan groottes met die don’t-fragment-biet, vanaf die kliënt, na ’n gasheer anderkant die deurgang:

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

As die eerste probeer werk en die tweede faal met ’n fragmenteringsfout, vertel die pad jou sy bruikbare grootte. As nie een van hulle werk nie, kyk jy na deurstuur of roetering, en MTU is nie die veranderlike om te wysig nie.

Herstel die laag wat jy bewys het

Wanneer deurstuur die fout is, is die regstelling ’n deurstuur-reël of ’n roete, so nou uitgedruk as wat die ontwerp toelaat. Wanneer grootte die fout is, is die regstelling ’n MTU wat die inkapseling op hierdie spesifieke pad in ag neem, toegepas op die koppelvlak wat dit nodig het eerder as op elke adapter in die vloot.

Hoe dit ook al sy, herhaal dieselfde taak daarna teen dieselfde bestemming. As die oorspronklike groot oordrag nou voltooi, het die verandering die laag aangespreek wat gefaal het. As net die klein probeer verbeter het, het jy ’n simptoom behandel en die werklike perk staan nog.

Skryf neer watter vorm jy voor die verandering gesien het. Daardie een reël, langs die oplossing aangeteken, is wat die volgende persoon daarvan weerhou om ’n MTU te verlaag wat nooit die probleem was nie.