VPN-yhteys tuntuu turvalliselta heti kun sovellus näyttää vihreää valoa. Todellisuudessa moni käyttäjä lähettää edelleen DNS-kyselyjä omalle operaattorilleen, paljastaa julkisen IP-osoitteensa selaimen kautta tai vuotaa sijaintinsa IPv6-liikenteen mukana, vaikka VPN-tunneli on päällä. Michiganin ja New Mexicon yliopistojen sekä IIT Delhin tutkijoiden helmikuussa 2026 esittelemä MVPNalyzer-testijärjestelmä kävi läpi 281 suosittua ilmaista Android-VPN-sovellusta ja löysi vuotoja lähes joka kymmenennestä. Tässä oppaassa käyt läpi, miten testaat oman VPN-yhteytesi DNS-, IP- ja WebRTC-vuodot 12 vaiheessa, korjaat löydetyt aukot ja rakennat lopuksi pienen komentorivityökalun, joka valvoo tilannetta jatkossa automaattisesti.

Moni suomalainen ja pohjoismainen käyttäjä ottaa VPN:n käyttöön juuri julkisilla verkoilla, etätöissä tai suoratoistopalvelujen alueellisten rajoitusten kiertämiseksi, mutta harva testaa yhteyden todellista suojaustasoa asennuksen jälkeen. Sama pätee, vaikka olisit jo lukenut oppaamme ProtonVPN:n asennuksesta tai vertaillut palveluita keskenään: itse asennus ei vielä todista, että liikenne kulkee tunnelin sisällä kokonaisuudessaan. Tämä opas ei vaadi ohjelmointitaitoa, mutta komentorivin peruskäyttö selkeyttää tuloksia huomattavasti.

Mikä VPN-vuoto on ja miksi se tapahtuu

VPN-vuodolla tarkoitetaan tilannetta, jossa osa liikenteestäsi kulkee salatun tunnelin ohi ja päätyy suoraan operaattorillesi tai ulkopuoliselle palvelulle. Vuoto ei tarkoita, että VPN olisi kokonaan rikki, vaan että jokin kapea liikennekanava karkaa tunnelin ulkopuolelle huomaamatta. Selain saattaa silti näyttää VPN-palveluntarjoajan IP-osoitteen sivupalkissa, vaikka tausta-DNS-kysely tai WebRTC-yhteys paljastaa todellisen sijaintisi.

Käytännön seuraukset vaihtelevat sen mukaan, mitä yrität VPN:llä saavuttaa. Jos tavoitteena on vain kiertää suoratoistopalvelun alueellinen rajoitus, DNS-vuoto voi näkyä yksinkertaisesti virheilmoituksena, koska palvelu tunnistaa todellisen sijaintisi. Jos taas tavoitteena on suojata liikennettä julkisella Wi-Fi-verkolla tai piilottaa selailu operaattorilta, sama vuoto tarkoittaa, että koko suojan tarkoitus jää täyttämättä ilman että käyttäjä huomaa sitä. Tästä syystä vuototestaus ei ole vain teknisen tarkkuuden harjoitus, vaan käytännössä ainoa tapa varmistaa, että VPN todella tekee sen, mitä sen luultiin tekevän.

DNS-vuoto selitettynä

Yleisin syy on Windowsin Smart Multi-Homed Name Resolution -toiminto (SMHNR), joka on ollut käytössä Windows 8:sta lähtien. Se lähettää DNS-kyselyt rinnakkain kaikkiin aktiivisiin verkkosovittimiin ja hyväksyy nopeimman vastauksen. Kun VPN on päällä, kysely lähtee siis samaan aikaan sekä VPN-tunnelin että operaattorin verkkosovittimen kautta, ja operaattori näkee kyselyn riippumatta siitä kumpi vastaus voittaa. Toinen yleinen syy on selaimen oma DNS over HTTPS -asetus (DoH), joka ohittaa sekä käyttöjärjestelmän että VPN:n DNS-hallinnan kokonaan ja lähettää kyselyt suoraan Cloudflaren, Googlen tai muun DoH-palveluntarjoajan resolveriin. Kolmas syy on VPN-sovellus, joka ei hallinnoi DNS-asetuksia natiivisti, ja neljäs on tunneloimaton IPv6-liikenne.

IP- ja WebRTC-vuoto selitettynä

WebRTC on selainten sisäänrakennettu tekniikka reaaliaikaiseen video- ja äänipuheluun, ja se kerää niin sanottuja ICE-kandidaatteja: paikallisen lähiverkon IP-osoitteen sekä STUN-palvelimen kautta selvitetyn julkisen IP-osoitteen. Nämä osoitteet ovat JavaScript-koodin luettavissa ilman erillistä lupaa, joten mikä tahansa sivusto voi periaatteessa napata todellisen IP-osoitteesi STUN-kyselyn kautta, vaikka VPN peittäisi selaimen näkyvän osoitteen. Nykyiset Chrome- ja Firefox-versiot korvaavat paikallisen IP-osoitteen satunnaisella mDNS-isäntänimellä, mikä estää lähiverkon osoitteen paljastumisen, mutta julkinen IP voi silti vuotaa STUN-reitin kautta reitityksestä riippuen.

Vuodon vakavuus riippuu myös siitä, mitä palvelua käytät VPN:n kanssa. Videopuhelupalvelut, verkkopelit ja jotkin pankkisovellukset nojaavat WebRTC:hen tai vastaaviin suoriin yhteyksiin, joten niiden käyttö VPN:n kanssa on erityisen altis paljastamaan todellisen sijainnin, vaikka selauksessa muuten kaikki näyttäisi olevan kunnossa. Tästä syystä pelkkä selaimen osoitepalkin tarkistus ei riitä: vuoto voi tapahtua täysin taustalla ilman mitään näkyvää merkkiä käyttöliittymässä.

Ennakkovaatimukset ja tarvittavat työkalut

Ennen kuin aloitat, varaa noin 45 minuuttia ja varmista, että käytössäsi on seuraavat asiat. Tarvitset toimivan VPN-tilauksen (esimerkiksi ProtonVPN tai muu WireGuard-pohjainen palvelu), ajantasaisen selaimen (Chrome 128+ tai Firefox 130+ riittää useimpiin testeihin, mutta uusin vakaa versio on aina suositeltavin), pääsyn käyttöjärjestelmän verkkoasetuksiin ylläpitäjän oikeuksin, sekä Linux- tai macOS-käyttäjille komentorivin dig– ja curl-työkalut. Windows-käyttäjät tarvitsevat PowerShellin ylläpitäjän oikeuksin. Automaatio-osiota varten tarvitset lisäksi cron-ajastuksen (Linux/macOS) tai Tehtävienajastimen (Windows), jos haluat ajaa vuototestin säännöllisesti taustalla.

