Küldhetik a DHCP-útvonalak a forgalmadat a VPN-alagút mellett?

A titkosítás egy határon kezdődik, és ez a határ egy útválasztási döntés, amelyet a végpont hoz meg, mielőtt bármely csomag beágyazódna. Egy hálózat, amely soha nem látja a kulcsaidat, mégis adhat a gépednek olyan útvonalat, amelyet jobban kedvel, mint magáét az alagútét. Itt két hibát kevernek össze: egy már az alagútban lévő csomag olvasását, és egy soha oda nem tett csomag elterelését.

A megkülönböztetés azért számít, mert a második hiba olcsóbban előkészíthető és sokkal könnyebb elkerülni az észrevételt. Úgy jelenik meg, mint egy kérés, amely a rossz interfészen ment ki, miközben a kliens még egészséges kapcsolatot jelentett.

Két mód, ahogy egy hálózat hatással lehet rád

Az alagútba érkező csomag haszna rejtve van minden előtte álló ugrás elől, és ez a védelem akkor is tart, ha az útvonal meglep. Az a csomag, amely soha nem érkezik meg az alagútba, közönséges kérés a címedről, oda küldve, ahová az útvonaltábla mutatott. Az első hibához törött titkosítás vagy kompromittált partner kell, a másodikhoz csak egy konfigurációs üzenet, amelyben a géped megbízni döntött. Ez az aszimmetria az oka, hogy az útválasztási fele saját átvizsgálást érdemel.

Az útvonalon lévő eszköznek nincs szüksége a kulcsaidra a második eset befolyásolásához. Csak arra van szüksége, hogy a végpontod elfogadjon egy útvonalat, egy feloldót vagy egy házirend-szabályt, amely ilyet állít elő.

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

Honnan jöhet útvonal, mielőtt az alagút létezik

A DHCP többet oszt ki, mint egy címbérletet. Az osztály nélküli statikus útvonal beállítás cél-előtagokat és következő ugrásokat hordozhat, és RFC 3442 megvizsgálja egy hibás routercím biztonsági következményeit: eltérített forgalmat, szolgáltatásmegtagadást vagy az útvonalon ülő megfigyelőt. Egy kliens, amely ezeket az útvonalakat az alagút felállása előtt elfogadja, olyan előnyben részesített útvonalhoz juthat, amelynek semmi köze a szolgáltatódhoz.

Ezek egyike sem teszi egyetemessé az útvonal-injektálást. A kliensnek el kell fogadnia a beállítást, az előtagnak le kell fednie az általad fontosnak tartott forgalmat, a választott következő ugrásnak elérhetőnek kell lennie, és a kényszerítési házirendnek engednie kell a csomagot azon az úton ki. Vedd el bármelyiket, és ugyanaz a válasz ártalmatlanná válik. Ezért viselkedhet két gép ugyanazon a hálózaton másként, hiszen nem ugyanazt a klienst, ugyanazt a házirendet vagy akár ugyanazt a címcsaládot futtatják.

Az IPv6 saját kört érdemel, mert a routerhirdetések más kódon keresztül hordozzák az alapértelmezett útvonalat, mint a DHCPv4 beállítás. Az a teszt, amely csak a v4 táblát vizsgálja, nem fedte le.

Ellenőrizd az útvonalat, amelyet a kernel valóban választ

Az útvonal-lekérdezések megválaszolhatók, ezért kérdezd őket ahelyett, hogy állapotlámpából következtetnél. Az alábbi parancsok egy célhoz választott útvonalat és forrást mutatják, valamint azokat a szabályokat, amelyek felülírhatják a fő táblát. Futtasd őket kapcsolódva, majd újra csatlakozás után, mert a bérlet megújítása megváltoztathatja a választ.

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

Két dolgot keress a kimenetben: az útvonalban megnevezett interfészt és a választott forrás-címet. Az alagút-útvonal az alagút-eszközt nevezi meg, a szivárgott útvonal a fizikait, és a különbség látható anélkül, hogy bármit is visszafejtenél. Ha a válasz futások között változik, őrizd meg mindkét kimenetet, és hasonlítsd össze az azokat létrehozó szabályokat.

Ne állj meg az alapértelmezett útvonalnál. Egy alkalmazás-kivétel, egy osztott alagút előtag vagy egy második házirend-szabály egy adott célt az alagút mellett vihet el, miközben az alapértelmezett még befelé mutat.

Döntsd el, hol éljen a kényszerítés

Három feltétel dönti el, hogy elég-e az ügyféloldali kényszerítés, vagy valami rajta kívül kell. Ha a kliens minden általad használt címcsaládhoz telepít és véd útvonalakat, az alapértelmezettet birtokló alagút általában elég. Ha a gépnek helyi erőforrásokat kell elérnie, miközben minden más az alagútban marad, ezeket a kivételeket fel kell sorolni és birtokolni, ahelyett hogy a hozzáférési hálózat hirdetésére bíznád. És ha a platform alkalmazásonként interfészhez tudja kötni a forgalmat, az a kötés erősebb garancia, mint egy útvonal, amelyet bármi felülírhat.

Bármit is választasz, írd le a döntést ott, ahol a konfiguráció él. Egy szabály, amely azért létezik, mert valaki egy incidens közben begépelte, nem éli túl a következő újraindítást, ezért tartsd szűken a helyi és indítási kivételeket, és jegyezd fel, miért létezik mindegyik.

Minden kliensfrissítés és minden hálózati változás után futtasd újra a keresőparancsokat, és hasonlítsd össze az utoljára rögzített kimenettel. Az útvonaltábla a kényszerítés határa, ezért úgy is kezeld.