A DNS fölötti VPN nem ugyanaz, mint egy VPN DNS-kiszolgálója

A DNS fölötti VPN egy szállítási ötletet ír le, és nem szinonimája annak, hogy egy eszközt saját feloldóra irányítunk. A zavart eldöntő kérdés egyszerű: mit szállítanak valójában a DNS-üzenetek? Egy hétköznapi VPN telepíthet feloldót, hogy a lefedett alkalmazások privát neveket találjanak, és a feloldó cseréje csak a névfeloldást változtatja meg. Futtassa az alábbi ellenőrzéseket sorrendben, mert a három elrendezés szókincset és szinte semmi mást nem oszt meg.

Válassza szét a három elrendezést

Az első elrendezésben a VPN feloldót vagy névszabályzat-beállítást biztosít. Az alkalmazások adatai továbbra is saját hálózati kapcsolataikon utaznak, és az alagút csak azt befolyásolja, melyik kiszolgáló válaszol a lekérdezésre.

A másodikban a titkosított DNS magát a DNS-cserét védi. A HTTPS fölötti DNS és a TLS fölötti DNS becsomagolja a lekérdezéseket a kiválasztott feloldó felé, és nem szállítanak más alkalmazás csomagjait. Azt sem rejtik el a választott feloldó elől, hogy milyen neveket kérdeztek, ami más bizalmi határ, mint elrejteni őket a helyi hálózat elől.

A harmadikban egy együttműködő kliens más adatot kódol DNS-üzenetekbe, és egy együttműködő végpont visszaállítja azt. A szokásos feloldói útvonal lesz a szállítás, és a feloldó most az adatútvonal része, nem névszolgáltatás.

Ellenőrizze, mit szállítanak a DNS-üzenetek

Cserélje le a feloldót, és figyelje meg, változik-e az alkalmazás forgalmi útvonala. Ha az alkalmazás továbbra is ugyanazokra a címekre kapcsolódik ugyanazokon a socketeken, akkor a névfeloldást változtatta meg, és semmi mást.

A DNS-en keresztül szállított alagúthoz illeszkedő kiszolgálóoldali elrendezés kell. Az Iodine dokumentált példa: a projekt dokumentációja DNS-en át vezető IP-alagutat ír le, és olyan kiszolgálókomponenst igényel, amely érti a kódolást. Nyilvános feloldócím beírása az Androidban nem biztosítja ezt a végpontot, és a két termék által megosztott marketingkifejezés nem protokollspecifikáció.

A rögzítés a döntő ellenőrzés. Ha szokásos lekérdezéseket lát a feloldó felé és semmi mást, nincs alagút. Ha a lekérdezésnevekbe és válaszokba kódolt adatot lát, megtalálta a hordozót, és a következő kérdés az, mennyit képes mozgatni.

Ellenőrizze a kapacitást, mielőtt elkötelezi magát

A DNS-t lekérdezésekre és válaszokra tervezték, nem tömeges kézbesítésre. A kódolási többlet, az üzenetméret-korlátok és a feloldó viselkedése mind részesednek a névleges útvonalból, ezért a hasznos kapacitás alacsonyabb, mint amit az alapul szolgáló kapcsolat sugall. Bármely áteresztőképességi számot, amelyet nem a saját útvonalán mért, kezeljen hipotézisként, nem költségvetésként. Mérje mindkét irányt, mert a kérés-válasz hordozón a feltöltés és a letöltés különböző korlátokba ütközhet.

A kliensnek azt is el kell döntenie, milyen forgalom lép be az alagútba. Egy helyi VPN-szolgáltatás interfész gyűjthet csomagokat, de az interfész semmit sem mond arról, hogyan védi vagy továbbítja őket a távoli szállítás. A töredezés és az újraküldés másként viselkedik, ha a hordozó kérés-válasz protokoll, nem folyam, és egy nyitva maradó kapcsolat keveset mond az interaktív késleltetésről.

Azzal a forgalommal mérjen, amelyet szállítani kíván. Egy alagút, amely jónak tűnik periodikus szívveréshez, használhatatlan lehet interaktív munkamenethez, és ez fordítva is igaz.

Ellenőrizze a hordozó biztonságát

Ne feltételezze, hogy a DNS-becsomagolás bizalmasságot vagy erős hitelesítést nyújt. A feloldói útvonal és az alagút végpontja látja, amit a megvalósítás feltár, és ez a feltárás a tervezéstől függően változik.

A titkosítás és a hordozó megválasztása külön tulajdonságok. Egy alagút titkosítható egyszerű IP-útvonal fölött, és egy DNS-en szállított alagút építhető a hasznos terhelés védelmével vagy anélkül. Mindenképpen tartsa meg az alkalmazás HTTPS-ét, és az alagút tényleges biztonsági tervezését értékelje, ne a nevét.

Ha a követelmény a helyi hálózattal szembeni magánélet, a titkosított DNS és az adatalagút ennek különböző részeire válaszolnak. Írja le, mely megfigyelő ellen védekezik, mielőtt választana.

A javítást a tényleges hibához igazítsa

Egy hétköznapi lassú VPN esetében a DNS-en szállított alagútra váltás korlátozott szállítást tesz a probléma tetejére. Nem javítja a rádióminőséget, a túlterheltséget vagy a kiszolgálóterhelést, és általában láthatóbbá teszi őket.

Privát nevek meghibásodásai esetén először a szándékolt feloldószabályzatot vizsgálja: melyik kiszolgálónak kell válaszolnia, mely nevek tartoznak a hatókörbe, és a kliens jogosult-e használni. Utána válasszon a követelményhez illő engedélyezett szállítást, és őrizze meg a feloldó konfigurációját a változásnaplóban, hogy a következő esemény ne kezdje újra ugyanezt a keresést.

Az ellenőrzőlista rövid: azonosítsa az elrendezést, erősítse meg, mit szállítanak az üzenetek, mérje meg a kapacitást, majd vizsgálja át a bizalmat. Bármely lépés, amely nem illik a tünethez, azt jelenti, hogy a másik két elrendezés még játékban van.