Kannattaa myös varata paperia tai tekstitiedosto muistiinpanoja varten, sillä testaat samat asiat kahteen kertaan: kerran ilman VPN:ää ja kerran sen kanssa. Jos käytät mobiililaitetta, lataa testit valmiiksi molempiin laitteisiin ennen aloitusta, koska osa vuodoista näkyy vain matkapuhelinverkossa eikä Wi-Fi-yhteydellä. Jos et vielä ole valinnut VPN-palvelua, tutustu ensin artikkeliimme NordVPN:n, ProtonVPN:n ja Mullvadin vertailusta, sillä palveluiden väliset erot kill switchin ja DNS-hallinnan toteutuksessa vaikuttavat suoraan siihen, kuinka paljon manuaalista korjaustyötä tarvitset tässä oppaassa.

Laite/ohjelmistoVähimmäisversioRooli testauksessa
WindowsWindows 10 tai Windows 11PowerShell IPv6-komennot, adapterin hallinta
macOSVentura, Sonoma tai Sequoianetworksetup-komento, TCP/IP-asetukset
AndroidAndroid 12 tai uudempiAPN-asetukset, IPv6-hallinta mobiiliverkossa
iOSiOS 16 tai uudempiManuaaliset Wi-Fi-DNS-asetukset
Google Chrome128 tai uudempichrome://flags, WebRTC IP handling policy
Mozilla Firefox130 tai uudempiabout:config, media.peerconnection-asetukset

Vaihe 1–2: Perustason mittaus ilman VPN:ää

Ennen kuin kytket VPN:n päälle, kirjaa muistiin lähtötilanne. Käy osoitteessa ipleak.net ilman VPN-yhteyttä ja kirjoita ylös julkinen IP-osoitteesi sekä operaattorisi nimi. Tämä on kontrollinäyte, johon vertaat kaikkia myöhempiä tuloksia. Vaihe kaksi on sama testi dnsleaktest.com-sivustolla: aja “Standard test” ja kirjaa ylös näkyvät DNS-palvelimet ja niiden operaattori. Jos myöhemmin VPN päällä ollessa näet saman operaattorin nimen tässä listassa, kyseessä on vuoto. Monet oppaat unohtavat tämän lähtötilanteen, minkä vuoksi käyttäjä ei osaa erottaa aitoa vuotoa normaalista taustakohinasta.

Kirjaa myös ylös, mitä verkkoa käytät testihetkellä: kotiverkko kiinteällä laajakaistalla, mobiilidata vai julkinen Wi-Fi. Näiden kolmen verkkotyypin lähtötilanne voi poiketa toisistaan huomattavasti, koska osa operaattoreista käyttää eri DNS-infrastruktuuria matkapuhelinverkossa kuin kiinteässä laajakaistassa. Jos aiot testata VPN:n toimintaa kaikissa kolmessa ympäristössä, kannattaa toistaa tämä lähtötilanteen mittaus jokaisessa erikseen ennen varsinaisia vuototestejä, jotta tulkinnalle jää selkeä vertailukohta.

Vaihe 3–4: DNS-vuototesti käytännössä

Kytke VPN päälle ja valitse palvelin, joka on maantieteellisesti kaukana todellisesta sijainnistasi, esimerkiksi Singapore tai Kanada, jos olet Suomessa. Näin erottelu on selkeämpi. Avaa uusi selainikkuna (älä käytä samaa välilehteä, jossa on välimuistiin jääneitä DNS-vastauksia) ja mene uudelleen dnsleaktest.com-sivulle, tällä kertaa “Extended test” -painikkeella. Extended-testi lähettää useampia kyselyjä ja paljastaa myös osittaiset vuodot, joita standarditesti ei havaitse. Voit tehdä saman tarkistuksen myös komentoriviltä, mikä on hyödyllistä jos haluat automatisoida testin myöhemmin:

# Linux/macOS: tarkista mitä DNS-palvelinta yhteys todella käyttää
dig +short whoami.akamai.net
dig TXT +short o-o.myaddr.l.google.com @ns1.google.com

# Vertaa tulosta VPN-palveluntarjoajan ilmoittamiin DNS-osoitteisiin
nslookup -type=txt debug.opendns.com resolver1.opendns.com

Jos komennon tulos näyttää operaattorisi nimen tai kotimaasi sijainnin VPN-palvelimen sijainnin sijaan, DNS vuotaa. Yleisin korjaus on ottaa käyttöön VPN-sovelluksen oma DNS-suojaus asetuksista tai pakottaa käyttöjärjestelmä käyttämään vain VPN:n tarjoamaa resolveria.

Esimerkki komennon tulosteesta, kun DNS kulkee oikein VPN-palvelimen kautta (palvelin Alankomaissa):

$ dig +short whoami.akamai.net
185.242.5.14

$ nslookup -type=txt debug.opendns.com resolver1.opendns.com
"server    185.242.5.14"
"country   NL (Netherlands)"
"errors    0"

Jos sen sijaan tuloste näyttäisi suomalaisen operaattorin IP-avaruuden osoitteen ja maakoodin “FI” VPN-palvelimen sijaintimaan sijaan, kyseessä on vahvistettu DNS-vuoto.

Tulkitse extended-testin tulostaulukko rivi kerrallaan. Jokainen rivi vastaa yhtä DNS-palvelinta, joka vastasi johonkin testin lähettämistä kyselyistä. Oikeanpuoleisin “ISP”-sarake kertoo, minkä organisaation nimissä palvelin on rekisteröity. Jos näet siellä oman operaattorisi (esimerkiksi Telia, DNA tai Elisa) VPN-palvelimen maan sijaan, DNS-kysely on karannut tunnelin ohi. Yksittäinen rivi VPN-palveluntarjoajan omalla nimellä on normaalia ja odotettua, mutta useamman eri organisaation sekoitus samassa tuloksessa on merkki osittaisesta vuodosta, jonka SMHNR tyypillisesti aiheuttaa.

