WireGuard bllokohet: një kufi MTU apo një rregull përcjelljeje që mungon?

Zakoni është të ulet MTU sapo WireGuard fillon të sillet keq, dhe ky zakon fsheh një defekt tjetër. Një portë që nuk përcjell dhe një rrugë që nuk mbart paketa të mëdha prodhojnë modele të dallueshme: njëra dështon në të dy drejtimet dhe në çdo madhësi, tjetra mbijeton kërkesat e vogla dhe vdes në të mëdhatë. Përcaktoni cilën formë keni përpara se të ndryshoni çdo numër. Testi është i lirë dhe heq gjysmën e shkaqeve të mundshme.

Dy dështime, dy forma të ndryshme

Një problem përcjelljeje shfaqet menjëherë pas serverit. Shtrëngimi i duarve funksionon, adresa e tunelit përgjigjet, dhe asgjë prapa portës nuk arrihet as me një kërkesë të vogël. Paketa arriti në server dhe nuk u përcoll, ose përgjigja nuk kishte rrugë kthimi.

Një problem madhësie shfaqet vetëm mbi një prag. DNS, një shtrëngim duarsh TCP dhe një thirrje e vogël API funksionojnë, ndërsa shkarkimi i një skedari ose një përgjigje e madhe varret. Paketat që hynë udhëtuan nga njëri skaj në tjetrin, dhe ato që nuk hynë u hodhën diku pa një raport të përdorshëm.

Ato përshkrime tregojnë njerëz të ndryshëm dhe skedarë konfigurimi të ndryshëm, prandaj matja e formës vlen më shumë se një hamendje. Një ping i vetëm drejt portës nuk mund t’i ndajë ato.

Përjashtoni përcjelljen përpara se të zvogëloni çdo gjë

Testoni një destinacion përtej portës, jo portën vetë. Një ping drejt adresës së tunelit të serverit dëshmon vetëm se ndërfaqja është aktive dhe se arrini makinën që përfundon tunelin. Trafiku për rrjetin më të gjerë varet nga përcjellja IP e aktivizuar në atë makinë dhe nga një firewall që lejon rrjedhën e përcjellë. Të dyja duhet të jenë të vërteta, dhe nëse njëra është e rreme, prodhohet i njëjti heshtje.

Rrugëtimi i kthimit ka po aq rëndësi. Nëse rrjeti i destinacionit nuk e di se si të arrijë adresën e tunelit të klientit, kërkesa arrin dhe përgjigja zhduket, dhe klienti raporton një afat kohor që duket njëlloj si një përcjellje e hedhur.

Aty ku projektimi përdor përkthimin e adresave, rregulli i përkthimit është pjesë e asaj rruge kthimi. Heqja e tij ndërsa ndiqni një problem MTU e kthen një projektim që funksionon në një të prishur, prandaj lexoni rregullat ekzistuese përpara se t’i modifikoni.

Matni ku fillon thyerja

Fillimisht lexoni gjendjen e përcjelljes dhe rregullat e filtrimit. Këto janë kontrolle vetëm leximi dhe u përgjigjen pyetjes së lirë:

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

Më pas provoni madhësi me bitin don’t-fragment, nga klienti, drejt një hosti përtej portës:

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

Nëse prova e parë funksionon dhe e dyta dështon me një gabim fragmentimi, rruga po ju thotë madhësinë e saj të përdorshme. Nëse asnjëra nuk funksionon, po shikoni përcjellje ose rrugëtim, dhe MTU nuk është ndryshorja që duhet ndryshuar.

Riparoni shtresën që vërtetuate

Kur përcjellja është defekti, korrigjimi është një rregull përcjelljeje ose një rrugë, e shprehur aq ngushtë sa projektimi lejon. Kur madhësia është defekti, korrigjimi është një MTU që merr parasysh inkapsulimin në këtë rrugë të veçantë, i zbatuar në ndërfaqen që ka nevojë dhe jo në çdo përshtatës të flotës.

Në çdo rast, më pas përsëritni të njëjtën detyrë drejt të njëjtit destinacion. Nëse transferimi i madh origjinal tani përfundon, ndryshimi adresoi shtresën që dështonte. Nëse u përmirësua vetëm prova e vogël, trajtuat një simptom dhe kufiri i vërtetë është ende në vend.

Shkruani cilën formë vëzhguat përpara ndryshimit. Ai një rresht, i regjistruar pranë korrigjimit, është ai që e pengon personin tjetër të ulë një MTU që nuk ishte kurrë problemi.