VPN. Igazán sokrétűen használható eszköz. Az otthoni hálózat biztonságos elérése, internetezés biztonságosan nyilvános Wi-Fi-n stbstbstb. Egy biztos. a VPN fő atrakciója mindig is a biztonság volt, és jelenleg is az. Nagyon ritka az az eset, amikor a biztonság másodlagos, no persze van ilyen is.
A biztonság viszont általában a sebesség rovására megy. Vagy a sebesség a biztonságéra. Megannyi VPN-megoldás van, többféle titkosítási módszerrel. Ott az L2TP + IPSEC kombó, vagy épp az OpenVPN, esetleg régebbi és kevésbé biztonságos a PPTP.
Ezért ma megnézünk egy igazán egyszerűen konfigurálható, biztonságos, gyors és multiplatformos megoldást. A WireGuard-ot.
A WireGuard 2015-ben indult el, és még mindig nem ért el az 1.0-ás stabil kiadáshoz. Folyamatosan fejlesztik. Azonban ez nem probléma, már most kismillió eszközre telepíthető és konfigurálható. Egy Debian-os, Ubuntu-s gép épp olyan jó lehet VPN szervernek mint egy EdgeRouter, kihasználva, hogy az EdgeOS egy Debian alapú disztró.
előnyei többek közt az SSH-hoz hasonlatos publikus-privát kulcspárok használata, egyszerű és könnyen fejleszthető kód, és a beépített roaming. A lista közel sem teljes, a kódról - révén nem vagyok programozó - nem tudok nyilatkozni, viszont az utolsó elemre érdemes kitérni. Tehát ha fellépünk a VPN-re, és váltunk mobilnet és az otthoni wi-Fi közt, a VPN-ben futó kapcsolataink elvileg nem fognak megszakadni. Például a TeamTalk nem dob le, az SSH-kapcsolatok nem szakadnak meg. Képes tehát úgy lekezelni az átmenetet, hogy a nyitott kapcsolatok ne záruljanak be.
Ezeken kívül is számos előnyt tud felmutatni, a hivatalos oldalon egész kis litánia olvasható, de az sem maradt ki, miért jobb mint a többi megoldás.
Az útmutatóban arra fogunk koncentrálni, hogy egy otthoni Debian 10-es gépből hogyan lehet szervert csinálni. Az EdgeRouter-es megoldásról itt egy remek cikk magyarul, de OpenWRT-re is telepíthető, igaz, a leírás angol, de hivatalos. Talán Windows-on lehet a legnehezebb összehozni a szervert, de azt őszintén bevallom, soha nem próbáltam.
Első körben a VPN szervert fogjuk előkészíteni, utána pedig a klienseket. Már elöljáróban leírom, hogy a kulcsgenerálásnak és több más lépésnek is van eltérőbb megvalósítási formája, én igyekszem azt megmutatni, ami hosszútávon a leglogikusabb.
Telepítés Debian-ra
a kliens és a szerver egyetlen csomag itt is, akár az OpenVPN-nél. A használt konfiguráció dönti el a betöltött szerepet.
A telepítés a buster-backports, bulseye és sid tárolókból ejthető meg. Azaz ha valaki nem busteren van, akkor a fejlesztői ágról tudja leszedni magának a csomagot, az alábbi parancsokkal.
A telepítéshez először hozzá kell adni az unstable ágat, majd telepíteni a programot. Itt van annyi trükk, hogy ami elérhető stabilként, azt nem fogja unstable-ből pakolgatni, vagy is a rendszerünk stabilitása nincs veszélyben. A parancsok:
sudo su
echo "deb http://deb.debian.org/debian/ unstable main" > /etc/apt/sources.list.d/unstable.list
printf 'Package: *\nPin: release a=unstable\nPin-Priority: 90\n' > /etc/apt/preferences.d/limit-unstable
apt update
apt install wireguard
Linuxdisztró révén a kernelbe betöltögeti a moduljait, némi türelemre lesz szükség. Amennyiben SecureBoot-tal megáldott EFI-s gépre telepítünk, alá kell írnunk a kernelt. SecureBoot - a Debian Wiki-ben
További operációsrendszerekhez a letöltés és telepítés menete itt található.
Ha a telepítés kész, továbbra is root-ként ténykedjünk, vagy minden parancshoz használjuk a sudo-t.
Hozzuk létre a wireguard mappáját, és lépjünk is bele:
mkdir /etc/wireguard
cd /etc/wireguard
Mivel az ittlévő fájlok igen csak bizalmas adatokat tartalmaznak, ezért létrehozásuk előtt beállítjuk, hogy csak a root férjen hozzájuk. Ez a módosítás csak az aktuális munkamenetre vonatkozik!
umask 077
Következő lépésben létrehozzuk a szerver privát kulcsát. Ezt soha nem adjuk meg senkinek, csak a szerver tudja és neki van rá szüksége!
wg genkey > privkey
Ebből pedig legeneráljuk a publikus kulcsot, ezt kell ismerni a klienseknek a csatlakozáshoz.
wg pubkey < privkey > pubkey
A publikus kulcs mindig a privátból készül. A < jellel beolvassuk a privkey fájl tartalmát, hogy legyen miből generálni, majd a > jellel a pubkey fájlba írjuk. Egyszerű, nem? De!
Megvannak a kulcsok, most jön a konfigurációs rész. Előrejáróban mondom, hogy minden peer-t hozzá kell adni a konfigfájlhoz, ezért vissza fogunk még térni ide. Illetve a konfigfájl szerkesztés helyett van lehetőség a wg (man wg) nevű eszközzel elkészíteni az állományt, de én maradok a kézi szerkesztésnél.
A WireGuard interfésze bármilyen nevet felvehet, ami még szabad. Legyen a wg0, mert mindenki így nevezi, ez a logikus és amúgy is lusta vagyok hosszabb nevet gépelni.
Hozzuk hát létre az ő konfigfájlját!
touch wg0.conf
Majd szerkesszük is a kedvenc szerkesztőnkkel, például nano.
nano wg0.conf
És így fog kinézni a fájl.
[Interface]
Address = 10.1.1.1/24
SaveConfig = false
ListenPort = 4000
PrivateKey = XXX
Az első sorral adjuk meg, hogy interfészbeállítások következnek. Közvetlen alatta adjuk meg az interfész címét. Tud IPv4-et és IPv6-ot is. Előbbit beállítjuk, utóbbit egyenlőre nem eröltetjük, mert az itthoni változó prefixes IPv6 megoldásokat sajnos nem támogatja, így fix v6 kell hozzá. VPS-eken illetve egyéb fix címmel rendelkező gépeken ez megoldott, de ezek köre még igen szűkös. Jelenleg a v4 is teljesen elég.
A címhez természetesen megadjuk a maszkot is, /24 (255.255.255.0) azaz a 10.1.1.1--10.1.1.254 tartományt jelenti, a 10.1.1.255 a broadcast (szórási) cím.
SaveConfig, értéke false, nem engedi belepiszkálni a konfigba a wg parancsot. Ha ez nincs bekapcsolva, akkor futó WireGuard mellett szerkesztett beállításaink könnyen repülhetnek valahova, mint ha a /dev/null-ba írtuk volna azokat.
A ListenPort az az UDP port, ami fogadja a bejövő kapcsolatokat, az utolsó sor pedig a privkey tartalma, az XXX-et arra kell kicserélni, írásjelekkel, mindennel. Ha a privát kulcs nem lenne meg fejből, akkor cat privkey.
Ha átírtuk a nekünk tetsző adatokra, mentsük el a fájlt, és ezzel egyenlőre megvagyunk. Most jön a kliens.
Telepítés Windows-ra
Windows-ra itt lehet letölteni, értelemszerűen architektúrának megfelelően. Egy sima MSI installer, elindít, felrakja a maga pár MB-os fájlját, és a WinTun nevű adaptert, ezzel lesz majd megoldva a VPN-csatlakozás.
Telepítés után vagy elindul az alkalmazás, vagy ha nem, márpedig nem fog, a startmenüből kell megtenni. Az asztalra nem rak parancsikont, akinek ezirányú igénye van, azt magának kell pótolni.
Megnyitás után kedvszerint vagy felugrik az ablaka, vagy a rendszertálcán lévő ikonra kell jobklikk, majd manage tunnels-t nyomni.
Kliens oldalon is szükségünk lesz kulcspárra. Több mód is van az előállításra.
Egyrészt használhatjuk a WireGuard alkalmazásának Add Tunnel (CTRL+n) gombját, amikor is meg kell adnunk egy nevet, illetve a további adatokat. Ahogy látható is, a publikus és privát kulcsokat ilyenkor létrehozza maga, a publikus fog kelleni a szerveren, a privát meg csak itt. A szerkeszthető részre kell beadni a többi paramétert (helyi cím, távoli cím stb.).
Másik módszer a parancssoros kulcsgeneráló megoldás, és ilyenkor célszerűen a konfigfájl kézi szerkesztése. Ennek annyi előnye van, hogy rögvest tudjuk menteni a konfigot. Ehhez nyissunk egy CMD-t, navigáljunk egy tetszőleges mappába, majd adjuk ki az alábbi két parancsot:
wg genkey > privkey.txt
wg pubkey < privkey.txt > pubkey.txt
Az első parancs kiadása után elkezd majd nyígni, hogy bárki által olvasható a privát kulcs, ezzel nem kell foglalkozni.
Warning: writing to world accessible file.
Consider setting the umask to 077 and trying again.
Néha nagyon Unix/Linux környezetben érzi magát, de ne zavarjuk meg ebben, ő se zavar minket!
Ha így vagy úgy megvan a kulcspár, ismét két út áll előttünk. Az egyik a grafikus út, amikor a korábbi Add Tunnel gomb megnyomása után fel kell vinni az adatokat, a másik, hogy létrehozunk egy .conf állományt, és később húzzuk be a WG alkalmazásába.
Így kell kinéznie a helyi konfignak:
[Interface]
PrivateKey = XXX
Address = 10.1.1.2/24
DNS = 1.1.1.1
[Peer]
PublicKey = XXX
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint =
PersistentKeepalive = 25
A legtöbb sor hasonló a fenntebbi társaihoz. A privát részre jön a helyi privát kulcs, ezt ugye nem piszkáljuk grafikus felületen, .conf-os megoldásnál meg lecseréljük sajátra. Az IP a kliens címe, és itt fontos figyelni rá, hogy a Windows nem támogatja a /32-es címeket, szóval /30-at lehet neki megadni, vagy én /24-et szoktam, mint amennyi a teljes tartomány is.
A DNS a névfeloldó szerver, itt arra érdemes figyelni, hogy véletlenül se adjuk meg a VPN átjáróját, mert döntő többségében a Linuxos gépeken nincsen DNS kiszolgáló (Bind9, PiHole), így a kérésekre nem tudnak majd válaszolni. Az eredmény pedig az lesz, hogy nem fog működni a névfeloldás. Ezért itt a CloudFlare névszervere van megadva. Nem fizetett reklám!:)
A Peer részen vannak a távoli gép infói, vagy is a szerveré. A public key a szerver publikus kulcsa, az AllowedIPs az engedélyezett IP-tartományok, jelen formájában minden IPv4-en és IPv6-on is (míg ha utóbbi nincs is beállítva).
Az Endpoint host:port formában kéri az átjáró adatait, akár domain ([email protected]), akár IP-cím. Az alul lévő PersistentKeepalive pedig jelen példában 25 másodpercenként küld egy üres csomagot, hogy fenntartsa a kapcsolatot, NAT-olt környezetben ez fontos mert különben zárja az alagutat, de soha nem lehet tudni, honnan lép fel az ember...
A grafikus felületen a privát kulcs hatására a publikus dinamikusan generálódik, tehát ha véletlen felülírtuk, akkor sincs gond, a publikus mindig az aktuális priváthoz tartozó információ.
Ha szövegszerkesztővel készül a konfig, mentsük le, és az Import Tunnel (CTRL+o) paranccsal nyissuk meg a fájlt. A tunnel, vagy is szabad fordításban alagút, neve a fájlnév .conf előtti része lesz.
Akár így, akár úgy, de ha bekerült a tunnel a programba, akkor az Edit (CTRL+e) paranccsal lehet szerkeszteni. Itt kiemelném a Block untunneled traffic (kill-switch) pipát. Ha be van jelölve, az alagút felépültekor minden új és meglévő kapcsolatot belerak a tunnelbe, tehát minden megszakad, és nem tud kiszökni a VPN-ből. Ha fontos az adatvédelem, feltétlenül engedélyezzük.
Irány megint vissza a szerverre. Szükségünk lesz a gépünk publikus kulcsára. Ha nem írtuk fel, csak legyen kijelölve a tunnelek listájában a legutóbb hozzáadott - és vélhetően egyetlen - elem, és a Status alatt írja az áhított információt.
Ismét szerkesztjük a wg0.conf állományt, és ezt hozzáadjuk.
[Peer]
PublicKey = XXX
AllowedIPs = 10.1.1.0/24, 10.1.1.2/32
PersistentKeepalive = 25
A publikus kulcs a kliens kulcsa, az AllowedIPs pedig azért néz ki így, mert először van a teljes tartomány, hogy lássák egymást a kliensek. Ha nem kell, csak a vessző utáni bejegyzés maradjon, ami pedig megadja a kliens által használható IP-címet.
Mentés, és kilépés.
Utolsó lépésként pedig indíthatjuk a WG-t. Erre is több lehetőség van. Lehet mindent kézzel csinálni, az interfészt felépíteni, konfigfájlhoz kötni. Lehet dolgozni a wg-quick nevű eszközzel, ami ezeket megteszi, végül pedig ezutóbbi kombinálható a systemctl-lel, így az automatikus indítás is megoldható.
Először ellenőrizzük, elindul-e rendesen:
wg-quick up wg0
Ha igen, érdemes rögvest megállítani.
wg-quick down wg0
Ha nem indul, ellenőrizzük mi fáj neki. A fenntebb írt SecureBoot tipikusan ilyen, hogy be tud kavarni, érdemes tanulmányozni a korábban linkelt szócikket.
Eztán már beállítható Systemctl-lel az automatikus indulás:
systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0
Az állapota is ellenőrizhető:
systemctl status wg-quick@wg0
Ha később újabb peereket adnánk hozzá, akkor csak azokat a lépéseket kel ismételni, ahol a klienst állítottuk be, minden kliensnek kell külön peer bejegyzés a szerveren. Azaz felvesszük a szerver oldalon a klienst, utána fordítva, és újraindítjuk, leggyakrabban a systemctl-lel.
Utolsó lépés a szerver tűzfalán beengedni az UDP 4000-es portot, illetve megvalósítani a NAT-olást.
Tűzfalkonfig a Linuxon
Mivel épp mostanság állunk át a Linuxdisztrókban Iptables-ről Nftables-re, ezért megnézzük mindkét tűzfal esetén a megvalósítást. Mindkét esetben masquerade-del fogunk dolgozni, ami a source NAT egy formája. Röviden annyit tesz, hogy a kimeneti cím megállapítása automatikusan történik, befelé pedig a related és established csomagok jönnek, újak nem. A forrás IP-t viszont nem kell megadni a tűzfalon, mert automatikusan belövi a csomag alapján, így nyilván a válasz is tudja, merre kell mennie. Ez a beállítás hasznos amúgy más VPN megoldásoknál, például OpenVPN.
NFT
Mivel az NFT korszerűbb és kényelmesebb, először ezt nézzük. Egyrészt a CLI részről hozzá lehet adni így:
nft add table nat
nft add chain nat POSTROUTING { type nat hook postrouting priority 100 \; }
nft add rule nat POSTROUTING oif eth0 masquerade
Először a NAT tábla jön létre, majd a szörnyen kreatív nevű POSTROUTE láncot akasztjuk a postroute hook-ra, végül hozzáadjuk a szabályt.
Azt érdemes még tudni, hogy ugyan Iptables-szel egyetlen parancsból megoldható ez az egész, azonban ott fix láncok és táblák vannak, míg itt egy táblában bármilyen nevű láncból bármennyi lehet, csak a hookkal kell beállítani megfelelően a feladatát.
Haladó tűzfalasoknak innen már egyértelmű, hogy kell belementeni a többi szabály mellé egy fájlba. Akinek nincs NFT beállítva, az alábbi parancsokkal tudja lementeni az nftables.conf-ba ezt, hogy a következő indításnál is működjön:
cd /etc
nft list ruleset > nftables.conf
systemctl enable nftables
Iptables
Itt egyszerű a történet. Ennyit kell írni.
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Ha meg akarjuk őrizni a következő újraindítás utánra is, akkor az iptables-persistent csomagot rakjuk fel, és telepítéskor írassuk ki az aktuális v4-es szabályokat.
Érdemes viszont az Iptables-t leváltani az NFT-vel, mert ez a jövő, és előbbi már amúgy is csak kompatibilitási okokból van benne a rendszerben.
Az UDP 4000-es port megnyitását direkt nem mutattam. A tűzfal alapból átengedi az összes többivel együtt. Ha nem, akkor pedig a korábbi beállítás miatt ehhez is esélyesen megvan a kellő tudás.
Ha a tűzfal is kész, semmi nem hiányzik a csatlakozáshoz! A Windows-os kliensben klikkeljünk az egyetlen elemre a listában, és már fel is épül a tunnel. A bontás hasonlóan történik. Érdemes szemelőtt tartani, hogy ha egy alagút aktív, akkor újraindítás után is felépül, tehát magától semmilyen esetben sem szabad megszakadnia.
Végszó, jótanácsok
A leírás végére szeretnék adni pár jótanácsot.
A legfontosabb, hogy nekem problémás volt a belső hálózatom elérése ha onnan léptem fel a VPN-re, ugyanis a szerverem egy Ubiquiti EdgeRouter-X mögött van. Ha átléptem akár roaminggal akár nélküle külső netre, akkor megjavult, de ugye a roaming miatt jó lenne, ha itthon is menne belsőről a tunnel rendesen. Megy is. Ha gondok vannak a belső hálózattal, a kliens konfigjában ezt a sort:
AllowedIPs = 0.0.0.0/0, ::/0
erre kell átírni feltételezve, hogy a belső hálózat 192.168.1.0/24
AllowedIPs = 0.0.0.0/0, ::/0, 192.168.1.0/24
A telepítés egyszerű, viszont a szolgáltatás nem feltétlen sokoldalú. Érdemes szemelőtt tartani, hogy bár könnyű összelőni a WG-t, vagy ha nem is az, de könnyebb mint a konkurenseket, azonban ez ott üt vissza, hogy nincs LAN-bridge és társai, mindenképp NAT-ol, ami problémás lehet destination NAT esetében, vagy is amikor a netről egy adott portot akarunk a VPN egyik kliensére átirányítani. Illetve így RA sincs, tehát a routerünk hiába oszt IPv6 címeket, a RA csomagok nem jutnak el a kliensig.
Ha portot kell nyitni, szakszerűen mondva átirányítani, egy VPN kliensre, akkor érdemes elolvasni az NFT vonatkozó útmutatóját, illetve az alapok megértéséhez a quick reference-t, amiből többekközt kiderül, miért is jó az NFT (például közös IPv4 és IPv6 szabályok, nem kell ugyanazt a portot kétszer engedni).
A WG parancssori eszközének kiismeréséhez érdemes tanulmányozni a vonatkozó MAN szekciót.
A leírásban lévő interfésznevek, IP-címek vagy épp a 4000-es port variálható, sőt kell is, mert sokszor már nem eth0 az internet interfész neve. Érdemes azonban a privát címeknél maradni, mert különben nem várt anomáliák jöhetnek szembe. Erről egy szócikk
Végül pedig: Ez egy béta projekt, szóval problémák simán adódhatnak. Ha bárkinek gondja van, a Facebookoldalon írjon a cikkhez kapcsolódó poszt alá, és igyekszem segíteni.
Köszönöm a figyelmet, sok sikert mindenkinek!