Kion VPN-protokolo povas kaj ne povas pruvi pri retumado

Antaŭ ol elekti protokol-kolektilon, decidu, kiun eventon la revizio devas konstati. Demandi, kiu VPN-seanco kontaktis celadreson, estas alia demando ol demandi, kiu persono malfermis apartan paĝon. Ambaŭ postulas malsamajn riordojn, malsamajn kunligojn kaj malsamajn nivelojn de certeco. Konekta protokolo de OpenVPN respondas la unuan kaj ne povas respondi la duan.

Nomu la eventon antaŭ ol elekti kolektilon

Seanca riordo montras akceptitan identecon, komencan kaj finan tempon kaj adreson, kiun la servilo atribuis laŭ sia propra politiko. Solvila protokolo montras, ke nomo estis demandita ĉe tiu solvilo. Flua riordo montras adresojn, pordojn, protokolon kaj tempon, kaj aplikaĵa protokolo montras la transakcion, kiun tiu aplikaĵo efektive traktis. Neniu el tiuj kvar anstataŭas alian.

Ĉiu el ili konstatas unu eventon kaj lasas la aliajn malfermitaj. Skribi la demandon unue malhelpas vin kunmeti rakonton, kiun la datumoj ne povas subteni.

journalctl -u [email protected] --since today | grep -i 'peer info\|assigned'
cat /etc/openvpn/server/openvpn-status.log | head -20
conntrack -L -p tcp --dport 443 2>/dev/null | head -20

La unua komando montras seancajn eventojn el la serva protokolo. La dua presas la nunan klientliston kun atribuitaj adresoj, kio estas la mapado, de kiu dependas revizia kunligo. La tria montras vivan fluan staton, utilan nur dum la konekto ankoraŭ ekzistas.

Serĉo ne estas vizito

Retumilo solvas nomojn spekulativeme, kaŝmemorigas respondojn kaj reuzas ilin sen demandi la observatan solvilon denove. Nomo en solvila protokolo do pruvas serĉon, ne viziton. DNS super HTTPS plilarĝigas tiun breĉon, ĉar retumilo agordita por ĝi sendas siajn demandojn tien, kie via ordinara protokolilo neniam vidas ilin.

Celadresoj solaj ne estas pli bonaj. Unu adreso povas gastigi multajn senrilatajn retejojn, inversa DNS estas konjekto, ne rekonstruo, kaj hostnomo videbla dum TLS-manpremo ne estas la petvojo ene de la ĉifrita seanco.

Por precizaj transakcioj vi bezonas la proprajn eventajn riordojn de la aplikaĵo aŭ prokuran dezajnon, kiu estas eksplicite subtenata por protokolado. CONNECT-tunelo donas al prokuro la celon kaj la volumon, ne la paĝajn vojojn ene de ĝi. Administra aliro al la reto ne estas permeso silente anstataŭigi la fidmodelon de la aplikaĵo.

Kunligu identecon kaj tempon antaŭ ol nomi personon

Flua riordo kun interna fontadreso signifas nenion ĝis tiu adreso estos kunligita al seanco samtempe. Adresoj estas reuzataj, kaj la sama adreso povis aparteni al alia seanco unu horon pli frue. Statika atribuo estas unu maniero konservi la ligon, ne la sola.

Tradukaj limoj pli malfortigas la kunligon. Se pluraj aparatoj jam dividis unu fontadreson antaŭ via observpunkto, la plej bona, kion vi povas identigi, estas la komuna enirporda seanco kaj ne unu aparato. Atestilo aŭ konto uzata de pluraj personoj havas la saman efikon.

Registru tempzonojn, horloĝfontojn, observpunktojn kaj ĉiun tradukan paŝon. Mankantaj riordoj povas signifi, ke flua riordo eksvalidiĝis, ke sensilo estis preterpasita aŭ ke aplikaĵa protokolo estis malŝaltita. Foresto ne estas pruvo, ke nenio okazis.

Poste difinu la minimumajn kampojn, la permesitajn legantojn kaj la konservan periodon por la deklarita celo. Korelacio kaj malĝusta atribuo estas dezajnaj demandoj, ne postpenso, kaj metadatumoj, kiuj identigas personojn, meritas la saman protekton kiel la identeca mapado, de kiu ili dependas.

Testu la revizion per agado, kiun vi kontrolas

Generu permesitan trafikon, kies seancn kaj aplikaĵon vi jam konas, poste kontrolu, kion ĉiu riordo efektive kaptis. Faru serĉon sen ŝargi la paĝon, ŝargu paĝon el la kaŝmemoro kaj malfermu konekton tra prokuro, kaj vidu, kiuj eventoj aperas.

Raportu la eventon, kiun la pruvoj subtenas, kaj diru, kion ili ne kovras. Modesta riordo kun deklarita amplekso trapasas revizion; ambicia retumhistorio kunmetita el konjektoj ne trapasas.