NordVPN, Private Internet Access ja kümned teised VPN-teenused – enamik meist on neist kuulnud. Reklaamid lubavad rohkem privaatsust, turvalisust ja anonüümsust internetis.

Aga miks neid tegelikult vaja on?

Minu jaoks oli vastus üsna lihtne. Ma ei tahtnud, et iga veebileht – olgu see Google, Facebook või mõni muu teenus – saaks IP-aadressi põhjal liiga lihtsalt aru:

• kes ma olen
• kust ma tulen
• millise võrgu kaudu ma internetti kasutan

Seetõttu hakkasin uurima, kuidas ehitada süsteem, kus minu internetiliiklus ei läheks alati otse minu koduvõrgust välja.

Tahtsin lahendust, kus:

• mul on kontroll, millised seadmed kasutavad VPN-i
• VPN ei sõltu teenusepakkuja äpist
• kogu loogika toimib võrgu tasemel

Selles postituses kirjeldan, kuidas ma oma koduvõrgus selle lahenduse üles ehitasin.

Privacy VPN tunnel otse pfSense’is

Esimene disainiotsus, mille tegin, oli see, et privacy VPN tunnel jookseb minu koduses pfSense tulemüüris, mitte üksikutes seadmetes.

See tähendab, et minu pfSense toimib VPN kliendina, mis ühendub otse VPN teenusepakkuja serverisse.

Sellel lähenemisel on mitu praktilist eelist.

Esiteks tuleb VPN konfigureerida ainult ühes kohas.
Kui tunnel on pfSense’is olemas, saavad seda kasutada kõik seadmed minu võrgus.

Teiseks annab see mulle võimaluse teha routing'u otsuseid võrgu tasemel, mitte seadmete tasemel.

Näiteks saan pfSense’is otsustada:

• millised seadmed kasutavad VPN-i
• millised lähevad otse internetti
• milline liiklus läheb läbi millise gateway

See tähendab, et ma ei pea:

• installima VPN äppe igasse seadmesse
• haldama eraldi konfiguratsioone telefonides, arvutites või serverites

Kõik toimub võrgu keskpunktis – tulemüüri tasemel.

Selline arhitektuur on eriti mugav kodulabori või self-hosting keskkonna jaoks, kus võrgus võib olla palju erinevaid seadmeid ja teenuseid.

Miks just Mullvad?

Mullvad oli minu jaoks loogiline valik.

Põhjused:

• kasutajatunnus on lihtsalt random number string
• konto ei ole seotud e-maili ega nimega
• puudub tunne, et teenus üritab kasutaja kohta profiili ehitada

Aga ausalt – see, mis mind kõige rohkem üllatas:

Mullvadi veebilehel on pfSense jaoks väga korralik dokumentatsioon.

WireGuard tunnel, gateway, firewall reeglid ja policy routing – kõik on samm-sammult lahti kirjutatud.

pfSense konfiguratsioon sai tehtud umbes 15 minutiga.

See näitab, et teenusepakkuja mõtleb ka self-hostijatele ja network inimestele, mitte ainult mobiiliäppide kasutajatele.

Selektiivne routing - mitte VLAN, vaid alias

Alguses mõtlesin lahenduse teha VLAN-põhiselt.

Idee oli lihtne:
teatud VLAN → läheb privacy VPN-i kaudu internetti.

Päriselus osutus täpsemaks lahenduseks alias + policy based routing.

pfSense’is on loodud alias, kuhu olen lisanud ainult:

• konkreetsed seadmed
• mõned LXC konteinerid

Firewall reegel:

Source: PRIVACY_VPN_ALIAS
Gateway: Mullvad_WG_GW

See tähendab:

• terve subnet ei lähe VPN-i
• ainult need IP-aadressid, mis on aliases

Kui tahan seadme VPN-ist eemaldada, piisab lihtsalt IP eemaldamisest aliasest.

Selline lähenemine annab palju täpsema kontrolli kui VLAN-põhine routing.

Kill switch - teadlikult mitte kasutusel

Mõned inimesed konfigureerivad privacy VPN-i nii, et kui tunnel mingil põhjusel katkeb, blokeeritakse kogu internetiliiklus. Seda nimetatakse tavaliselt kill switch lähenemiseks.

See tähendab, et kui VPN ei tööta, ei pääse seadmed üldse internetti.

Minu koduvõrgus ma sellist konfiguratsiooni ei kasuta.

Kui Mullvadi tunnel ei ole aktiivne – näiteks teenus on maksmata või ühendus on maas – siis liigub liiklus lihtsalt tavalise WAN ühenduse kaudu internetti.

Minu jaoks on kättesaadavus olulisem kui täielik blokkimine.

Privacy VPN on minu arhitektuuris pigem:

• täiendav privaatsuskiht
• routing’u kontroll
• mitte absoluutne anonüümsuslahendus.

NetBird - teine kiht

Lisaks privacy VPN-ile kasutan ma oma võrgus NetBird overlay võrku.

Proxmoxis jookseb selle jaoks eraldi LXC konteiner, mille roll on nö exit node

See konteiner asub Guest VLANis.

Oluline detail:

NetBirdi exit node väljub internetti läbi Mullvad VPN-i.

See tähendab, et kui ma olen kodust eemal ja kasutan NetBirdi overlay võrku, siis minu liiklus liigub nii:

Client device
↓
NetBird tunnel
↓
Kodune exit node
↓
Mullvad VPN
↓
Internet

Sisuliselt tähendab see, et ka remote access liiklus läheb läbi sama privacy layer’i.

Guest VLAN - minimaalne attack surface

Exit node jookseb Guest VLANis, mis on tahtlikult väga piiratud.

pfSense’i reeglid selles VLANis:

• ainult outbound internet
• puudub ligipääs sisevõrgule
• puudub ligipääs haldusvõrkudele

Exit node ei expose’i:

• sisevõrgu teenuseid
• haldusliideseid
• teisi VLANe

See on ühefunktsiooniline komponent, mille ainus eesmärk on toimida exit node’ina.

Ligipääs sisevõrgule - policy tasemel

Sisevõrgu teenustele ligipääs ei käi firewall exceptionitega.

See on lahendatud NetBirdi Network Resource Policy kaudu.

See tähendab, et:

• määran milline kasutaja näeb millist teenust
• ligipääs on ACL-põhine
• teenused on defineeritud resource’idena

Näiteks on ka Pi-hole DNS sinkhole NetBirdis defineeritud eraldi resource’ina.

Miks mulle see setup meeldib

Selle arhitektuuri juures meeldib mulle kõige rohkem granulaarsus.

Ma saan täpselt kontrollida:

• milline seade läheb VPN-i
• milline ei lähe
• milline overlay klient näeb millist teenust
• kust mu liiklus väljub
• millised VLANid võivad omavahel suhelda

Mida ma sellest õppisin

Selle setupi ehitamise käigus sain mitu huvitavat õppetundi.

Privacy ei pea olema must-valge.

Provideri valikul loeb väga palju:

• läbipaistvus
• tehniline dokumentatsioon

Samuti selgus, et:

• Alias + policy based routing annab rohkem kontrolli kui subnet-põhine lahendus
• exit node rolli võib panna täielikult isoleeritud VLANi
• overlay võrk ja privacy VPN võivad töötada mitme kihina koos