Vaihe 5–6: WebRTC-vuototesti selaimessa

Avaa VPN-yhteyden ollessa päällä osoite browserleaks.com/webrtc. Sivu listaa kaikki ICE-kandidaatit, jotka selaimesi paljastaa: paikalliset osoitteet, mDNS-nimet ja mahdollisen julkisen STUN-osoitteen. Jos “public IP” -kentässä näkyy muu osoite kuin VPN-palvelimesi, WebRTC vuotaa todellisen sijaintisi ohi tunnelin. Firefoxissa vuoto korjataan avaamalla about:config ja säätämällä seuraavat arvot:

# Firefox about:config -arvot WebRTC-vuotojen tukkimiseen
media.peerconnection.enabled = false          // sammuttaa WebRTC:n kokonaan
media.peerconnection.ice.no_host = true       // estää paikallisten osoitteiden jaon
media.peerconnection.ice.relay_only = true    // pakottaa liikenteen relay-palvelimen kautta

Chromessa ei ole vastaavaa suoraa kytkintä, joten käytännöllisin ratkaisu on avata chrome://flags, hakea “WebRTC IP handling policy” ja valita “Disable non-proxied UDP” tai asentaa erillinen WebRTC Leak Prevent -laajennus ja asettaa sen tilaksi “Use the default public interface only”. uBlock Originin asetuksista löytyy myös kytkin “Prevent WebRTC from leaking local IP addresses”, joka kannattaa ottaa käyttöön joka tapauksessa.

Selainkohtaiset erot: Chrome, Firefox, Safari ja Edge

Kaikki selaimet eivät käsittele WebRTC:tä samalla tavalla, joten sama korjaus ei toimi joka paikassa. Firefox ja siitä haaroitetut selaimet, kuten LibreWolf, tarjoavat suoran about:config-kytkimen, joka sammuttaa WebRTC:n kokonaan. Chrome ja muut Chromium-pohjaiset selaimet (Edge, Brave, Opera) eivät tarjoa yhtä suoraa kytkintä, vaan vaativat joko laajennuksen tai flag-asetuksen muuttamisen. Safari macOS:ssä ja iOS:ssä ei tarjoa käyttäjälle näkyvää WebRTC-kytkintä lainkaan, joten ainoa käytännön keino on estää WebRTC sisällönestolaajennuksella tai varmistaa, että VPN-sovellus reitittää koko järjestelmän liikenteen, jolloin selaimen sisäinen käyttäytyminen ei enää ratkaise mitään. Edge perii Chromiumin flag-järjestelmän, joten samat edge://flags-asetukset toimivat kuin Chromessa.

Vaihe 7–8: IPv6-vuodon tarkistus ja sulkeminen

Suurin osa suomalaisista operaattoreista tarjoaa nykyään IPv6-osoitteen oletuksena, ja monet laitteet suosivat IPv6-reittiä IPv4:n sijaan. Jos VPN-sovelluksesi ei tunneloi IPv6-liikennettä, kaikki IPv6-kyselyt kulkevat suoraan operaattorin verkon kautta salattuna tunnelin ohitse. Turvallisin ratkaisu on sulkea IPv6 kokonaan käyttöjärjestelmätasolla, ellei VPN-palveluntarjoaja nimenomaisesti ilmoita tukevansa IPv6:ta tunnelin sisällä.

# Windows 11 PowerShell (ylläpitäjänä)
Get-NetAdapter | ForEach-Object {
  Disable-NetAdapterBinding -Name $_.Name -ComponentID ms_tcpip6
}
# macOS (Ventura/Sonoma/Sequoia): aseta IPv6 pois käytöstä Wi-Fi-liitännästä
networksetup -setv6off "Wi-Fi"
# Palautus tarvittaessa:
networksetup -setv6automatic "Wi-Fi"
# Linux (systemd): poista IPv6 käytöstä pysyvästi sysctl-asetuksilla
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
echo "net.ipv6.conf.all.disable_ipv6 = 1" | sudo tee -a /etc/sysctl.conf

Androidilla IPv6 suljetaan mobiiliverkosta kohdasta Asetukset → Verkko ja internet → Mobiiliverkot → Yhteyspisteet (APN) → APN-protokolla → valitse IPv4. iOS ei tarjoa suoraa IPv6-kytkintä, joten käytännön ratkaisu on poistaa IPv6-DNS-osoitteet (alkavat yleensä tunnisteella 2001: tai 2606:) Wi-Fi-verkon manuaalisista DNS-asetuksista kohdassa Asetukset → Wi-Fi → verkon tiedot → Määritä DNS → Manuaalinen.

Kannattaa muistaa, että IPv6:n kokonaan sulkeminen on kompromissi. Osa palveluista, kuten jotkin operaattoreiden omat sovellukset tai IoT-laitteet, saattavat toimia heikommin ilman IPv6-yhteyttä. Jos VPN-palveluntarjoajasi ilmoittaa selkeästi tukevansa IPv6-tunnelointia (esimerkiksi osana WireGuard-konfiguraatiota), parempi ratkaisu voi olla jättää IPv6 päälle ja varmistaa sen sijaan, että VPN-sovellus todella tunneloi sen kokonaan. Tämän voi tarkistaa toistamalla vaiheen 3–4 DNS-testin IPv6-yhteydellä: käy osoitteessa ipleak.net ja katso, näkyykö sivulla erillinen IPv6-osoiterivi ja vastaako se VPN-palvelimen sijaintia.

Vaihe 9–10: Kill switch -toiminnon varmistus

Kill switch katkaisee koko internet-yhteyden hetkeksi, jos VPN-tunneli putoaa yllättäen. Ilman sitä pieni katkos riittää paljastamaan todellisen IP-osoitteesi hetkeksi tavalliselle selaustapahtumalle. Testaa toiminto käytännössä: avaa taustalle jatkuva ping tai lataus, sammuta VPN-sovelluksen prosessi väkisin (älä sammuta siististi valikosta) ja seuraa, katkeaako internet-yhteys välittömästi vai jatkuuko liikenne muutaman sekunnin ajan suojaamattomana.

