IPv6-forgalom a VPN mellett: a szivárgó útvonal megtalálása

Két teszoldal ellentmond egymásnak: az egyik a szolgáltató címét jelenti az alagúton keresztül, a második a házi előtagodat, és a kézenfekvő következtetés az, hogy a VPN szivárog. Ez a következtetés kihagy egy lépést, mert a két jelentés két különböző útválasztási döntést gyakorolt, és csak az egyiküknek kellett volna az alagútba kerülnie. A hézag általában valódi, és lefedettségi probléma, nem törött alagút. Három kérdés dönti el: melyik folyam ment ki valójában, melyik útvonalat választotta hozzá a kernel, és milyen viselkedést szánt a kliens.

Ebben a sorrendben dolgozz. Ha nem ebben a sorrendben válaszolsz rájuk, hosszú vita lesz arról, hogy hibás-e a kliens, holott a valódi válasz az, hogy soha nem települt IPv6-útvonal.

Melyik folyam ment ki valójában, és melyik adapteren

Kezdd egy teszttel, amely megnevezi a használt családot, majd írd fel az alkalmazást, a hozzáférési hálózatot, az érvényben lévő profilt és azt, hogy kínál-e egyáltalán IPv6-ot a kapcsolat. Ez a négy tény teszi összehasonlíthatóvá két futást, és a negyediket felejtik el az emberek: a v6 előtag nélküli hálózat nem tud v6-ot szivárogtatni, és a hálózat, amely később hozzáad egyet, megváltoztatja a választ.

Családonként egy kérést küldj ahelyett, hogy betöltenél egy oldalt és elolvasnád az eredményét. Egyetlen oldal keverhet v6- és v4-erőforrásokat, egy háttérfolyamat másképp viselkedhet, mint az előtted lévő lap, és egy gyorsítótárazott válasz túlélheti a hálózatváltást, amelyet tesztelni próbálsz. Rögzítsd a tesztelt célt és jegyezd fel, hogy az ismételt futás ugyanazt mérje.

A kernel által választott útvonal kiolvasása

Az útvonaltábla arra a kérdésre válaszol, amelyre a böngésző nem tud. Kérdezd meg a rendszertől, hová menne egy adott cél, és vedd bele a házirend-szabályokat csakúgy, mint a látható alapértelmezést, mert bármelyik felülírhatja:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Egy konkrétabb előtag a szokásos oka annak, hogy egy cél az alagúton kívül marad, miközben minden más bent marad, és egy házirend-szabály ugyanezt teheti bármely útvonalnál magasabb prioritással. Olvasd ki a metrikát is, mert az azonos előtag két bejegyzése metrika alapján dől el, nem a képernyőn látható sorrendjük alapján. Windowson az egyenértékű lista Get-NetRoute -AddressFamily IPv6, metrika szerint rendezve, hogy megfeleljen a döntési sorrendnek. Egy szabály, amely a táblázatban helyesnek tűnik, még mindig veszíthet egy alacsonyabb számú házirend-szabállyal szemben, ezért a szabálylista ugyanabban a lélegzetben tartozik az útvonallistához.

Honnan jön a kliens IPv6-házirendje

Egy kliens épülhet arra, hogy v6-ot vigyen át az alagúton, hogy elutasítsa, vagy hogy engedjen egy megnevezett kivételt, és ez a három szándék három különböző helyes eredményt ad. Olvasd el a profilt és a kliens saját dokumentációját, mielőtt szivárgásnak nevezel egy megfigyelést, mert az a kliens, amely blokkolja a v6-ot, miközben az operációs rendszer továbbra is szomszédkeresést küld a fizikai kapcsolaton, a tervezés szerint viselkedik.

Az alagútból szándékosan kizárt alkalmazás más eset, mint egy család, amelyet az alagút soha nem vitt. Az első döntés egy programról, a második hézag a lefedettségben, és a javítás ennek megfelelően különbözik. Olvasd el a kliens kizárt programjainak listáját, mielőtt olyan útvonalat keresnél, amelynek soha nem lett volna szabad léteznie.

Szűk megfigyelés, amikor a táblázat ellentmond

Amikor az útvonalkeresés kétértelmű, egyetlen interfész-megfigyelés a hoston eldöntheti, de csak akkor, ha a kérdésre irányul. A VPN végpontja felé menő forgalom tervezés szerint átmegy a fizikai adapteren; az számít, hogy a máshová címzett alkalmazásfolyam is megjelenik-e ott. Szűrd a rögzítést a tesztelt célra, ahelyett hogy mindent összegyűjtenél.

Egy széles rögzítés sokkal több személyes forgalmat tár fel, mint amennyit az az egy kérdés megkíván. Kevésbé tisztán is válaszol, mert a téged érdeklő folyam összefüggéstelen kapcsolatok áradatába temetve érkezik. Szűrj a tesztelt célra, állj meg néhány csomag után, és töröld a rögzítést.

Három mód a hézag bezárására

Vidd át a családot az alagúton, blokkold a kliensben, amikor az alagút nem tudja vinni, vagy jegyezz fel szándékos kivételt egy felelőssel és egy felülvizsgálati dátummal. Mindegyik védhető, és az egyetlen védhetetlen dolog az, hogy a választás implicit marad, mert az implicit választás pontosan az, ami a szivárgás. Ha az alagútnak egyáltalán nincs v6-kijárata, a v6 elutasítása a kliensben egyszerre őszinte és tesztelhető. Az számít, hogy a választás ott legyen leírva, ahol a következő ember megtalálja, ne pedig hat hónappal később a viselkedésből következtessék ki.

Ismételd meg az ellenőrzést újracsatlakozás után és hálózatok közötti váltás után, mert az előző kapcsolathoz telepített útvonal túlélheti a változást. Utána jegyezd fel a célt, a választott útvonalat, a kliens házirendjét és a teszt által használt családot, hogy a következő ember döntést olvasson ahelyett, hogy újra levezetné. RFC 7359 a kettős verem szivárgását tervezési problémaként dokumentálja, nem hibaként, és ez a hivatkozás, amelyet idézni kell, amikor valaki azt állítja, hogy egy működő v4-alagút mindent lefed.