Een complete gids voor IP-lekbescherming

Een van de belangrijkste redenen om een ​​VPN te gebruiken, is om uw echte IP-adres te verbergen. Wanneer u een VPN gebruikt, wordt uw internetverkeer gecodeerd en verzonden naar een VPN-server die wordt uitgevoerd door uw VPN-provider, voordat u het internet verlaat.


Dit betekent dat externe waarnemers alleen het IP-adres van de VPN-server kunnen zien en niet uw echte IP-adres. De enige manier voor hen om uw echte IP-adres te ontdekken, is daarom uw VPN-provider te overtuigen om het aan hen te overhandigen (en goede providers gebruiken robuuste maatregelen zoals het gebruik van gedeelde IP's en houden geen logboeken bij om dit zo moeilijk mogelijk te maken).

Helaas is het soms voor websites mogelijk om uw ware IP-adres te detecteren, zelfs wanneer u een VPN gebruikt.

Dit artikel heeft als antwoord: wat is een IP-lek, waarom lekt mijn IP, hoewel ik verbonden ben met een VPN, en hoe los ik het probleem op??

Hoe te testen op een DNS-lek of IP-lek

Om te bepalen of u een IP-lek lijdt:

1. Ga naar ipleak.net zonder VPN. Noteer alle IP-adressen die u ziet (of laat het venster gewoon open), want dit zijn uw echte IP-adressen.

Dit is hoe onze IPv6-compatibele kantoorverbinding eruit ziet zonder dat een VPN actief is. Als uw verbinding niet geschikt is voor IPv6, ziet u alleen IPv4-adressen. Zoals we kunnen zien, rapporteert WebRTC ons echte IPv6-adres correct. Als we geen IPv6-capaciteit hadden, zou dit in plaats daarvan ons IPv4-adres rapporteren.

WebRTC rapporteert ook een privégebruik (IANA privé- of speciaal adres), maar dit betreft ons niet. Deze privégebruikadressen zijn interne adressen die alleen door uw lokale netwerk worden gebruikt.

Zelfs als WebRTC een echt privé-IP-adres retourneert wanneer een VPN actief is, is dit geen privacyrisico, omdat deze niet kunnen worden gebruikt om u te identificeren via internet.

2. Schakel uw VPN in. Hoewel niet strikt noodzakelijk, maakt verbinding met een VPN-server in een ander land het opsporen van IP-lekken veel eenvoudiger.

3. Open een privé- / incognitovenster in uw browser, bezoek ipleak.net opnieuw en vergelijk de resultaten met de resultaten die u hebt verkregen zonder dat de VPN actief was.

  • Als het normale IPv4-adres uw echte IPv4-adres is, is de VPN niet ingeschakeld of werkt deze gewoon niet.
  • U kunt privégebruik-IP's die door WebRTC zijn gedetecteerd, negeren. Zoals reeds besproken, vormen deze geen bedreiging voor uw online privacy en daarom tellen ze niet als een IP-lek (in praktische termen hoe dan ook).
  • Als een ander adres op de ipleak.net-webpagina overeenkomt met uw echte adres, dan werkt de VPN maar lekt uw IP-adres op de een of andere manier.

Het goede

Verbinding maken met een Amerikaanse VPN-server uit het VK, hieronder is het resultaat dat we willen zien.

  • Het IPv4-adres is gewijzigd in de locatie van de VPN-server. Dus de VPN werkt.
  • IPv6 is uitgeschakeld of geblokkeerd om regelmatige IPv6-lekken te voorkomen.
  • WebRTC detecteert ons echte IPv4- of IPv6-adres niet. We kunnen het privégebruik-adres negeren omdat het onze privacy niet bedreigt.
  • De gebruikte DNS-servers behoren niet tot onze ISP en worden in het juiste land opgelost.

Als DNS wordt opgelost in de buurt van waar de VPN-server zich bevindt, suggereert dit sterk dat de VPN-service daar zijn eigen DNS-server (s) uitvoert.

Als u meerdere DNS-geadresseerden ziet die zich alleen in een groter land of geografisch gebied bevinden, wordt DNS-vertaling waarschijnlijk uitgevoerd door een externe DNS-resolver zoals Google DNS.

Dit is geen probleem, zolang we ervan uitgaan dat de DNS-aanvragen via de VPN-verbinding worden verzonden en daarom worden benaderd door de VPN-server (een redelijk veilige veronderstelling, hoewel je het nooit weet).

Helaas is er meestal geen gemakkelijke manier voor een eindgebruiker om te weten of DNS-aanvragen die door een externe resolver worden afgehandeld, worden benaderd door de VPN-service of rechtstreeks naar de resolver worden verzonden. Je moet dus gewoon je provider vertrouwen (of overschakelen naar een provider die zeker zijn eigen DNS-servers heeft).

Het is vermeldenswaard dat Google DNS alle Europese DNS-aanvragen op servers in Nederland en België afhandelt. Dus als u verbonden bent met een VPN-server in het Verenigd Koninkrijk, Frankrijk of Roemenië, maar de DNS-server zich in België bevindt, is dat de reden. En het is geen probleem (zolang we ervan uitgaan dat de DNS-aanvragen proxy zijn en niet rechtstreeks naar Google worden verzonden).

De slechte

Dit is een voorbeeld van wat u niet wilt zien wanneer u vanuit het VK verbinding maakt met een VPN-server in Duitsland.

  • Het IPv4-adres is gewijzigd in een Duits, dus de VPN werkt op een basisniveau.
  • We kunnen echter nog steeds ons echte reguliere IPv6-adres zien. Dit betekent dat we een regelmatig IPv6-lek hebben (of gewoon “IPv6-lek”).
  • WebRTC rapporteert ook ons ​​echte IPv6-adres. We hebben dus een WebRTC IPv6-lek.
  • De DNS-adressen bevinden zich niet in Duitsland, maar behoren ook niet tot onze echte ISP. Dus ze vormen geen DNS-lek.

Hieronder leggen we uit wat de verschillende soorten IP-lekken zijn en hoe ze kunnen worden opgelost. In alle gevallen is een vaak ongeschreven maar aanbevolen oplossing echter om de VPN-service te wijzigen in een die niet lekt.

Regelmatige IPv6-lekken

IPv4 begrijpen

Elke internetverbinding heeft een uniek numeriek adres dat een IP-adres (Internet Protocol) wordt genoemd. De IP-adressen (of alleen "IP's") worden toegewezen door de internetprovider (ISP) die het apparaat verbindt.

Tot voor kort gebruikte het hele internet de standaard Internet Protocol versie 4 (IPv4) om IP-adressen te definiëren. Dit ondersteunt een maximaal 32-bit internetadres, wat zich vertaalt in 2 ^ 32 IP-adressen (ongeveer 4,29 miljard) beschikbaar voor toewijzing.

Helaas, dankzij de ongekende toename van internetgebruik in de afgelopen jaren, raken IPv4-adressen op. Technisch gezien hebben ze dat zelfs al gedaan, hoewel tijdelijke oplossingen betekenen dat IPv4 nog steeds verre van dood is. Momenteel gebruikt de overgrote meerderheid van internetadressen nog steeds de IPv4-standaard.

IPv6 begrijpen

Hoewel verschillende mitigerende strategieën zijn ingezet om de houdbaarheid van IPv4 te verlengen, komt de echte oplossing in de vorm van een nieuwe standaard - IPv6. Dit maakt gebruik van 128-bit webadressen, waardoor het maximaal beschikbare aantal webadressen wordt uitgebreid tot 2 ^ 128 (ongeveer 340 miljard miljard miljard!). Dat zou ons voorzien van IP-adressen voor de nabije toekomst.

De acceptatie van IPv6 was echter traag - voornamelijk vanwege upgradekosten, bezorgdheid over de achterstand en pure luiheid. Hoewel alle moderne besturingssystemen IPv6 ondersteunen, maakt de overgrote meerderheid van ISP's en websites dit nog niet uit.

Dit heeft ertoe geleid dat websites die IPv6 ondersteunen, kiezen voor een tweeledige aanpak. Wanneer verbonden met vanaf een adres dat alleen IPv4 ondersteunt, zullen ze een IPv4-adres serveren, maar wanneer verbonden met een adres dat IPv6 ondersteunt, zullen ze een IPv6-adres serveren.

Dit heeft ertoe geleid dat websites die IPv6 ondersteunen, kiezen voor een tweeledige aanpak. Wanneer verbonden met een adres dat alleen IPv4 ondersteunt, zullen ze een IPv4-adres serveren. Maar wanneer verbonden vanaf een adres dat IPv6 ondersteunt, zullen ze een IPv6-adres serveren.

Totdat IPv4-adressen opraken, is er geen nadeel aan het gebruik van een alleen IPv4-verbinding.

IPv6 VPN-lekken

Helaas heeft veel VPN-software IPv6 niet ingehaald. Wanneer u verbinding maakt met een IPv6-website vanaf een IPv6-internetverbinding, zal de VPN-client uw IPv4-verbinding routeren via de VPN-interface, maar is volledig onbewust van de IPv6-verbinding die ook wordt gemaakt.

Dus de website zal uw echte IPv4-adres niet zien, maar wel uw IPv6-adres. Die kan worden gebruikt om u te identificeren.

Oplossingen

1. Gebruik een VPN-client met IPv6-lekbescherming

Alle goede VPN-clients bieden tegenwoordig IPv6-lekbescherming. In de meeste gevallen wordt dit gedaan door IPv6 op systeemniveau uit te schakelen om ervoor te zorgen dat IPv6-verbindingen eenvoudig niet mogelijk zijn. Dit is iets van een luie oplossing, maar het werkt goed.

Technischer indrukwekkend zijn VPN-apps die IPv6-verbindingen correct routeren via de VPN-interface. Dit is een veel elegantere oplossing en is ongetwijfeld de toekomst voor alle VPN-apps.

Als de aangepaste software van uw VPN-provider normale IPv6-lekken niet voorkomt, kunt u in plaats daarvan een app van derden gebruiken. OpenVPN GUI voor Windows, Tunnelblick voor macOS, OpenVPN voor Android en OpenVPN Connect voor iOS (en andere platforms) bieden allemaal effectieve IPv6-lekbescherming.

2. Schakel IPv6 handmatig uit op uw systeem

De meest zekere manier om IP-lekken te voorkomen, is IPv6 op systeemniveau uit te schakelen (waar mogelijk). Bekijk onze gids over Hoe IPv6 op alle apparaten uit te schakelen voor instructies over hoe u dit kunt doen.

DNS-lekken

DNS-lekken zijn de meest bekende vorm van IP-lekken omdat dit de meest voorkomende vorm was. In de afgelopen jaren zijn de meeste VPN-services echter naar een hoger niveau getreden en in onze tests detecteren we DNS-lekken veel minder vaak.

Het Dynamic Name System (DNS) wordt gebruikt om de gemakkelijk te begrijpen en te onthouden webadressen die we kennen (URL's) te vertalen naar hun “echte” numerieke IP-adressen. Bijvoorbeeld, de domeinnaam www.proprivacy.com vertalen naar zijn IPv4-adres van 104.20.239.134. Dus in wezen is DNS gewoon een luxe telefoonboek dat URL's koppelt aan hun overeenkomstige IP-adressen.

Dit DNS-vertaalproces wordt meestal uitgevoerd door DNS-servers van uw internetprovider (ISP). Bij grotere ISP's is het waarschijnlijk dat DNS-vragen geografisch dicht bij u (bijvoorbeeld ergens in uw stad) worden opgelost, maar dit is niet altijd het geval.

Wat zeker is, is dat DNS-vragen worden opgelost in het land waar uw internetprovider is gevestigd (d.w.z. uw eigen land). Overal waar de DNS-query wordt opgelost, bevindt deze zich echter niet op uw IP-adres thuis. Maar…

Privacy risico's

Uw ISP kan zien wat u van plan bent

Het is uw ISP die uw DNS-vragen oplost, dus:

  1. Het kent het IP-adres waar ze vandaan kwamen.
  2. Het weet welke websites u bezoekt omdat het de URL's is die u typt in IP-adressen. De meeste ISP's over de hele wereld houden logboeken bij van deze informatie, die ze al dan niet routinematig delen met uw regering of politie, maar die ze altijd kunnen dwingen te delen.

Nu ... in de normale gang van zaken maakt dit eigenlijk niet zoveel uit, omdat uw ISP u rechtstreeks verbindt met de IP-adressen die u bezoekt. Dus het weet in elk geval welke websites u bezoekt.

Een VPN-server proxyt echter uw internetverbinding om te voorkomen dat uw ISP ziet wat u op internet doet. Tenzij het nog steeds uw DNS-vragen oplost, in welk geval het nog steeds (indirect) kan zien welke website u bezoekt.

Je kunt getraceerd worden

Websites kunnen de IP-adressen van DNS-servers zien en registreren die directe verbindingen met hen maken. Ze zullen uw unieke IP-adres niet op deze manier kennen, maar ze zullen weten welke ISP de DNS-query heeft opgelost en routinematig een tijdstempel maken van wanneer het gebeurde.

Als ze (of de politie bijvoorbeeld) een bezoeker willen identificeren, moeten ze eenvoudigweg de ISP vragen "wie heeft op dit moment een DNS-verzoek naar dit adres gedaan?"

Nogmaals, in de normale gang van zaken is dit niet relevant, omdat websites uw unieke IP-adres toch kunnen zien. Maar wanneer u uw IP-adres verbergt met een VPN, wordt het een belangrijk middel om VPN-gebruikers te "deanonimiseren".

Hoe DNS-lekken gebeuren

In theorie moeten bij het gebruik van een VPN alle DNS-aanvragen via de VPN worden verzonden, waar ze intern door uw VPN-provider kunnen worden afgehandeld of doorgestuurd naar een derde partij die alleen zal zien dat het verzoek van de VPN-server kwam.

Helaas slagen besturingssystemen er soms niet in om DNS-query's via de VPN-interface te routeren en in plaats daarvan naar de standaard DNS-server te sturen die is opgegeven in de systeeminstellingen (dit wordt de DNS-server van uw ISP tenzij u uw DNS-instellingen handmatig hebt gewijzigd).

Oplossingen

1. Gebruik een VPN-client met DNS-lekbescherming

Veel VPN-clients pakken dit probleem aan met de functie "DNS-lekbescherming". Dit maakt gebruik van firewallregels om ervoor te zorgen dat er geen DNS-aanvragen buiten de VPN-tunnel kunnen worden verzonden. Helaas zijn deze maatregelen niet altijd effectief.

We begrijpen niet waarom "DNS-lekbescherming" vaak een door de gebruiker te selecteren functie is die niet standaard is ingeschakeld.

Nogmaals, OpenVPN GUI voor Windows, Tunnelblick voor macOS, OpenVPN voor Android en OpenVPN Connect voor iOS (en andere platforms) bieden allemaal goede DNS-lekbescherming.

2. Schakel IPv6 uit

Merk op dat dit slechts een gedeeltelijke oplossing is, aangezien het op geen enkele manier IPv4 DNS-lekken voorkomt. Maar een van de belangrijkste redenen dat zelfs VPN-apps met DNS-lekbescherming DNS-lekken niet blokkeren, is dat ze alleen DNS-aanvragen firewallen naar IPv4 DNS-servers.

Omdat de meeste DNS-servers alleen IPv4 blijven, kunnen ze hier vaak mee wegkomen. Maar ISP's die IPv6-verbindingen bieden, bieden meestal ook IPv6 DNS-servers. Dus als een client alleen IPv4 DNS-aanvragen buiten de VPN-interface blokkeert, kunnen IPv6-aanvragen doorkomen.

3. Wijzig uw DNS-instellingen

Eigenzinnige DNS-zoekopdrachten die niet via de VPN-interface worden gerouteerd (zoals zou moeten), worden in plaats daarvan verzonden naar de standaard DNS-servers die zijn opgegeven in de instellingen van uw systeem.

Tenzij u deze al hebt gewijzigd, worden de DNS-serveradressen (IPv4 en IPv6 indien beschikbaar) automatisch van uw ISP verkregen. Maar u kunt het wijzigen en we hebben hier instructies voor.

Merk op dat het wijzigen van uw DNS-instellingen het probleem met de DNS-lekkage niet echt "verhelpt". Het is gewoon zo dat u DNS-verzoeken lekt naar een externe resolver in plaats van uw ISP.

Gelukkig zijn er nu enkele zeer goede privacygerichte DNS-services die geen logboeken bijhouden. Ze beschermen ook DNS-aanvragen met DNS via HTTPS (DoH) of DNS via TLS (DoT) DNS-codering, zonder welke uw ISP de DNS-aanvragen toch kan zien, zelfs als deze deze niet verwerkt.

Zie hier voor meer informatie over dit onderwerp, plus een lijst met aanbevolen gratis en privé-DNS-services.

Een opmerking voor Linux-gebruikers

Handmatige VPN-installatie in Linux, of u NetworkManager, de CLI OpenVPN-client, strongSwan of wat dan ook gebruikt, biedt geen DNS-lekbescherming. Gelukkig zijn er stappen die u kunt nemen om dit probleem op te lossen, hoewel ze het VPN-installatieproces bemoeilijken.

U kunt resolvconf wijzigen om DNS naar de DNS-servers van uw VPN te pushen, of u kunt de iptables-firewall handmatig configureren om ervoor te zorgen dat al het verkeer (inclusief DNS-aanvragen) uw Linux-machine niet buiten de VPN-tunnel kan verlaten. Lees onze opmerkingen over het bouwen van uw eigen firewall later in dit artikel voor meer informatie hierover.

WebRTC lekt

WebRTC-lekken zijn nu de meest voorkomende vorm van IP-lekkage die we in onze tests zien. Strikt genomen zijn WebRTC-lekken een browserprobleem, geen VPN-probleem, waardoor veel VPN-providers afstand hebben genomen van een probleem dat niet eenvoudig is op te lossen.

Naar onze mening is dit niet goed genoeg. Inderdaad, we denken ook niet dat het publiceren van een "How to Disable WebRTC" -gidsen diep verborgen in de helpsectie van een provider goed genoeg is,.

Wat zijn WebRTC-lekken?

WebRTC is een HTML5-platform dat naadloze spraak- en videocommunicatie mogelijk maakt in de browservensters van gebruikers. Bijna alle moderne browsers op bijna alle grote platforms ondersteunen nu WebRTC, inclusief Chrome, Firefox, Opera, Edge, Safari en Brave.

Een uitzondering is in iOS, waar alleen Safari WebRTC ondersteunt (althans zonder extra plug-ins).

Om naadloze browser-naar-browser communicatie te realiseren via obstakels zoals firewalls, zenden WebRTC-compatibele browsers uw echte IP-adres (sen) uit naar STUN-servers die een lijst bijhouden van de openbare IP-adressen van beide gebruikers en hun echte IP-adressen.

Iedereen die een WebRTC-gesprek met u (of gewoon elke nieuwsgierige website) wil beginnen, kan uw echte IP-adres aanvragen en de STUN-server zal het eenvoudig overhandigen.

Dit probleem wordt meestal een WebRTC-lek genoemd en wordt ook wel de 'WebRTC-bug' genoemd. Dit is een verkeerde benaming omdat het een opzettelijke en zeer nuttige functie van WebRTC is. Maar het is een echte pijn voor VPN-gebruikers die proberen hun echte IP-adres te verbergen!

Oplossingen

1. Schakel WebRTC uit in uw browser

Dit is de enige 100% effectieve manier om een ​​WebRTC-lek te voorkomen bij gebruik van een VPN. We raden aan dit te doen, zelfs als uw VPN-client effectief is in het verminderen van VPN-lekken.

In Firefox is het eenvoudig om WebRTC uit te schakelen. Typ "about: config" in de URL-balk om de geavanceerde instellingen van Firefox in te voeren, zoek naar "media.peerconnection.enabled" en dubbelklik op het item om de waarde te wijzigen in false.

Als alternatief (en in andere browsers) zijn er verschillende browserplug-ins die WebRTC kunnen uitschakelen, waaronder WebRTC, uBlock, uBlock Origin en NoScript uitschakelen. Sommige VPN-providers hebben een functie WebRTC uitschakelen in hun aangepaste browser-add-ons.

Een meer complete discussie over dit onderwerp is te vinden op Wat is de WebRTC VPN "Bug" en hoe dit te verhelpen?

2. Gebruik een VPN-service die WebRTC-lekken beperkt

WebRTC-lekken zijn een probleem met de browser, dus de enige echt effectieve manier om dit te voorkomen is door WebRTC in de browser uit te schakelen.

Dat gezegd hebbende, kunnen VPN-providers firewall-regels gebruiken en instellingen op zowel client- als VPN-niveau aanscherpen om de kans op WebRTC-lekken aanzienlijk te verkleinen. Geen enkele VPN-provider kan garanderen dat deze maatregelen werken, omdat websites altijd slimme JavaScript-code kunnen implementeren die is ontworpen om de kans op lekken te vergroten.

We hebben echter vastgesteld dat sommige VPN-services consistent effectief zijn in het voorkomen van VPN-lekken. We raden echter nog steeds aan om WebRTC op browserniveau uit te schakelen. Voor de zekerheid.

VPN-uitvallers en kill-schakelaars

Hoewel technisch gezien geen "IP-lek", omdat het probleem zich precies voordoet omdat u geen VPN-verbinding hebt, is het effect hetzelfde - u denkt dat u wordt beschermd door VPN, terwijl in feite de hele wereld uw IP-adres kan zien.

Wat is een VPN-drop-out?

Soms mislukken VPN-verbindingen, vaak om redenen die zelfs buiten de controle van zelfs de beste VPN-services vallen. . Als uw computer na dit blijft verbonden met internet, wordt uw echte IP-adres weergegeven.

Dit is met name een probleem voor P2P-downloaders die BitTorrent-clients laten draaien terwijl ze niet achter hun computer zitten (vaak voor lange tijd). Als de VPN-verbinding wegvalt, wordt hun echte IP-adres daarom blootgesteld aan auteursrechtenhandhavers die een torrent volgen die ze downloaden.

Het is ook een probleem voor mobiele gebruikers, omdat schakelen tussen WiFi en mobiele netwerken en schakelen tussen mobiele netwerken VPN-uitval kan veroorzaken.

Oplossingen

1. Gebruik een kill-schakelaar

Een kill-schakelaar voorkomt dat uw apparaat verbinding maakt met internet wanneer de VPN niet werkt. Bijna alle moderne kill-switches zijn eigenlijk firewalls of firewallregels op systeemniveau die alle internetverbindingen buiten de VPN-interface blokkeren.

Dus als de VPN-software mislukt of opnieuw verbinding moet maken, wordt alle toegang tot internet geblokkeerd. Inderdaad, dezelfde firewall-regels bieden effectieve DNS-lekbescherming en kunnen helpen bij het verminderen van WebRTC-lekken.

Doodschakelaars zijn nu een veel voorkomende functie in desktop VPN-clients, hoewel zeldzamer in mobiele apps. Android 7+ bevat echter een ingebouwde kill-schakelaar die werkt met elke geïnstalleerde VPN-app.

VPN-apps kunnen hun eigen firewall gebruiken om een ​​kill-schakelaar (en andere lekbescherming) te maken of de ingebouwde firewall van uw systeem wijzigen. We geven de voorkeur aan de laatste oplossing omdat de kill-schakelaar zal overleven, zelfs als de app volledig crasht. Maar elke kill-schakelaar is veel beter dan geen.

Bouw je eigen kill-schakelaar en DNS-lekbescherming met behulp van firewallregels

Zoals we hebben gezien, gebruiken veel VPN-apps hun eigen firewallregels of wijzigen ze uw systeemfirewallregels om een ​​kill-schakelaar te maken en DNS-lekken te voorkomen. Het is heel goed mogelijk om hetzelfde handmatig te doen.

Details verschillen per besturingssysteem en firewall-programma, maar de basisprincipes zijn:

1. Voeg een regel toe die al het uitgaande en inkomende verkeer op uw internetverbinding blokkeert.

2. Voeg een uitzondering toe voor de IP-adressen van uw VPN-provider.

3. Voeg een regel toe voor uw TUN / Tap-adapter (als u OpenVPN gebruikt, of voor een ander VPN-apparaat anders) om al het uitgaande verkeer voor de VPN-tunnel toe te staan.

We hebben een gedetailleerde gids om dit te doen met Comodo Firewall voor Windows. Mac-gebruikers kunnen hetzelfde doen met Little Snitch, terwijl Linux-gebruikers en gebruikers van een VPN-client op een DD-WRT-router iptables kunnen gebruiken.

Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me