Toiminto tunnetaan hieman eri nimillä palveluntarjoajasta riippuen. NordVPN tarjoaa erilliset järjestelmätason ja sovelluskohtaiset kytkimet, ProtonVPN nimeää ominaisuuden pysyväksi kill switchiksi ja yhdistää sen NetShield-suojaukseen, Mullvad kutsuu sitä lukitustilaksi (“Lockdown mode”), joka on oletuksena päällä ja estää kaiken liikenteen ilman tunnelia, ExpressVPN käyttää nimeä Network Lock, ja Surfsharkilla on peruskytkimen lisäksi erillinen Emergency Kill Switch. Rtingsin vuoden 2025 uudelleenkäynnistystestissä Mullvad oli yksi vain kahdesta palvelusta, joka ei vuotanut yhtäkään pakettia käyttöjärjestelmän uudelleenkäynnistyksen aikana, kiitos palomuuritason kill switch -toteutuksen.

Kill switchin testaaminen kannattaa tehdä useammin kuin kerran, koska ominaisuus voi käyttäytyä eri tavalla eri tilanteissa: yhteyden yllättävä katkeaminen, kannettavan siirtyminen lepotilaan ja herääminen, tai Wi-Fi-verkon vaihtuminen matkan aikana. Testaa kaikki kolme tilannetta erikseen, sillä moni sovellus suojaa hyvin ensimmäisessä skenaariossa mutta vuotaa hetken toisessa tai kolmannessa. Mobiilisovelluksissa kill switch pitää usein aktivoida erikseen asetuksista, sillä se ei aina ole päällä oletuksena, toisin kuin työpöytäversioissa.

Vaihe 11–12: Automatisoitu vuotovalvonta ja täydellinen esimerkkiprojekti

Manuaalinen testaus on hyvä lähtökohta, mutta VPN-sovellusten päivitykset, käyttöjärjestelmän palautukset oletusasetuksiin ja uudet selainversiot voivat avata vuodon uudelleen milloin tahansa. Seuraava bash-skripti tarkistaa julkisen IP-osoitteen ja DNS-resolverin komentoriviltä ja hälyttää, jos tulos poikkeaa VPN-palvelimen odotetusta sijainnista. Tallenna se tiedostoon vpn-leak-check.sh, tee siitä suoritettava ja ajasta cronilla esimerkiksi tunnin välein.

#!/usr/bin/env bash
# vpn-leak-check.sh – yksinkertainen VPN-vuotovalvonta
# Käyttö: ./vpn-leak-check.sh "Odotettu maakoodi, esim. NL"

set -euo pipefail
EXPECTED_COUNTRY="${1:-NL}"
LOGFILE="$HOME/vpn-leak-check.log"

