Hogyan ismerjünk fel aktív VPN-alagutat kódból bármely platformon
Létezik-e az alagút, ezen a célon halad-e át, vagy a távoli vég válaszol? Ez három különböző ellenőrzés és három különböző jel.
„Be van kapcsolva a VPN?” valójában három kérdés egyetlen mondatban. Hogy melyikre van szüksége a kódjának, az az első döntés, és éppen ezt hagyja ki a legtöbb megvalósítás. Létezik-e alagút ezen az eszközön, az erre a célra irányuló forgalom kimegy-e rajta, vagy a távoli vég a várt identitással válaszol. Válassza ki a tulajdonságot, majd a jelet, amely méri, végül írja be a naplóba, melyiket mérte valójában.
Három tulajdonság, három jel
Egy-egy sorba tömörítve a három kérdésnek három különböző válasza van. Az alábbi táblázat maga a döntés, nem annak összefoglalása.
| Property | Signal that answers it | What it still leaves open |
|---|---|---|
| Existence | The platform's own connection state: RAS on Windows, NetworkManager on D-Bus on Linux, scutil on macOS | Tunnels of a type the platform does not manage, which includes most third-party clients |
| Path | A route lookup for the one destination, or a scoped proxy or interface key that names the tunnel | Whether the far end is the peer you trust |
| Identity | An authenticated response from the far end, or a source-address policy applied on the server | Which local interface carried the packets |
Olvassa el lassan az utolsó sort. Egy válaszoló privát hoszt azt bizonyítja, hogy valami válaszolt, nem azt, hogy a válasz az alagúton keresztül érkezett, és semmit nem mond arról, ki van a másik végén. Ha a szükséges tulajdonság az útvonal, mérje az útvonalat.
Létezés: a platform saját állapota
A Windows ezt a natív profilok esetében a Remote Access Service API-n keresztül válaszolja meg. A RasEnumConnections felsorolja, mi van csatlakoztatva, a RasGetConnectStatus egy bejegyzés állapotát jelenti, a RasGetLinkStatistics pedig sebességet, bájtszámlálókat és a kapcsolat korát adja hozzá. A korlátok a lényeg: az OpenVPN, a WireGuard és a szállítói kliensek soha nem regisztrálnak RAS-kapcsolatot, ezért az ilyen típusú egészséges alagút üres listát mutat, és a naiv kód leállítottnak jelenti.
A Linux asztalok ugyanezt a tulajdonságot a NetworkManageren keresztül teszik elérhetővé D-Buson, ahol a PropertiesChanged a VPN-kapcsolat objektumán eseménnyé alakítja az ellenőrzést, és a State tulajdonság jelenti, amikor a kapcsolat eléri a csatlakoztatott állapotot. Héjból a nmcli connection show --active ugyanezt az információt olvassa, és debug közben éppen ezt akarja. A macOS ezt a listát a System Configuration keretrendszerben tartja, a scutil pedig a parancssori nézete. Mindhárom olyan kapcsolatot ír le, amelyet a platform kezel, és mindhárom elhallgat az olyan alagútról, amelyet nem kezel.
Útvonal: hová megy valójában a csomag
A névillesztés az a rövidítés, amelyhez mindenki először nyúl: sorolja fel az interfészeket, tesztelje a karakterláncot a tun, tap, ppp vagy ipsec ellen, és tekintse a találatot bizonyítéknak. Ez heurisztika, és az interfészkészlet ugyanúgy nézhet ki, akár mozog rajta valami, akár nem. A régebbi iOS-verziók így válaszoltak, a későbbiek abbahagyták, mert a látható interfészek már nem különböztették meg a két állapotot.
Amit ott a helyére tett, az a rendszer proxyszótára. Amíg a VPN csatlakoztatva van, a proxybeállítások hívása az alagúthoz kapcsolódó interfészekre szűkített kulcsokat ad vissza, és ha semmi sincs csatlakoztatva, a szótár üresen tér vissza. Ez gyengébb állítás annál, mint amilyennek hangzik, mert a rendszer azon hitét rögzíti, hogy létezik alagút, nem pedig azt, hogy melyik cél használja.
Az Androidnak megvan a maga változata a csapdára: a vpn.connectivity sugárzás egyes buildekben a manifestben deklarált fogadókhoz ér el, másokban futásidőben regisztrált fogadókhoz. Kezelje legjobb erőfeszítésként, és tartson mögötte közvetlen szondát.
Amikor a cél a fontos, kérdezze az útválasztási táblát az adapterlista helyett. Az alapértelmezett átjáró heurisztikái eltörnek a többhálózatos gépeken és azokon az alagutakon, amelyek saját átjárót telepítenek.
Identitás: szondázza a távoli véget
Egy hurok, amely néhány másodpercenként ICMP-visszhangot küld a távoli végnek, a legolcsóbb ilyen ellenőrzés, és hasznos irányban vall kudarcot. Célozza olyan címre, amely csak a privát hálózaton belül létezik, mert egy nyilvános bármely működő felfelé irányuló kapcsolaton válaszol, és semmit nem bizonyít. Ahol az ICMP szűrt, ott egy rövid TCP-kapcsolat a szolgáltatás portjára ugyanazt a munkát végzi.
A kiszolgálóoldali ellenőrzésnek pontosan egy jele van: a kapcsolat forráscíme. A tartománykészlet nyilvántartása karbantartási munka, és nem tudja elválasztani az alagutat bármely más hálózattól, amely véletlenül ugyanazt a blokkot használja.
A durva szabályzat meg tud élni ezzel. Az identitás nem, ezért hitelesítse az ügyfelet ahelyett, hogy megbízna abban, honnan tűnnek jönni a csomagjai.
A kategóriát naplózza, ne az ítéletet
Tartsa külön a hibakategóriákat a naplóban: egyáltalán nincs interfész, van interfész, de a cél elérhetetlen, a cél elérhető, de a hitelesítés elutasítva. Ez három különböző tulajdonos, és mindegyik más vizsgálatot nyit.
Egyetlen „VPN leállt” állapotba olvasztásuk olyan csapathoz küldi a jelentést, amely nem tudja megjavítani. A kategória a hasznos kimenet; az ítélet az, ami hibássá teszi.