Beágyazott VPN-alagutak: miért akad meg a belső a nagy csomagoknál

A DNS feloldódik, az SSH-munkamenet fennmarad, majd egy nagy feltöltés megfagy, miközben a ping ugyanahhoz a hoszthoz még válaszol. Ez a szétválás a csomagméretre utal, nem egy törött alagútra. A beágyazott alagutak olyan méreteknél érik el ezt, amelyeket egyik alagút sem érne el egyedül. A belső munkamenet rendben van; csak olyan csomagokat kap, amelyek már nem férnek bele.

Hová megy valójában az útvonal MTU-ja

Minden beágyazás bájtokat költ, mielőtt a következő réteg sorra kerülne. Egy Ethernet-útvonal 1500 bájtot kínál a külső csomagnak, és a külső alagút elveszi a részét, mielőtt bármi belül címezhető lenne. Egyetlen becsült overhead-érték pontosan annyival lesz hibás, amennyi számít.

Sorolja fel a rétegeket sorrendben: hozzáférési útvonal, külső szállítás, külső alagút, belső szállítás, belső alagút, alkalmazás. Minden fejlécet egyszer számoljon, és tartsa az UDP-t külön az alagút saját fejlécétől és címkéjétől.

Két WireGuard-réteg, egyszer számolva

Vegyen egy IPv4 hozzáférési útvonalat, benne egy WireGuard-alagúttal egy másikban. A külső réteg 20 bájt IPv4-be, 8 bájt UDP-be és 32 bájtba kerül a WireGuard adatfejlécért és annak hitelesítési címkéjéért. Ezen belül a belső alagútnak saját 20 bájtos IPv4-fejlécre és 8 bájtos UDP-fejlécre van szüksége a második 32 bájt WireGuard-többlete előtt. Ami marad, abban egy IPv4-fejléc, egy TCP-fejléc és az adatok kapnak helyet. Egy külső IPv6-útvonal 20 helyett 40-be kerül, és 1320-at hagy.

A számtan 1340 bájtra fut ki. Egy réteg ugyanezen szabályok szerint 1400-at hagy a TCP hasznos terhelésének, ami 1500 mínusz 20, 8, 32, 20 és 20, a 60 bájtos különbség pedig pontosan a belső beágyazás, amelyet a második alagút hozzáad.

Alkalmazza az 1400-at egy beágyazott útvonalra, és a belső alagútból 60 bájt hiányzik, láthatatlanul, amíg a csomag elég nagy nem lesz ahhoz, hogy szükség legyen rájuk. A kitöltés és a protokoll saját töredezettség-kezelési lehetősége újra elmozdítja a számokat, ezért bízzon a táblázatban.

Az MTU, az MSS és a töredezettség különböző helyeken hat

Az interfész MTU-ja korlátozza, mit fog kibocsátani az interfész, míg a TCP MSS-szorítása megváltoztatja, mit hajlandó küldeni egy TCP-partner. A szorítás kijavítja a TCP-munkameneteket és semmit sem tesz egy nagy UDP-datagramért, így egy javítás sikeresnek látszik az egyik alkalmazásnál, és csendben elvéti a következőt. A protokoll saját töredezettség-kezelési lehetősége harmadik kar a saját hibáival. Az interfész MTU-ja a szokásos első lépés és a legdurvább.

A hidalt és a routolt alagutak különböző kereteket szállítanak, ezért egy másik telepítés számai ritkán vihetők át. Az útvonal-MTU felderítése, amelyet a RFC 8201 ír le, csak addig segít, amíg az általa igényelt ICMP-üzeneteket átengedik.

A hiányos réteg megtalálása

Ellenőrizze az egyes alagutakat külön a beágyazás előtt, ha a követelmények lehetővé teszik az összehasonlítást. Egy rögzített méretű próba eldönti: ping -M do -s 1472 -c 3 10.8.0.1 teljes 1500 bájtos IPv4-csomagot küld azon a rétegen belül. Adja hozzá a második réteget, és ismételje meg ugyanazt a próbát, hogy minden hiba egy ismert változáshoz tartozzon.

Amikor egy átvitel elakad, egyszerre egy dokumentált paramétert változtasson, és jegyezze fel a hibás méretet. Ellenőrizze a visszautat is, mert a beágyazott útvonal-rekurzió elég pontosan utánozhatja a csomagméret-problémát ahhoz, hogy egy délutánba kerüljön. Egy szűrt ICMP-válasz elrejtheti a valódi korlátot, ezért a próba fontosabb az okoskodásnál.

Írja a büdzsét oda, ahol a következő ember megtalálja

A rétegenként egy sort tartalmazó táblázat túlél egy ökölszabályt. Tartsa az alagút ábrája mellett, hogy senki ne számolja újra a számtant nyomás alatt.

A több alagút több függőséget jelent, ezért a visszaállítási terv megérdemli a helyét a büdzsé mellett. Ha a számok még mindig nem jönnek ki, mérje meg az útvonalat, ahelyett hogy újra találgatna. A cél egy szám, amelyet meg tud védeni, nem egy, amelyet megjegyez.