CURRENT_IP=$(curl -s https://api.ipify.org)
CURRENT_COUNTRY=$(curl -s "https://ipapi.co/${CURRENT_IP}/country/")
DNS_RESULT=$(dig +short whoami.akamai.net)

TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

if [ "$CURRENT_COUNTRY" != "$EXPECTED_COUNTRY" ]; then
  echo "[$TIMESTAMP] VAROITUS: IP-osoite ei vastaa VPN-palvelinta. Maa: $CURRENT_COUNTRY, IP: $CURRENT_IP" | tee -a "$LOGFILE"
  exit 1
else
  echo "[$TIMESTAMP] OK: IP $CURRENT_IP, maa $CURRENT_COUNTRY, DNS-resolveri $DNS_RESULT" >> "$LOGFILE"
fi

Ajasta skripti crontabilla suorittumaan tunneittain ja lähettämään lokitiedosto sähköpostiisi tai yksinkertaiseen webhookiin, jos haluat reaaliaikaisen hälytyksen:

# crontab -e
0 * * * * /home/kayttaja/vpn-leak-check.sh NL >> /home/kayttaja/vpn-leak-check.log 2>&1

Tämä on koko projekti pähkinänkuoressa: yksi skripti, yksi cron-rivi ja lokitiedosto, jota voit tarkistaa milloin tahansa. Laajempi versio voisi lähettää tuloksen esimerkiksi Slackiin tai Discordiin webhookilla, mutta perusversio riittää useimmille kotikäyttäjille.

Esimerkki lokitiedoston sisällöstä muutaman tunnin ajolta, kun kaikki on kunnossa ja yksi vuoto havaitaan:

[2026-09-06 08:00:03] OK: IP 185.242.5.14, maa NL, DNS-resolveri 185.242.5.14
[2026-09-06 09:00:02] OK: IP 185.242.5.14, maa NL, DNS-resolveri 185.242.5.14
[2026-09-06 10:00:04] VAROITUS: IP-osoite ei vastaa VPN-palvelinta. Maa: FI, IP: 85.76.xxx.xxx
[2026-09-06 11:00:03] OK: IP 185.242.5.14, maa NL, DNS-resolveri 185.242.5.14

Kello 10 tapahtunut varoitus tarkoittaa tässä esimerkissä, että VPN-yhteys oli hetkellisesti pudonnut ja kill switch ei ehtinyt estää liikennettä ennen kuin sovellus yhdisti uudelleen. Tällainen yksittäinen rivi lokissa on hyvä syy palata vaiheeseen 9–10 ja testata kill switch uudelleen.

Skriptiä kannattaa laajentaa vähitellen tarpeen mukaan. Ensimmäinen looginen lisäys on DNS-resolverin vertailu tunnettuun listaan VPN-palveluntarjoajan omista osoitteista, jolloin skripti osaa erottaa “OK, DNS kulkee VPN:n kautta” tilanteesta “VAROITUS, DNS näyttää operaattorin osoitteen”. Toinen lisäys on ajastaa skripti käynnistymään automaattisesti aina kun tietokone herää lepotilasta, mikä kattaa juuri sen hetken, jolloin kill switch on historiallisesti epäluotettavin. Windows-käyttäjät voivat toteuttaa saman logiikan PowerShell-skriptinä ja ajastaa sen Tehtävienajastimella käynnistymään järjestelmän käynnistyksen yhteydessä, jolloin koko valvonta toimii ilman erillistä Linux- tai macOS-konetta.

Vertailutaulukko: suosituimmat vuototestaustyökalut

Alla oleva taulukko kokoaa yhteen tässä oppaassa käytetyt työkalut yhdellä silmäyksellä. Kaikki ovat ilmaisia eivätkä vaadi rekisteröitymistä, mikä tekee niistä sopivia myös kertaluonteiseen tarkistukseen ilman, että tarvitsee jättää sähköpostiosoitetta kolmannelle osapuolelle.

TyökaluTestaaHintaHuomio
dnsleaktest.comDNS (standard/extended)IlmainenExtended-testi paljastaa osittaiset vuodot
ipleak.netIP, DNS, WebRTCIlmainenNäyttää kaikki kolme yhdellä sivulla
browserleaks.com/webrtcWebRTC (ICE-kandidaatit)IlmainenTarkin WebRTC-erittely, ohjeet korjaukseen
ExpressVPN Leak TestIP, DNS, WebRTCIlmainenPalveluntarjoajan oma integroitu työkalu
dig/nslookup (komentorivi)DNS-resolveriIlmainenSopii automaatioon ja skripteihin

Kill switch -ominaisuudet viidessä suositussa VPN-palvelussa

Nimet ja toteutustavat eroavat palveluiden välillä, mutta perusidea on kaikissa sama: estää liikenne kokonaan siihen asti, kunnes VPN-tunneli on taas pystyssä. Käytä alla olevaa taulukkoa muistilistana, kun käyt läpi vaiheen 9–10 testejä omalla palvelullasi.

PalveluKill switch -nimiToimintatapa
NordVPNKill Switch (järjestelmä- ja sovellustaso)Erilliset kytkimet koko yhteydelle ja yksittäisille sovelluksille
ProtonVPNPysyvä kill switch + NetShieldPalomuuritason esto, yhdistetty mainos- ja seurantasuojaan
MullvadLockdown modeOletuksena päällä, estää kaiken liikenteen ilman tunnelia
ExpressVPNNetwork LockJärjestelmätason lukitus, yksinkertainen päälle/pois-kytkin
SurfsharkKill Switch + Emergency Kill SwitchPerus- ja lisäkytkin, oletuksena aktiivinen

MVPNalyzer-tutkimus: mitä 281 ilmaista Android-VPN:ää paljasti

The Hacker News raportoi heinäkuussa 2026 tutkimuksesta, jossa Michiganin yliopiston, New Mexicon yliopiston ja IIT Delhin tutkijat testasivat MVPNalyzer-nimisellä automaattisella testijärjestelmällä 281 suosittua ilmaista Android-VPN-sovellusta Google Playssa. Tulokset olivat karuja: 29 sovellusta päästi käyttäjäliikennettä VPN-tunnelin ulkopuolelle, ja näistä 24 vuoti nimenomaan DNS-liikennettä, mikä paljastaa käyttäjän vierailemat sivustot paikalliselle verkolle. Yhteensä nämä 24 sovellusta kattoivat arviolta noin 360 miljoonaa asennusta. Kuusi sovellusta vuoti selausliikennettä näkyvän TLS SNI -kentän kautta, ja neljä sovellusta käytti kokonaan salaamatonta tunnelia.

Vielä huolestuttavampaa oli, että 61 sovellusta lähetti jotain dataa selväkielisenä yli 10 000 mitatussa liikennevirrassa, ja viisi sovellusta lähetti VPN:n asetustiedoston täysin salaamattomana. Tutkijat pystyivät tämän avulla demonstroimaan käytännön tunnelikaappauksen: muokkaamalla asetustiedostoa liikenne saatiin ohjattua hyökkääjän hallitsemalle palvelimelle. Tutkimus koski nimenomaan ilmaisia Android-sovelluksia, ei suuria maksullisia palveluntarjoajia, mutta se on hyvä muistutus siitä, että VPN-sovelluksen asentaminen ei automaattisesti tarkoita suojattua yhteyttä. Tämän oppaan testit toimivat yhtä hyvin riippumatta siitä, mikä VPN-sovellus on käytössä.

MVPNalyzer on tutkijoiden mukaan ensimmäinen järjestelmä, joka on rakennettu toistuvasti auditoimaan Android-VPN-sovelluksia, mikä eroaa aiemmista kertaluonteisista selvityksistä. Se tarkoittaa, että sama testijärjestelmä voi jatkossa seurata sovelluspäivityksiä ja huomata, jos aiemmin turvallinen sovellus alkaa vuotaa uuden version myötä. Kuluttajan näkökulmasta viesti on selkeä: sovelluskaupan tähtiarvio tai asennusmäärä ei kerro mitään DNS- tai WebRTC-vuodoista, ja ainoa varma tapa tietää on testata itse tämän oppaan menetelmillä jokaisen ison päivityksen jälkeen.

Suomi ja Pohjoismaat: sääntely ja valvonta

Suomessa Liikenne- ja viestintävirasto Traficom ylläpitää Kyberturvallisuuskeskuksen kautta ohjeistusta salaus- ja tietoturvatuotteiden arvioinnista. Traficomin NCSA-FI-yksikön hyväksymien salausratkaisujen ohjeistus tuli voimaan helmikuussa 2025, ja se koskee laajemmin salausta ja tietoturvaa täyttäviä tuotteita, ei suoraan kuluttajien VPN-sovelluksia. Käytännössä tämä tarkoittaa, ettei Suomessa ole erillistä viranomaisen ylläpitämää “hyväksyttyjen VPN-palvelujen” listaa kuluttajille, vaan vastuu oman yhteyden turvallisuuden varmistamisesta jää käyttäjälle itselleen. Tämä tekee omatoimisesta vuototestauksesta erityisen tärkeää suomalaisille ja pohjoismaisille käyttäjille, sillä valmista viranomaistarkastusta ei ole odotettavissa yksittäisille kuluttajasovelluksille. Vertailun vuoksi kannattaa lukea myös aiempi katsauksemme NordVPN:n ja Mullvadin kolmannen osapuolen auditoinneista, jotka täydentävät tätä omatoimista testausta.

Käytännön tasolla tämä näkyy suomalaisen käyttäjän arjessa kolmella tavalla. Ensinnäkin operaattorit (Telia, DNA, Elisa) ovat siirtyneet laajasti IPv6:een, mikä tekee IPv6-vuodosta todennäköisemmän juuri suomalaisille kuin monille eteläeurooppalaisille käyttäjille, joiden verkoissa IPv6 ei ole vielä yhtä yleinen. Toiseksi julkishallinnon ja yritysten etätyöohjeistuksissa VPN mainitaan usein pakollisena, mutta harvoin ohjeistetaan testaamaan yhteyden todellista suojaustasoa, mikä jättää testausvastuun yksittäiselle työntekijälle. Kolmanneksi, koska erillistä kuluttajaviraston VPN-hyväksyntää ei ole, markkinoilla toimii rinnakkain sekä auditoituja palveluita että ilman julkista auditointia toimivia palveluita, ja juuri tämä ero näkyy konkreettisesti tässä oppaassa esiteltyjen testien tuloksissa.

Julkiset Wi-Fi-verkot ja erityisriskit

Julkinen Wi-Fi kahvilassa, junassa tai lentokentällä on tilanne, jossa vuototestaus kannattaa tehdä erityisen huolellisesti. Monet julkiset verkot käyttävät niin sanottua captive portal -kirjautumissivua, joka avautuu automaattisesti selaimessa ennen kuin varsinainen internet-yhteys toimii. Käyttöjärjestelmä saattaa tässä vaiheessa sallia rajoitetun, suojaamattoman yhteyden portaalisivun lataamiseksi, ja jos VPN-sovellus ei ole vielä ehtinyt käynnistyä, tämä hetki jää testaamatta myöhemmissä tarkistuksissa. Käytännön suositus on kirjautua ensin captive-portaaliin ilman mitään arkaluontoista selausta, käynnistää VPN vasta portaalin läpäisyn jälkeen ja ajaa täysi vuototesti uudelleen ennen normaalia käyttöä.

Toinen julkisiin verkkoihin liittyvä erityispiirre on DNS-välimuistin myrkytys ja väärennetyt tukiasemat, jotka voivat ohjata DNS-kyselyt haluamalleen palvelimelle ennen VPN:n käynnistymistä. Tästä syystä kill switchin testaaminen (vaihe 9–10) on julkisessa verkossa vielä tärkeämpää kuin kotiverkossa: jos kill switch ei toimi, jokainen yhteyskatkos julkisessa verkossa on hetki, jolloin liikenteesi voi altistua paitsi operaattorin myös verkon muiden käyttäjien tarkkailulle.

Yleisimmät virheet vuototestauksessa

Vuototestaus menee helposti pieleen, jos testimenetelmä on väärä. Tässä yleisimmät sudenkuopat, jotka vääristävät tuloksia.

  • Testaat samassa selainikkunassa, jossa on vanhoja DNS-vastauksia välimuistissa. Avaa aina uusi ikkuna tai tyhjennä selaimen DNS-välimuisti ennen uutta testiä.
  • Unohdat sulkea IPv6:n, vaikka VPN tukee vain IPv4-tunnelia. Tämä on yksi yleisimmistä syistä, miksi käyttäjä luulee olevansa suojattu, vaikka IPv6-liikenne vuotaa koko ajan taustalla.
  • Luotat pelkkään sovelluksen omaan tilailmoitukseen. “Yhdistetty”-teksti sovelluksessa ei todista, että liikenne todella kulkee tunnelin läpi kokonaisuudessaan.
  • Testaat reitittimestä, joka välimuistittaa DNS-vastauksia paikallisesti. Kotireititin saattaa näyttää vanhan vastauksen, joka ei kerro totuutta senhetkisestä yhteydestä.
  • Et testaa kill switchiä oikeasti sammuttamalla VPN-prosessin väkisin. Siisti sovelluksen sulkeminen valikosta ei simuloi todellista yhteyskatkosta.
  • Testaat vain työpöytäkoneella ja unohdat mobiililaitteet. Android ja iOS käyttäytyvät DNS- ja IPv6-asioissa eri tavalla kuin Windows tai macOS.
  • Luotat vain yhteen testityökaluun. Eri työkalut käyttävät eri mittausmenetelmiä, joten kahden tai kolmen työkalun ristiinvertailu antaa luotettavamman kuvan.
  • Vaihdat VPN-palvelinta testien välissä huomaamatta. Jos vertailet DNS- ja WebRTC-tuloksia keskenään, varmista että molemmat testit tehtiin samalla palvelimella ja samalla protokollalla (esimerkiksi WireGuard eikä OpenVPN).
  • Unohdat testata julkisen Wi-Fi-verkon erikoistapaukset. Kahviloiden ja lentokenttien captive portal -kirjautumissivut avaavat usein hetkellisesti suojaamattoman yhteyden ennen VPN:n käynnistymistä, mikä ei näy myöhemmässä testissä mutta on tapahtunut silti.

VPN-vuodot suoratoistossa ja verkkopeleissä

Suoratoistopalvelut ja verkkopelit ovat erityistapaus, koska ne usein havaitsevat ja estävät tunnetut VPN-palvelinosoitteet aktiivisesti. Tämä johtaa siihen, että käyttäjät vaihtavat VPN-palvelinta usein tai kokeilevat useita palvelimia löytääkseen toimivan yhteyden, ja jokainen vaihto on uusi tilaisuus DNS- tai WebRTC-vuodolle, jos testausta ei toisteta. Verkkopeleissä ongelma on erityisen näkyvä, koska monet pelimoottorit käyttävät UDP-pohjaista suoraa yhteyttä pelipalvelimeen samaan tapaan kuin WebRTC, mikä tarkoittaa, että pelin sisäinen “ping-osoite” tai vastustajalle näkyvä IP voi paljastaa todellisen sijaintisi, vaikka selaimen vuototesti näyttäisi kaiken olevan kunnossa.

Käytännön suositus on testata jokainen uusi VPN-palvelin erikseen ennen pitkäaikaista käyttöä, ja jos pelaat kilpailullisesti tai suoratoistat säännöllisesti tietyllä palvelimella, aja vaiheen 11–12 automaatioskripti juuri kyseisen palvelimen maakoodilla. Jos huomaat, että peli tai suoratoistopalvelu näyttää sinulle eri sijainnin kuin VPN-sovellus ilmoittaa, syynä on lähes aina se, että sovellus käyttää omaa suoraa yhteyttään pelipalvelimeen VPN-tunnelin sijaan, mikä vaatii erillisen selvityksen palveluntarjoajan tukikanavan kautta.

Vianmääritys: yleisimmät ongelmat ja ratkaisut

1. DNS-testi näyttää edelleen operaattorini nimen, vaikka VPN on päällä. Tarkista VPN-sovelluksen asetuksista, onko oma DNS-suojaus (usein nimellä “DNS leak protection” tai “Force VPN DNS”) kytketty päälle. Jos asetusta ei löydy, aseta käyttöjärjestelmän verkkosovittimen DNS-palvelimeksi manuaalisesti VPN-palveluntarjoajan ilmoittama osoite. Jos ongelma jatkuu tämänkin jälkeen, syynä on lähes aina SMHNR-toiminto Windowsissa, jonka voi sammuttaa rekisterimuokkauksella tai poistamalla käytöstä ylimääräiset verkkosovittimet, joita et aktiivisesti käytä.

2. WebRTC-testi paljastaa julkisen IP-osoitteeni selaimessa. Ota käyttöön edellä mainitut Firefoxin about:config-asetukset tai asenna WebRTC Leak Prevent -laajennus Chromeen ja aseta se tilaan “Use the default public interface only”.

3. Kill switch ei katkaise yhteyttä yhteyden pudotessa. Varmista, että ominaisuus on erikseen aktivoitu asetuksista, sillä useissa sovelluksissa se ei ole oletuksena päällä mobiilipuolella, vaikka työpöytäversiossa olisikin. Jos ominaisuus on jo päällä eikä silti toimi, päivitä VPN-sovellus uusimpaan versioon, sillä kill switch -toteutukset ovat yksi yleisimmistä bugikorjausten kohteista sovellusten julkaisumuistioissa.

4. IPv6 kytkeytyy takaisin päälle Windows-päivityksen jälkeen. Windowsin suuret päivitykset palauttavat toisinaan verkkosovittimien oletusasetukset. Tarkista IPv6-tila päivitysten jälkeen ja aja PowerShell-komento uudelleen tarvittaessa.

5. dnsleaktest.com ja ipleak.net antavat ristiriitaisia tuloksia. Tämä on tavallista, koska työkalut käyttävät eri kyselymenetelmiä ja palvelinverkkoja. Luota siihen työkaluun, joka toistuvasti näyttää saman tuloksen useammalla testikerralla.

6. VPN-sovellus näyttää yhdistetyksi, mutta selain silti vuotaa. Kyse on lähes aina selaintason DoH-asetuksesta, joka ohittaa VPN:n DNS-hallinnan. Tarkista selaimen asetuksista, onko DNS over HTTPS asetettu käyttämään omaa palveluntarjoajaasi VPN:n sijaan. Aiheesta lisää oppaassamme DNS over HTTPS -asennuksesta.

7. Android-puhelin vuotaa DNS:n mobiiliverkossa vaikka Wi-Fi:ssä kaikki toimii. Mobiiliverkon APN-asetukset voivat ohittaa VPN:n DNS-hallinnan eri tavalla kuin Wi-Fi. Kokeile asettaa APN-protokolla IPv4-only-tilaan ja testaa uudelleen mobiilidatalla. Jos APN-asetuksia ei pääse muokkaamaan operaattorin lukituksen vuoksi, viimeinen keino on asettaa VPN-sovellus “Always-on VPN” -tilaan Androidin järjestelmäasetuksista ja kytkeä samalla “Block connections without VPN” -valinta päälle.

8. Automaatioskripti ei havaitse vuotoa, vaikka manuaalinen testi löytää sen. Skripti tarkistaa vain julkisen IP-osoitteen ja yhden DNS-kyselyn, kun taas selaintestit tarkistavat myös WebRTC:n. Laajenna skriptiä lisäämällä siihen erillinen WebRTC-tarkistus tai aja selaintestit rinnalla säännöllisesti.

9. Testitulokset vaihtelevat samalla laitteella eri kellonaikoina. Osa operaattoreista ja VPN-palveluista käyttää kuormantasausta, joka ohjaa kyselyt eri palvelimille testikerrasta riippuen. Tämä on normaalia eikä välttämättä merkki vuodosta, mutta jos sama toinen operaattori toistuu useasti eri kellonaikoina, kyseessä on todennäköisesti aito vuoto eikä satunnainen vaihtelu.

Edistyneet vinkit ammattikäyttäjille

Kun perustestit ovat kunnossa, voit viedä valvonnan seuraavalle tasolle. Wireshark-pakettikaappauksella näet tarkalleen, mikä liikenne kulkee VPN-sovittimen (esimerkiksi tun0 tai wg0) kautta ja mikä fyysisen verkkokortin kautta. Suodattimella !ip.addr==VPN_PALVELIMEN_IP && dns löydät nopeasti kaiken DNS-liikenteen, joka ei mene VPN-palvelimen kautta. Reititintasolla voit myös pakottaa koko kotiverkon käyttämään VPN:ää palomuurisäännöillä (esimerkiksi pfSensessä tai OPNsensessä), jolloin yksittäisen sovelluksen tai laitteen vuoto ei enää ole mahdollinen, koska koko liikenne pakotetaan kulkemaan tunnelin läpi tai estetään kokonaan. Jos rakennat omaa suojattua kotiverkkoa, kannattaa tutustua myös oppaaseemme oman WireGuard-palvelimen pystyttämisestä.

Toinen hyödyllinen tekniikka on niin sanottu canary-domain-testi: rekisteröi tai käytä olemassa olevaa aliverkkotunnusta, jota et koskaan käytä muuhun tarkoitukseen, ja katso omalta DNS-palveluntarjoajaltasi (jos ylläpidät omaa domainia) tuleeko kyselyjä sinun operaattorisi IP-avaruudesta VPN:n ollessa päällä. Jos kyselyjä tulee, tiedät varmasti että DNS-liikenne karkaa tunnelin ohitse. Tämä on erityisen hyödyllinen tekniikka silloin, kun epäilet vuotoa, mutta yleiset testityökalut eivät sitä toistuvasti löydä. Jos vertailet vielä eri palveluntarjoajia keskenään, katso myös artikkelimme NordVPN:n, ProtonVPN:n ja Mullvadin vertailusta.

Kolmas edistynyt keino on niin sanottu multi-hop- tai kaksoishyppy-yhteys, jossa liikenne kulkee kahden peräkkäisen VPN-palvelimen kautta eri maissa. Tämä ei poista tässä oppaassa käsiteltyjä perusvuototyyppejä, mutta pienentää yhden palvelimen tai palveluntarjoajan kompromettoitumisen aiheuttamaa riskiä, koska kumpikaan yksittäinen hyppy ei näe sekä alkuperäistä IP-osoitettasi että lopullista kohdetta samanaikaisesti. Jos taas haluat sulkea vuotoreitit kokonaan pois yhtälöstä, itse ylläpidetty DNS-resolveri VPN-tunnelin sisällä (esimerkiksi Unbound-palvelu VPN-palvelimella) poistaa tarpeen luottaa mihinkään kolmannen osapuolen DNS-palveluun.

Pikatarkistuslista: 12 vaihetta yhdellä silmäyksellä

Kun olet käynyt oppaan läpi kertaalleen, tätä listaa voi käyttää nopeana muistilistana jatkossa aina, kun epäilet muutosta VPN-yhteytesi turvallisuudessa.

  1. Mittaa IP-osoite ja operaattori ilman VPN:ää ipleak.net-sivulla.
  2. Mittaa DNS-palvelimet ilman VPN:ää dnsleaktest.com-sivun standarditestillä.
  3. Kytke VPN päälle ja valitse kaukainen palvelin.
  4. Aja dnsleaktest.com:n extended-testi ja vertaa tulosta lähtötilanteeseen.
  5. Avaa browserleaks.com/webrtc ja tarkista ICE-kandidaatit.
  6. Korjaa WebRTC-asetukset selainkohtaisesti tarvittaessa.
  7. Tarkista IPv6-tila ja sulje se, ellei VPN tue sitä täysin.
  8. Vahvista IPv6-sulku uudella ipleak.net-testillä.
  9. Testaa kill switch sammuttamalla VPN-prosessi väkisin.
  10. Toista kill switch -testi Wi-Fi-verkon vaihdolla ja lepotilasta heräämisellä.
  11. Asenna ja ajasta automaattinen vpn-leak-check.sh-skripti.
  12. Toista koko lista jokaisen ison sovellus- tai käyttöjärjestelmäpäivityksen jälkeen.

Usein kysytyt kysymykset

Kuinka usein VPN-vuototesti kannattaa tehdä?
Kertaalleen asennuksen jälkeen ja aina VPN-sovelluksen, käyttöjärjestelmän tai selaimen ison päivityksen jälkeen. Automaattinen tuntikohtainen valvonta edellä esitellyllä skriptillä poistaa tarpeen muistaa tämä manuaalisesti.

Onko ilmainen VPN turvallisempi vai epäturvallisempi vuotojen suhteen kuin maksullinen?
MVPNalyzer-tutkimuksen mukaan vuotoja löytyi nimenomaan ilmaisista Android-sovelluksista, joista 29 kappaletta 281:sta vuoti liikennettä. Maksulliset, laajasti auditoidut palvelut kuten NordVPN, ProtonVPN ja Mullvad eivät sisältyneet tähän tutkimukseen samalla tavalla, ja niiden julkaisemat kolmannen osapuolen auditoinnit ovat toistaiseksi löytäneet huomattavasti vähemmän ongelmia.

Riittääkö selaimen sisäänrakennettu yksityinen selaustila estämään vuodot?
Ei riitä. Yksityinen selaustila estää vain paikallisen historian tallentumisen, ei DNS- tai WebRTC-vuotoja, jotka tapahtuvat verkkotasolla riippumatta selaimen tallennusasetuksista.

Voiko VPN-vuoto paljastaa täsmällisen sijaintini?
DNS- ja IP-vuoto paljastavat yleensä operaattorin ja karkean maantieteellisen alueen, ei tarkkaa katuosoitetta. WebRTC-vuoto voi paljastaa myös paikallisverkon IP-osoitteen, mikä on tarkempi mutta ei sekään yksin riitä täsmälliseen paikannukseen.

Toimivatko samat testit myös reititinpohjaisella VPN-yhteydellä?
Kyllä, mutta tulos kuvaa silloin koko kotiverkkoa yksittäisen laitteen sijaan. Reititintason VPN on usein tehokkain tapa estää vuotoja, koska yksittäisten sovellusten tai käyttöjärjestelmien virheelliset asetukset eivät pääse ohittamaan tunnelia.

Mitä teen, jos löydän vuodon enkä pysty korjaamaan sitä itse?
Ota yhteyttä VPN-palveluntarjoajan tukeen ja liitä mukaan tarkat testitulokset (dnsleaktest.com-linkki tai kuvakaappaus). Useimmilla suurilla palveluilla on erillinen DNS-suojausasetus, joka ratkaisee ongelman ilman käyttöjärjestelmätason muutoksia.

Vaikuttaako vuototestaus VPN-yhteyden nopeuteen?
Ei pysyvästi. Testit itsessään kuluttavat vain muutaman kilotavun liikennettä. Automaattinen tuntikohtainen valvontaskripti tekee yhden kevyen kyselyn kerran tunnissa, mikä ei ole mitattavissa normaalikäytössä.

Onko olemassa yhtä työkalua, joka testaa kaikki kolme vuototyyppiä kerralla?
ipleak.net on lähimpänä tätä, sillä se näyttää IP-osoitteen, DNS-palvelimet ja WebRTC-tiedot samalla sivulla. Silti kannattaa täydentää tulosta browserleaks.com/webrtc-sivun tarkemmalla WebRTC-erittelyllä, koska se paljastaa yksityiskohtia, joita ipleak.net ei näytä.

Kannattaako IPv6 sulkea kokonaan vai riittääkö VPN-sovelluksen oma suojaus?
Jos VPN-palveluntarjoajasi ilmoittaa selkeästi tukevansa täyttä IPv6-tunnelointia, oman sovelluksen suojaus voi riittää. Epävarmoissa tilanteissa IPv6:n kokonaan sulkeminen käyttöjärjestelmätasolla on varmempi vaihtoehto, koska se poistaa vuotomahdollisuuden riippumatta siitä, toimiiko VPN-sovelluksen oma suojaus odotetusti jokaisessa tilanteessa.

Mitä eroa on DNS-vuodolla ja WebRTC-vuodolla käytännön riskin kannalta?
DNS-vuoto paljastaa yleensä vain sen, mitä verkkotunnuksia selaat, ja karkean sijaintisi operaattorin kautta. WebRTC-vuoto voi paljastaa suoraan julkisen IP-osoitteesi tarkemmalla tasolla, mikä mahdollistaa tarkemman sijainnin päättelyn kolmannen osapuolen palvelun (esimerkiksi IP-osoitteeseen sidotun sijaintitietokannan) kautta. Molemmat kannattaa siis tulkita vakavina, mutta WebRTC-vuoto on tyypillisesti se, joka paljastaa eniten yksityiskohtia yhdellä kertaa.