Monero VPN-en át: melyik változik a három hálózati útvonal közül?

Nyissa meg a tárcát, indítsa el a démont, és rajzoljon három nyilat, mielőtt bármit engedélyezne. Az egyik nyíl a tárcától egy csomópont RPC-portjáig fut, a másik a démon peer-szinkronizációját szállítja, a harmadik pedig a helyben beküldött tranzakciókat viszi egy továbbítási útvonal felé. Ezek különböző beállítású kapcsolatok, és egy VPN vagy anonimitási hálózat lefedhet közülük egyet, kettőt vagy egyet sem.

Járja végig az útvonalakat abban a sorrendben, ahogyan a szoftver megnyitja őket. Az, hogy minden nyilat felcímkéz a céljával és az átvitelével, teszi később ellenőrizhetővé az adatvédelmi állítást. A sorrend számít, mert a későbbi állítás általában csak egyetlen útvonalat fed le.

Kezdje a tárca és a csomópont közötti kapcsolat megrajzolásával

A távoli csomóponttal beszélő tárca RPC-kéréseket küld annak a csomópontnak a címére és portjára. A helyi démonnal rendelkező tárca viszont a loopback-interfészen keresztül beszél. Ezek különböző bizalmi viszonyok, még akkor is, ha a hétköznapi beszédben mindkettőt „a csomópontnak” nevezik.

Jegyezze fel a címet, a portot és az átvitelt, amelyek használatára a tárca be van állítva. Ha a tárcának saját proxybeállítása van, azt külön rögzítse a démon beállításaitól; egy folyamat beállítása nem állítja be a másikat.

Itt válik csábítóvá egy nyilvános RPC-végpont is. Ha a csomópont RPC-szolgáltatását a diagram egyszerűsítése érdekében kitesszük, egy hálózati útvonalat cserélünk támadási felületre. Tartsa a tárca és a csomópont közötti kapcsolatot privát útvonalon vagy a loopback-interfészen, és dokumentálja, melyik az. Az a diagram, amely elrejti ezt a kitettséget, rosszabb, mint a diagram hiánya.

Ezután kövesse a démon peer-forgalmát

A szinkronizáló démon kimenő kapcsolatokat nyit a peer-ek felé, és a láncadatokat a peer-to-peer portján keresztül cseréli. Ez a forgalom nem a tárca RPC-kapcsolata, és nem halad automatikusan a tárca proxyján keresztül. A démon saját hálózati beállításait és a gazdagép útválasztási táblázatát követi.

Jegyezze fel a peer-portot, a kapcsolatok számát, és azt, hogy a démon be van-e állítva proxy használatára a peer-forgalomhoz. Ezután ellenőrizze a gazdagép útvonalát egy minta peer-címhez. Ha a VPN elfogja az alapértelmezett útvonalat, a peer-kapcsolatok valószínűleg azt használják; ha a démon egy adott interfészhez van kötve, talán nem. Ez a két tény dönti el a nyilat.

A megfigyelő kérdése ezzel az útvonallal megváltozik. A VPN elrejti a peer-kapcsolatokat a helyi hozzáférési hálózat elől, de a VPN végpontja és maguk a peer-ek más képet látnak. Egyik megfigyelés sem bizonyítja, hogy a tárca kérései ugyanazon az útvonalon haladtak.

Ezután különítse el a tranzakciók továbbítási útvonalát

A helyben beküldött tranzakciók egy beállított relén vagy proxyn keresztül továbbíthatók a hálózat felé. A Monero démon jelenlegi dokumentációjában ez az opció csak azt a tranzakció-továbbítási forgalmat küldi a proxyn keresztül, amelyet arra irányít. Nem alakít minden RPC-, tárca- és szinkronizációs kapcsolatot proxyn átmenő forgalommá.

A projekt anonimitási hálózatokról szóló dokumentációja kísérletiként írja le a Tor és I2P integrációját, és meghatározza a továbbítási viselkedés hatókörét. Azt a verziót olvassa el, amelyet ténylegesen futtat, mert a régebbi viták Kovrihoz hasonló neveket használnak, és olyan összetevőket írnak le, amelyek már nem léteznek ugyanabban a formában.

Tartsa külön a továbbítási útvonalat a diagramon. Egy proxyn keresztül távozó tranzakciónak, miközben a tárca egyenleglekérdezései távoli csomópontot használnak, két különböző megfigyelője van, és az a tény, hogy a tranzakció proxyn ment át, semmit sem mond a lekérdezés útvonaláról.

Csak akkor adja hozzá a VPN-t, ha a három útvonal már fel van címkézve

A megrajzolt nyilakkal jelölje meg, melyeket szállítja valójában a VPN. A teljes alagútos VPN elfogja a gazdagép alapértelmezett útvonalát, így az alapértelmezettet követő kapcsolatok azt használják. Egy osztott alagút, egy kötött interfész vagy egy adott címen kilépő proxy néhány nyilat az alagúton kívül hagyhat.

Most mondja ki kifejezetten a megfigyelő modelljét. Olyan kialakításban, ahol egy anonimitási hálózati kapcsolat a VPN-en belül fut, a helyi hozzáférési hálózat a külső VPN-kapcsolatot látja, míg a VPN oldala a továbbhaladó kapcsolatot. Ez a megfigyelő változása, nem annak bizonyítéka, hogy az azonosító jelek eltűnnek.

Ellenőrizze a hiba viselkedését ugyanazon végigjárás részeként. Ha a VPN kiesik, visszaesik-e a démon közvetlen peer-kapcsolatra, folytatja-e a tárca a távoli csomópont kérdezését, és zárt állapotban hibázik-e a továbbító proxy? Ha a blokkolás nincs beállítva, az újracsatlakozás általában új közvetlen kísérletet jelent, nem csendet.

Ellenőrizze azokat az útvonalakat, amelyeket úgy gondol, hogy beállított

Használja a gazdagép saját eszközeit: olvassa ki az útvonalat minden célhoz, vizsgálja meg a figyelő és a létrejött socketeket, és erősítse meg, melyik folyamat birtokolja az egyes kapcsolatokat. Ezt akkor tegye, amikor a tárca, a démon és a továbbítás mind fut, mert egy csak indításkor létező útvonal eltűnhet újracsatlakozás után.

Ismételje meg a VPN újracsatlakozása után és a démon újraindítása után. Hasonlítsa össze a célokat és az átviteleket a diagrammal. Ha egy nyíl elmozdult, az adatvédelmi modell is elmozdult vele, még akkor is, ha minden folyamat továbbra is egészségesnek jelenti magát.

Jegyezze fel a három célt, mindegyik átvitelét és azt a megfigyelőt, amelyik elől el akarja rejteni őket. Egy rövid, megnevezett megfigyelőkkel ellátott útvonaltérkép hasznosabb egyetlen VPN-jelzőnél, amikor több független kliens fut egy gépen.