A WireGuard beállítása Ubuntun
Bevezetés
WireGuard egy könnyű Virtual Private Network (VPN), amely támogatja mind az IPv4, mind az IPv6 kapcsolatokat. A VPN lehetővé teszi, hogy megbízhatatlan hálózatokon keresztül úgy közlekedj, mintha egy privát hálózaton lennél. Lehetővé teszi, hogy biztonságosabban férj hozzá az internethez olyan eszközökről, mint laptopok vagy mobiltelefonok, amikor megbízhatatlan hálózatokhoz, például nyilvános WiFi-hez csatlakozol.
A WireGuard titkosítása nyilvános és privát kulcsokra támaszkodik, hogy a csomópontok közt titkosított csatornákat hozzon létre. Minden WireGuard kiadás egy rögzített készlet modern kriptográfiai módszert használ, ami segít egyszerűvé és kiszámíthatóvá tenni a protokollt. Ez a kialakítás elkerüli a futásidejű tárgyalást és csökkenti a konfigurációs hibák kockázatát.
Összehasonlításképpen, más VPN szoftverek, mint az OpenVPN és az IPsec a Transport Layer Security-re és tanúsítványokra támaszkodnak az azonosításhoz és a titkosított alagutak létrehozásához. Bár ez a megközelítés rugalmasságot biztosít és széles körű kliens támogatást nyújt, növeli a konfiguráció összetettségét, és megnehezíti a működési viselkedés megértését.
Ebben az útmutatóban beállítja a WireGuardot egy Ubuntu szerveren, és konfigurál egy másik gépet, hogy csatlakozzon hozzá társként mind IPv4, mind IPv6 segítségével, amit általában dual-stack konfigurációnak neveznek. Megtanulja azt is, hogyan lehet a társi forgalmat a WireGuard szerveren keresztül irányítani egy átjáró beállításában, valamint hogyan lehet a VPN-t titkosított peer-to-peer kommunikációra használni.
A magbeállításokon kívül ez az útmutató gyakorlati témákat is lefed, amelyek a valódi környezetbe történő telepítések szempontjából fontosak. Ide tartozik a WireGuard peer-to-peer architektúrájának megértése, a kulcsok kezelése és forgatása, az IPv6 és a dupla stack útválasztás helyes kezelése, a NAT mögötti csomópontok megbízhatóságának javítása, a teljesítmény hangolása, valamint annak megértése, hogy a WireGuard hogyan viszonyul az OpenVPN-hez az átviteli protokollok és a tűzfal viselkedése szempontjából.
A jelen oktatóanyag céljaira egy másik Ubuntu rendszert használnak WireGuard Peer-ként. A sorozat későbbi oktatóanyagai a WireGuard telepítését és használatát tárgyalják Windows, macOS, Android és iOS rendszereken.
Telepítse frontend alkalmazásait a GitHubról a Linux-Console.net App Platform segítségével. Hagyja, hogy a Linux-Console.net az alkalmazás skálázására összpontosítson.
Megjegyzés: Ha a WireGuardot egy Linux-Console.net Dropleten szeretné beállítani, vegye figyelembe, hogy mi, mint sok más szolgáltató, díjat számítunk fel a sávszélesség-túllépésekért. Ezért kérjük, legyen figyelmes arra, hogy mennyi forgalmat kezel a szervere. További információért tekintse meg a Sávszélesség Számlázás oldalunkat.
Főbb tanulságok:
- A WireGuard egy könnyű VPN, amely modern kriptográfiát használ, egyszerű kialakítással, amely nyilvános és privát kulcspárokon alapul, ezáltal csökkentve a konfiguráció bonyolultságát és a hibákat.
- A WireGuard peer-to-peer architektúrát követ, ahol minden rendszer ugyanazt a szoftvert futtatja, és a szerver és peer kifejezések csak a hálózati topológiát írják le, nem különböző szerepeket vagy képességeket.
- A WireGuard minden titkosítási, hitelesítési és útválasztási működése kifejezetten a konfigurációs fájlokban van meghatározva, nincs vezérlési sík, tanúsítványhatóság vagy futásidejű egyeztetés.
- A
AllowedIPsbeállítás két célt szolgál: szabályozza, hogy melyik forgalom halad át a tunelon, és szigorú hozzáférés-ellenőrző listaként működik a társaktól érkező bejövő forgalom számára. - A WireGuard egyaránt támogatja az IPv4-et és az IPv6-ot, és a duál-stack konfigurációk esetén mindkét protokollra gondos útvonalkezelésre, tűzfal-szabályokra és továbbítási beállításokra van szükség.
- Amikor a WireGuardot VPN átjáróként használjuk, a szerveren be kell állítani az IP-továbbítást és a tűzfal álcázást, hogy a peer-forgalom elérhesse a külső hálózatokat.
- A
wg-quicksegédprogram automatikusan létrehozza az útvonalakat, a tűzfal szabályokat és a felületek beállítását, míg a WireGuard kernel modul csak a csomagok titkosítására és visszafejtésére összpontosít. - IPv6 szivárgások előfordulhatnak kettős veremű (dual-stack) beállításokban, ha az IPv6 útvonalakat, például
::/0-t, nem tartalmazzák kifejezetten, ami azt eredményezheti, hogy az IPv6 forgalom megkerüli a VPN-t, még akkor is, ha az IPv4 forgalom megfelelően tunnelingelve van. - A WireGuard nem módosítja automatikusan a rendszerútvonalakat, a DNS-beállításokat vagy a tűzfalszabályokat, ezért az útválasztás és a hálózati viselkedés kezeléséhez olyan eszközökre van szükség, mint a
wg-quickvagy a kézi konfiguráció. - A kettős veremű WireGuard telepítésekhez az IPv4 és IPv6 továbbítást, a tűzfal szabályokat és az ICMPv6 támogatást külön kell beállítani, mivel az operációs rendszer minden protokollt külön kezel.
Előfeltételek
A bemutató követéséhez szükséged lesz a következőkre:
Egy Ubuntu szerver egy sudo jogosultságú nem root felhasználóval és tűzfallal engedélyezve. Ennek beállításához követheted az Ubuntu kezdeti szerver beállításáról szóló útmutatónkat. A továbbiakban ezt hívjuk WireGuard szervernek ebben az útmutatóban.
Szükséged lesz egy kliens gépre, amelyet a WireGuard szerveredhez való csatlakozáshoz fogsz használni. Ebben a bemutatóban ezt a gépet WireGuard Peer-nek fogjuk nevezni. A bemutató szempontjából ajánlott a helyi gépedet használni WireGuard Peer-ként, de ha szeretnéd, távoli szervereket vagy mobiltelefonokat is használhatsz kliensként. Ha távoli rendszert használsz, mindenképpen kövesd a bemutató későbbi opcionális részeit, különben kizárhatod magad a rendszerből.
Ahhoz, hogy a WireGuardot IPv6-tal használja, biztosítania kell, hogy a szervere konfigurálva legyen az ilyen típusú forgalom támogatására. Ha a WireGuarddal szeretné engedélyezni az IPv6 támogatást, és Linux-Console.net Dropletet használ, kérjük, tekintse meg ezt a dokumentációs oldalt: Hogyan engedélyezzük az IPv6-ot a Dropleteken. IPv6 támogatást hozzáadhat a Droplet létrehozásakor, vagy később az oldal utasításai szerint.
A WireGuard architektúrájának áttekintése
Mielőtt beállítanánk a WireGuardot, hasznos megérteni, hogyan működnek együtt a rendszerek, a társak és a hálózati forgalom. A WireGuard szándékosan egyszerű architektúrát használ, amely elkerüli a vezérlési síkokat, a tanúsítványhatóságokat és a konfigurációs paraméterek futásidejű egyeztetését. Minden titkosítási, hitelesítési és útválasztási tevékenység kifejezetten a konfigurációs fájlokon keresztül van meghatározva.
Peer-to-Peer tervezés és topológiai terminológia
A WireGuard alapvetően egy peer-to-peer protokoll. Ugyanaz a WireGuard szoftver és kernel modul fut minden részt vevő rendszeren, és nincs külön szerver vagy kliens bináris fájl.
Ebben az útmutatóban a WireGuard szerver kifejezés egy központi csomópontot jelöl a hub-and-spoke (központi csomópont és ágak) topológiában. Ez a rendszer nyilvánosan elérhető, és a többi peer számára koordinációs pontként működik. A WireGuard peer kifejezés azokra az eszközökre utal, amelyek ehhez a csomóponthoz csatlakoznak. Ezek a kifejezések a jelen útmutatóban használt hálózati topológiát írják le, nem különböző szoftver szerepeket vagy képességeket.
Ennek a különbségtételnek a megértése fontos, mert a WireGuardnak nincsenek kizárólag szerverre vonatkozó beállítási lehetőségei. Bármely rendszer működhet csomópontként, ágként vagy mindkettőként, teljes mértékben attól függően, hogyan vannak meghatározva a kulcsok, címek és útválasztási szabályok.
A WireGuard telepítésének alapvető elemei
Egy WireGuard telepítés néhány jól meghatározott összetevőből áll, amelyek mindegyike egy meghatározott feladattal rendelkezik.
Központi Peer (Hub): A központi peer egy nyilvánosan elérhető rendszer, amely egyetlen porton figyeli a titkosított UDP-forgalmat. Egy virtuális tunnel interfészt, általában
wg0néven, hosztol, és tárolja azoknak a peer-eknek a nyilvános kulcsait, amelyekkel kommunikálhat. A hub nem fedezi fel dinamikusan a peer-eket, és nem fogadja el a kapcsolatokat automatikusan. A forgalmat csak azok a peer-ek küldhetik, amelyek nyilvános kulcsai és engedélyezett IP-tartományai kifejezetten be vannak állítva.Csatlakozó peer-ek (spoke-ok): A csatlakozó peer-ek olyan eszközök, amelyek titkosított alagutakat hoznak létre a központi peer felé. Ezek az eszközök lehetnek laptopok, szerverek, virtuális gépek vagy mobil rendszerek. Minden peer rendelkezik egy egyedi kriptográfiai kulcspárral és egy vagy több privát IP-címmel, amelyet az alagút interfészéhez rendelnek. Egy peer csak akkor küld forgalmat az alagútba, ha a routing szabályai erre utasítják.
Alagút interfész (
wg0): Az alagút interfész egy virtuális hálózati eszköz, amely minden résztvevő rendszeren létrejön. Minden titkosított forgalom ezen az interfészen keresztül érkezik és távozik. Az operációs rendszer szempontjából awg0úgy viselkedik, mint egy szabványos hálózati interfész, ami lehetővé teszi a normál útválasztási táblák, tűzfal szabályok és átviteli viselkedés alkalmazását.
Titkosítás, hitelesítés és kézfogások
A WireGuard nyilvános kulcsú kriptográfiát használ a partnerek hitelesítésére és a forgalom titkosítására. Minden partner létrehoz egy hosszú távú privát kulcsot, amely a helyi rendszeren marad, és soha nem kerül továbbításra. A megfelelő nyilvános kulcsot megosztják a többi partnerrel, és hozzáadják azok konfigurációihoz.
Amikor a kommunikáció megkezdődik, a WireGuard egy csendes, automatikus kriptográfiai kézfogást hajt végre a Noise protokoll keretrendszer alapján. Ez a kézfogás létrehozza az átmeneti munkamenet-kulcsokat, és biztosítja a Tökéletes Előremenő Titkosságot. Ezeket a munkamenet-kulcsokat rendszeresen, felhasználói beavatkozás nélkül cserélik.
A WireGuard nem tárgyal titkosítási csomagokról, hitelesítési módszerekről vagy protokollverziókról. Minden kriptográfiai primitívát a tervezés hoz rögzítve. Ez egy teljes konfigurációs hibakategóriát kiküszöböl, miközben modern biztonsági garanciákat nyújt.
Támogatott forgalmi minták
A WireGuard többféle forgalmi mintát támogat attól függően, hogyan van konfigurálva az útválasztás és a továbbítás. Ez a bemutató a két leggyakoribb felhasználási esetre összpontosít.
Peer-to-peer vagy belső hálózati hozzáférés
Egy peer-to-peer vagy belső hozzáférési konfigurációban a forgalom csak a VPN részét képező rendszerek között van titkosítva. A központi peer biztonságos végpontként vagy továbbítóként működik, de nem továbbítja a forgalmat külső hálózatok felé.
Ezt a konfigurációt általában privát szolgáltatások elérésére, az infrastruktúra kezelésére vagy elszigetelt rendszerekhez való csatlakozásra használják. A forgalom csak akkor kerül a tunnelen keresztülirányításra, ha a célcím megfelel a társkonfigurációban meghatározott privát IP-tartományoknak.
VPN átjáró mód
Átjáró üzemmódban a központi csomópont továbbítja a forgalmat a többi csomóponttól a külső hálózatok felé, beleértve a nyilvános internetet is. A csomópontok a forgalmuk egy részét vagy egészét a tunnelbe küldik, és a központi csomópont IP-továbbítással és hálózati címfordítással továbbítja ezt a forgalmat.
Ez a konfiguráció további rendszerbeállításokat igényel, beleértve a kernel továbbítást és a tűzfal szabályokat. Amikor a gateway mód engedélyezve van, a peer-ekből induló kimenő forgalom úgy tűnik, mintha a központi peer nyilvános IP-címéről származna.
AllowedIPs kettős szerepe
A AllowedIPs direktíva két különböző célt szolgál a WireGuardban.
Először is meghatározza a kimenő útválasztás viselkedését. Amikor egy csomag célcíme megegyezik egy AllowedIPs bejegyzéssel, az a csomag a WireGuard alagúton keresztül kerül továbbításra.
Másodszor, a AllowedIPs szigorú bejövő hozzáférés-ellenőrzési listaként működik. Amikor egy csomag érkezik egy peer-től, a WireGuard ellenőrzi a csomag forrás IP-címét. Ha a forrás cím nincs felsorolva az adott peer AllowedIPs listáján, a csomagot azonnal eldobja.
Ez a kettős szerep szándékos, és az egyik leggyakoribb oka a konfigurációs hibáknak. Önmagában a helyes útválasztás nem elegendő. A peer által használható forrás IP-címeket is kifejezetten engedélyezni kell.
Útvonal-automatizálás és segédprogramok
A WireGuard kernel modul maga nem módosítja a rendszer útvonalait, a DNS-beállításokat vagy a tűzfal szabályait. Csak titkosítja és visszafejti a csomagokat, és társítja ezeket a peer-ekhez.
Az útválasztás automatizálását segédprogramok, például a wg-quick végzik. Ez az eszköz beolvassa a WireGuard konfigurációs fájlt, és a szükséges útválasztási táblázati bejegyzéseket, DNS-beállításokat és tűzfal szabályokat alkalmazza, amikor egy alagutat fel- vagy lekapcsolnak.
Ha a WireGuardot alternatív eszközökkel, például nyers wg parancsokkal, systemd-networkd-vel vagy egyedi szkriptekkel konfigurálják, ezeket az útváltoztatásokat manuálisan kell kezelni.
Ez a szétválasztás egyszerűen tartja a magprotokollt, miközben rugalmas integrációt tesz lehetővé különböző rendszerhálózati kiterjesztésekkel.
1. lépés — A WireGuard telepítése és kulcspár generálása
A tutorial első lépése a WireGuard telepítése a szerverre. Kezdésként frissítse a WireGuard szerverének csomagindexét, majd a következő parancsok segítségével telepítse a WireGuardot. Előfordulhat, hogy meg kell adnia a sudo felhasználó jelszavát, ha ez az első alkalom, hogy a sudo parancsot használja ebben a munkamenetben:
sudo apt update
sudo apt install wireguardMost, hogy telepítetted a WireGuardot, a következő lépés a szerverhez privát és nyilvános kulcspár generálása. A beépített wg genkey és wg pubkey parancsokat használhatod a kulcsok létrehozásához, majd a privát kulcsot hozzá kell adnod a WireGuard konfigurációs fájljához.
A most létrehozott kulcs jogosultságait is módosítanod kell a chmod parancs segítségével, mivel alapértelmezés szerint a fájl minden felhasználó számára olvasható a szervereden.
Hozza létre a WireGuard privát kulcsát, és módosítsa a jogosultságait az alábbi parancsokkal:
wg genkey | sudo tee /etc/wireguard/private.key
sudo chmod go= /etc/wireguard/private.keyA sudo chmod go=... parancs eltávolít minden jogosultságot a fájlról a root felhasználón kívüli felhasználók és csoportok számára, hogy csak a root férhessen hozzá a privát kulcshoz.
Egyetlen sor base64 kódolt kimenetet kell kapnod, amely a privát kulcsot tartalmazza. A kimenet egy példánya a későbbi hivatkozás érdekében a /etc/wireguard/private.key fájlban is tárolódik a parancs tee része által. Figyelmesen jegyezd fel a kimenetként kapott privát kulcsot, mivel később hozzá kell adnod a WireGuard konfigurációs fájljához ezen a szakaszon.
A következő lépés a megfelelő nyilvános kulcs létrehozása, amely a privát kulcsból származik. Használja a következő parancsot a nyilvános kulcs fájl létrehozásához:
sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.keyEz a parancs három egyéni parancsból áll, amelyeket az | (pipe) operátorral láncoltak össze:
sudo cat /etc/wireguard/private.key: ez a parancs elolvassa a privát kulcs fájlt, és kiírja azt a szabványos kimeneti áramra.wg pubkey: a második parancs az első parancs kimenetét használja bemenetként, és feldolgozza azt egy nyilvános kulcs létrehozásához.sudo tee /etc/wireguard/public.key: a végső parancs a nyilvános kulcs generálásának kimenetét a/etc/wireguard/public.keynevű fájlba irányítja.
Amikor futtatod a parancsot, ismét egyetlen sor base64 kódolt kimenetet kapsz, ami a WireGuard szervered nyilvános kulcsa. Másold el valahova, mert szükséged lesz rá, hogy a nyilvános kulcsot bármely klienssel megoszd, amely csatlakozik a szerverhez.
2. lépés — IPv4- és IPv6-címek kiválasztása
Az előző részben telepítette a WireGuardot, és létrehozott egy kulcspárt, amelyet a szerver felé és szervertől érkező forgalom titkosítására fog használni. Ebben a részben létrehoz egy konfigurációs fájlt a szerverhez, és beállítja, hogy a WireGuard automatikusan elinduljon, amikor a szerver újraindul. Emellett meghatározza azokat a privát IPv4 és IPv6 címeket, amelyeket a WireGuard szerverével és peerjeivel használni fog.
Ha mind az IPv4, mind az IPv6 címeket használni szeretné, akkor kövesse mindkét szakaszt. Ellenkező esetben kövesse az Ön VPN-hálózatának igényeihez megfelelő szakasz utasításait.
2. lépés (a) — IPv4-tartomány kiválasztása
Ha IPv4-es társaiddal használod a WireGuard szerveredet, a szervernek szüksége van egy privát IPv4-címtartományra, amit a kliensjeihez és a tunel interfészéhez használhat. Bármelyik IP-címtartományt kiválaszthatod a következő foglalt címtartományok közül (ha többet szeretnél megtudni arról, hogy ezek a blokkok hogyan vannak kiosztva, látogasd meg az RFC 1918 specifikációt):
10.0.0.0-10.255.255.255(10/8 előtag)172.16.0.0-172.31.255.255(172.16/12 előtag)192.168.0.0–192.168.255.255(192.168/16 előtag)
A oktatóanyag céljaira a 10.8.0.0/24 címblokkot fogjuk használni, amely az első fenntartott IP-címtartományból származik. Ez a tartomány akár 255 különböző peer kapcsolatot is lehetővé tesz, és általában nem szabad, hogy átfedésben legyen vagy ütközzön más privát IP-tartományok címeivel. Nyugodtan választhat olyan címtartományt, amely kompatibilis a hálózati konfigurációjával, ha ez a példatartomány nem megfelelő az ön hálózataihoz.
A WireGuard szerver a tartományból egyetlen IP-címet használ a privát tunnel IPv4-címéhez. Itt a 10.8.0.1/24 címet használjuk, de a 10.8.0.1 és 10.8.0.255 közötti tartomány bármely címe használható. Jegyezd fel az általad választott IP-címet, ha más címet használsz a 10.8.0.1/24-tól eltérően. Ezt az IPv4-címet hozzá kell adnod a konfigurációs fájlhoz, amelyet a WireGuard szerver konfiguráció létrehozása részben definiálsz.
2(b) lépés — IPv6-tartomány kiválasztása
Ha WireGuardot használsz IPv6-tal, akkor egy egyedi helyi IPv6 unicast cím előtagot kell létrehoznod az RFC 4193-ban található algoritmus alapján. Azok a címek, amelyeket a WireGuarddal használsz, egy virtuális alagút interfészhez lesznek társítva. Néhány lépést kell végrehajtanod ahhoz, hogy egy véletlenszerű, egyedi IPv6 előtagot generálj a privát IPv6 címekre fenntartott fd00::/8 blokkban.
Az RFC szerint az ajánlott módszer egy egyedi IPv6 prefix megszerzésére az, ha a napszakot egy rendszerből származó egyedi azonosító értékkel, például sorozatszámmal vagy eszközazonosítóval kombinálják. Ezeket az értékeket ezután hash-elik és levágják, így egy olyan bitkészlet jön létre, amely egyedi címként használható az IP-k fenntartott privát fd00::/8 blokkján belül.
Az IPv6-tartomány generálásának megkezdéséhez a WireGuard szerveredhez gyűjts össze egy 64 bites időbélyeget a date segédprogram segítségével a következő parancs használatával:
date +%s%NEgy olyan számot fogsz kapni, mint az alábbi, amely a 1970-01-01 00:00:00 UTC óta eltelt másodpercekből (a %s a date parancsban) és nanomásodpercekből (a %N) áll, összekapcsolva:
1628101352127592197Jegyezze fel az értéket valahova, hogy később ebben a szakaszban használhassa. Ezután másolja ki a szerveréhez tartozó machine-id értéket a /var/lib/dbus/machine-id fájlból. Ez az azonosító egyedi a rendszeréhez, és nem változik, amíg a szerver létezik.
cat /var/lib/dbus/machine-idA következőhöz hasonló kimenetet fogsz kapni:
/var/lib/dbus/machine-id20086c25853947c7aeee2ca1ea849d7dMost össze kell kombinálnod az időbélyeget a machine-id-vel, majd a keletkező értéket a SHA-1 algoritmussal kell hashelni. A parancs a következő formátumot fogja használni:
printf <timestamp><machine-id> | sha1sumFuttassa a parancsot úgy, hogy a saját időbélyegét és gépazonosító értékeit helyettesíti be:
printf 162810135212759219720086c25853947c7aeee2ca1ea849d7d | sha1sumA következőhöz hasonló hash értéket fogsz kapni:
4f267c51857d6dc93a0bca107bca2f0d86fac3bc -Ne feledje, hogy a sha1sum parancs kimenete hexadecimális formátumú, így a kimenet két karaktert használ egyetlen adatbájt ábrázolására. Például a példaként szereplő 4f és 26 a hash-elt adatok első két bájtja.
Az RFC-ben szereplő algoritmus csak a legkevésbé jelentős (utolsó) 40 bitet, vagyis 5 bájtot igényel a hashelt kimenetből. Használd a cut parancsot, hogy kiírd a hash utolsó 5, hexadecimálisan kódolt bájtját:
printf 4f267c51857d6dc93a0bca107bca2f0d86fac3bc | cut -c 31-A -c argument azt mondja a cut parancsnak, hogy csak egy meghatározott karakterkészletet válasszon ki. A 31- argumentum azt mondja a cut-nak, hogy az összes karaktert a 31. pozíciótól a sor végéig nyomtassa ki.
A következőhöz hasonló kimenetet kellene kapnod:
0d86fac3bcEbben a kimeneti példában a bájtok halmaza a következő: 0d 86 fa c3 bc.
Most már felépítheted egyedi IPv6 hálózati előtagodat úgy, hogy a létrehozott 5 bájtot a fd előtaghoz fűzöd, minden 2 bájt után : kettősponttal elválasztva az olvashatóság érdekében. Mivel az egyedi előtag minden alhálózata összesen 18 446 744 073 709 551 616 lehetséges IPv6 címet képes tartalmazni, az alhálózatot egyszerűség kedvéért standard /64 méretre korlátozhatod.
A /64 alhálózati mérettel korábban generált bájtok felhasználásával az eredő prefix a következő lesz:
Unique Local IPv6 Address Prefixfd0d:86fa:c3bc::/64Ezt a fd0d:86fa:c3bc::/64 tartományt fogja használni az egyes IP-címek kiosztására a WireGuard alagút interfészekhez a szerveren és a klienseknél. Ahhoz, hogy egy IP-címet rendelje a szerverhez, adja hozzá a 1-et az utolsó :: karakterek után. Az így kapott cím fd0d:86fa:c3bc::1/64 lesz. A kliensek bármilyen IP-címet használhatnak a tartományban, de jellemzően minden új kliens hozzáadásakor eggyel növelik az értéket, például fd0d:86fa:c3bc::2/64. Jegyezze fel az IP-címet, és folytassa a WireGuard szerver konfigurálását a következő részben.
IPv6 és kettős verem konfigurációs szempontok
A jelenlegi útmutató lépései azt magyarázzák el, hogyan lehet IPv6-címeket generálni és kiosztani azokat a WireGuard interfészekhez. Azonban az IPv6 viselkedése a WireGuardban több fontos ponton eltér az IPv4-től, különösen akkor, ha a WireGuard VPN átjáróként van használva. E különbségek megértése segít megelőzni az útválasztási hibákat, a részleges alagútzást és a gyakori IPv6-szivárgásokat.
IPv6 támogatás a WireGuardban
A WireGuard teljes értékű protokollként támogatja az IPv6-ot. Az IPv6-forgalom titkosított, hitelesített, és ugyanazokkal a mechanizmusokkal kerül irányításra, mint az IPv4-forgalom. Nincs külön IPv6 mód vagy további konfigurációs beállítás. Ha az alagút interfészhez IPv6-címek vannak rendelve, és az útválasztási szabályok ezt lehetővé teszik, az IPv6-forgalom automatikusan az alagúton keresztül halad.
Az IPv4-től eltérően az IPv6 úgy lett tervezve, hogy elkerülje a NAT használatát globálisan routolható címek alkalmazásával, de a gyakorlatban sok VPN és felhőalapú környezet továbbra is NAT-ot használ az egyszerűbb működés érdekében. Ez a viselkedés azonban a hálózati környezettől függ. Sok VPN-átjáró beállításnál, például felhő VPS példányoknál vagy otthoni routereknél, a szerver nem kap rendelt IPv6 prefixet, amely a VPN-társak felé routolható lenne.
Ezekben a gyakori esetekben a partnereknek privát IPv6-címeket rendelnek, általában egy Egyedi Helyi Cím (ULA) tartományból. Ha privát IPv6-címeket használnak, és a szervernek nincs számukra útvonalható prefixe, akkor az IPv6 maszkolás továbbra is szükséges. Ezt általában az ip6tables -t nat szabályokkal valósítják meg, hasonlóan az IPv4 maszkoláshoz, hogy a VPN partnerek elérhessék a nyilvános Internetet.
Az IPv6 teljesen elkerülheti a NAT-ot, ha megfelelő prefix delegálás áll rendelkezésre. Azonban a legtöbb egyszerű VPN-átjáró telepítés továbbra is az IPv6-alapú álcázásra támaszkodik a kezelhető útvonal-kezelés érdekében.
A dual-stack működés magyarázata
A dupla veremű konfiguráció lehetővé teszi, hogy az IPv4 és az IPv6 egyaránt működjön ugyanazon a WireGuard interfészen. Ebben a beállításban a wg0 interfészhez egy IPv4 és egy IPv6 cím van rendelve, és mindkét protokoll függetlenül van útvonalra állítva.
A rendszerszoftver külön értékeli az IPv4- és az IPv6-útvonalakat. Egy társ sikeresen irányíthat IPv4-forgalmat a tunelen keresztül, míg az IPv6-forgalom megkerüli azt, vagy fordítva. Ez a viselkedés várható, és szinte mindig konfigurációs problémára utal, nem magára a WireGuardra.
Ahhoz, hogy a dual-stack útválasztás megfelelően működjön, több feltételnek is teljesülnie kell. Mind a szervernek, mind a peernek rendelkeznie kell IPv4 és IPv6 címmel a WireGuard interfészein. Az AllowedIPs direktívának tartalmaznia kell mind az IPv4, mind az IPv6 tartományokat. Az IP továbbítás külön kell, hogy engedélyezve legyen IPv4-re és IPv6-ra egyaránt. A tűzfal szabályainak engedélyezniük kell a továbbítást és a visszatérő forgalmat mindkét protokollhoz.
Cím hozzárendelés és előtaghossz
Az IPv4 esetében a WireGuard telepítések általában privát címtartományokat használnak, mint például a 10.0.0.0/8 vagy a 192.168.0.0/16. Minden peerhez általában egyetlen IPv4-címet rendelnek.
IPv6 esetében gyakori, hogy a VPN-hálózatot /64 előtaggal határozzák meg, például fd00::/64. Míg az Ethernet-hálózatok esetében a /64 szükséges a szomszédfelismeréshez és a címautokonfigurációhoz, a WireGuard rétegbeli 3-as pont-pont interfészként működik, és nem használja ezeket a mechanizmusokat.
Emiatt biztonságos, és gyakran javasolt, hogy minden peer-hez rendeljenek egy /128 IPv6 címet, például fd00::2/128. A /128 címek használata biztosítja a szigorú útválasztási viselkedést, és megakadályozza, hogy a peerek próbáljanak közvetlenül kommunikálni az alhálózat más címeivel megfelelő útválasztási szabályok nélkül.
A hálózatot /64-ként definiálni, miközben a csomópontoknak /128-as címeket osztunk ki, egyértelműséget biztosít és elkerüli a kétértelmű útválasztást.
Az összes forgalom irányítása IPv6-tal
Amikor a WireGuard VPN átjáróként van konfigurálva, az IPv6 forgalmat ugyanúgy kell kifejezetten irányítani, mint az IPv4 forgalmat.
IPv4 esetén az összes forgalom irányításához a 0.0.0.0/0 előtagot használjuk. IPv6 esetén a megfelelő előtag a ::/0. Mindkét előtagot fel kell venni, ha az a cél, hogy az összes forgalmat a VPN-en keresztül irányítsuk.
Ha csak a 0.0.0.0/0 van beállítva, az IPv4-forgalom a VPN-en keresztül halad, miközben az IPv6-forgalom továbbra is a helyi hálózati interfészt használja. Ezt a helyzetet IPv6-szivárgásnak nevezik. Ez gyakran azt eredményezi, hogy a DNS-lekérdezések, a webforgalom vagy az alkalmazáskölcsönhatások az IPv6 miatt kikerülik a VPN-t, miközben az IPv4-forgalom védett marad.
Az IPv6-szivárgások gyakori félreértések forrásai, és mindig tesztelni kell őket, amikor a dual-stack hálózat engedélyezve van.
Tűzfal, Továbbítás és ICMPv6
Az IPv6 továbbítását függetlenül kell engedélyezni az IPv4 továbbításától. Az egyik engedélyezése nem aktiválja automatikusan a másikat. Mindkét beállítás szükséges, ha forgalmat irányítunk az interfészek között.
A tűzfalszabályokat az IPv6-ra is egyértelműen meg kell határozni. Az olyan eszközök, mint a ufw, a iptables és a nftables az IPv4-et és az IPv6-ot külön szabályrendszerként kezelik. Hiányzó IPv6-szabályok akkor is csendben blokkolhatják a forgalmat, ha az IPv4-kapcsolat látszólag működik.
Különösen fontos engedélyezni az ICMPv6 forgalmat. Az IPv4-től eltérően az IPv6 az ICMPv6-ra támaszkodik alapvető funkciók, például az útvonal MTU-felderítés (Path MTU Discovery) esetén. Ha az ICMPv6 blokkolva van, a kapcsolatok fennakadhatnak vagy meghiúsulhatnak, amikor nagyobb csomagokat továbbítanak, bár a kisebb csomagok látszólag működhetnek.
Gyakori kettős verem buktatók
Több gyakori probléma merül fel a dual-stack WireGuard telepítéseknél. Előfordulhat, hogy az AllowedIPs utasításból hiányoznak az IPv6 útvonalak, ami miatt az IPv6 forgalom kikerüli az alagutat. Lehet, hogy az IPv6 továbbítás nincs engedélyezve a szerveren, ami megakadályozza, hogy a forgalom elhagyja az alagút interfészt. A tűzfal szabályok engedhetik az IPv4 forgalmat, de blokkolhatják az IPv6 vagy ICMPv6 forgalmat. A DNS feloldók IPv6 címeket adhatnak vissza, még akkor is, ha az IPv6 útválasztás nincs megfelelően konfigurálva.
Ezek a problémák gyakran időszakos hibaként jelentkeznek, és gyakran alkalmazás- vagy protokollproblémaként tévesen diagnosztizálják őket.
Az IPv4-only, IPv6-only és Dual-Stack közötti választás
Néhány környezetben egyetlen protokoll használata egyszerűsíti a műveleteket.
Az IPv4-only telepítések könnyebben integrálhatók a régi rendszerekkel és eszközökkel. Az IPv6-only telepítések megszüntetik az IPv4 NAT szükségességét és elkerülik a címkimerülést, de követelik a szolgáltatóktól és az ügyfélhálózatoktól az állandó IPv6 támogatást.
A kettős veremű telepítések biztosítják a legnagyobb rugalmasságot, de a legtöbb gondos tervezést, konfigurálást és ellenőrzést is igénylik.
3. lépés — WireGuard szerver konfiguráció létrehozása
Mielőtt létrehoznád a WireGuard szerver konfigurációját, szükséged lesz a következő információkra:
- Győződj meg róla, hogy rendelkezel a privát kulccsal a WireGuard telepítése és kulcspár generálása részből.
- Ha WireGuardot használ IPv4-gyel, szüksége lesz arra az IP-címre, amelyet a IPv4-tartomány választása során a szervernek választott, ami ebben a példában
10.8.0.1/24. - Ha IPv6-tal használod a WireGuardot, szükséged lesz a szerver IP-címére, amelyet a IPv6 tartomány kiválasztása részben generáltál. Ebben a példában az IP-cím
fd0d:86fa:c3bc::1/64.
Miután megvan a szükséges privát kulcs és IP-cím(ek), hozz létre egy új konfigurációs fájlt a nano vagy a kedvenc szerkesztőd használatával az alábbi parancs futtatásával:
sudo nano /etc/wireguard/wg0.confAdd hozzá a következő sorokat a fájlhoz, a kiemelt base64_encoded_private_key_goes_here érték helyére a saját privát kulcsodat, és a Address sorra az IP-címet vagy IP-címeket. A ListenPort sort is módosíthatod, ha szeretnéd, hogy a WireGuard egy másik porton legyen elérhető:
/etc/wireguard/wg0.conf[Interface]
PrivateKey = base64_encoded_private_key_goes_here
Address = 10.8.0.1/24, fd0d:86fa:c3bc::1/64
ListenPort = 51820
SaveConfig = trueA SaveConfig sor biztosítja, hogy amikor egy WireGuard interfészt leállítanak, az esetleges változtatások elmentődjenek a konfigurációs fájlba.
Mentse el és zárja be a /etc/wireguard/wg0.conf fájlt. Ha a nano szerkesztőt használja, ezt a CTRL+X, majd Y és ENTER gombokkal erősítheti meg. Most van egy kezdeti szerverkonfigurációja, amelyre építkezhet, attól függően, hogyan tervezi használni a WireGuard VPN szerverét.
4. lépés — A WireGuard szerver hálózati beállításainak módosítása
Ha a WireGuardot arra használja, hogy egy peer-t csatlakoztasson a WireGuard szerverhez annak érdekében, hogy csak a szerveren lévő szolgáltatásokhoz férjen hozzá, akkor ezt a részt nem kell kitöltenie. Ha azonban szeretné, hogy a WireGuard peer Internethasználata a WireGuard szerveren keresztül menjen, akkor az IP-továbbítást kell konfigurálnia a tutorial ezen részének követésével.
A továbbítás beállításához nyissa meg a /etc/sysctl.conf fájlt a nano vagy a preferált szövegszerkesztője segítségével:
sudo nano /etc/sysctl.confHa IPv4-et használsz WireGuardgal, add hozzá a következő sort a fájl aljához:
net.ipv4.ip_forward=1Ha IPv6-ot használsz a WireGuarddal, add hozzá ezt a sort a fájl aljára:
net.ipv6.conf.all.forwarding=1Ha mind az IPv4-et, mind az IPv6-ot használja, győződjön meg arról, hogy mindkét sort belefoglalja. Amikor végzett, mentse és zárja be a fájlt.
A fájl olvasásához és az új értékek betöltéséhez az aktuális terminál munkamenetedhez, futtasd:
sudo sysctl -pnet.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1Mostantól a WireGuard szervered képes lesz a bejövő forgalmat a virtuális VPN ethernet eszközről a szerveren lévő többi eszközre továbbítani, onnan pedig a nyilvános internet felé. Ezen a konfiguráción keresztül az összes webforgalmat a WireGuard Peer-od a szervered IP-címén keresztül tudja irányítani, így a kliensed nyilvános IP-címe gyakorlatilag el lesz rejtve.
Azonban, mielőtt a forgalmat helyesen át tudnánk irányítani a szervereden keresztül, néhány tűzfal-szabályt kell beállítanod. Ezek a szabályok biztosítják, hogy a forgalom a WireGuard szervered és a Peerek között megfelelően áramoljon.
5. lépés — A WireGuard szerver tűzfalának konfigurálása
Ebben a részben a WireGuard szerver konfigurációját fogja szerkeszteni, hogy tűzfalszabályokat adjon hozzá, amelyek biztosítják a szerver és a kliensek közötti forgalom helyes útvonalát. Ahogy az előző részben is, ezt a lépést hagyja ki, ha a WireGuard VPN-jét csak gép-gép kapcsolatként használja a VPN-hez korlátozott erőforrások eléréséhez.
Ahhoz, hogy a WireGuard VPN forgalom átmehessen a szerver tűzfalán, engedélyeznie kell a maszkolást, ami egy iptables koncepció, és lehetővé teszi a dinamikus hálózati címfordítást (NAT) a klienskapcsolatok helyes irányításához.
Először találja meg a WireGuard szerver nyilvános hálózati interfészét a ip route alparancs segítségével:
ip route list defaultA nyilvános interfész az a karakterlánc, amelyet a parancs kimenetében találunk, és amely a „dev” szó után következik. Például ez az eredmény az eth0 nevű interfészt mutatja, amelyet az alábbiakban kiemeltünk:
default via 203.0.113.1 dev eth0 proto staticJegyezze fel az eszköz nevét, mivel a következő lépésben hozzá kell adnia az iptables szabályokhoz.
A WireGuard szerveréhez való tűzfal-szabályok hozzáadásához nyissa meg újra a /etc/wireguard/wg0.conf fájlt a nano segítségével vagy a kedvenc szerkesztőjével.
sudo nano /etc/wireguard/wg0.confA fájl alján, a SaveConfig=true sor után illessze be a következő sorokat:
/etc/wireguard/wg0.conf. . .
PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on eth0
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADEA PostUp sorok akkor futnak, amikor a WireGuard szerver elindítja a virtuális VPN alagutat. A példában itt három ufw és iptables szabályt fog hozzáadni:
ufw route allow in on wg0 out on eth0: Ez a szabály lehetővé teszi az IPv4 és IPv6 forgalom továbbítását, amely awg0VPN interfészen érkezik a szervereth0hálózati interfészére. Ez anet.ipv4.ip_forwardés anet.ipv6.conf.all.forwardingsysctl értékekkel együtt működik, amelyeket az előző szakaszban állítottál be.iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE: Ez a szabály a maszkírozást konfigurálja, és átírja awg0VPN interfészen érkező IPv4 forgalmat, hogy úgy tűnjön, mintha közvetlenül a WireGuard szerver nyilvános IPv4 címéről származna.ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE: Ez a szabály beállítja a maszkolást, és átírja az IPv6 forgalmat, amely awg0VPN interfészen érkezik, hogy úgy tűnjön, mintha közvetlenül a WireGuard szerver nyilvános IPv6-címéről származna.
Megjegyzés: Az IPv6 álcázáshoz (masquerading) szükség van a ip6table_nat kernel támogatására. Néhány disztribúcióban vagy felhőképen ez a modul nem elérhető, vagy alapértelmezés szerint nincs engedélyezve. Ilyen esetekben a NAT helyett megfelelő IPv6 útválasztást kell használni delegált prefixekkel, és a peer-ek számára egy útvonalható IPv6-prefixet kell hirdetni, nem pedig ULA-címeket.
A PreDown szabályok akkor futnak, amikor a WireGuard szerver leállítja a virtuális VPN-alagutát. Ezek a szabályok a PostUp szabályok ellentétei, és arra szolgálnak, hogy visszavonják a VPN interfészhez beállított továbbítási és maszkolási szabályokat, amikor a VPN leáll.
Mindkét esetben szerkessze a konfigurációt úgy, hogy tartalmazza vagy kizárja az IPv4- és IPv6-szabályokat, amelyek a VPN-jéhez megfelelőek. Például, ha csak IPv4-et használ, akkor kizárhatja a ip6tables parancsokat tartalmazó sorokat.
Fordítva, ha csak IPv6-ot használsz, akkor szerkeszd a konfigurációt úgy, hogy csak az ip6tables parancsokat tartalmazza. A ufw soroknak bármilyen IPv4 és IPv6 hálózat kombináció esetén létezniük kell. Mentse el és zárja be a fájlt, amikor végzett.
A tűzfal konfigurálásának utolsó része a WireGuard szerveren az, hogy engedélyezzük a forgalmat a WireGuard UDP portjára és onnan. Ha nem változtatta meg a portot a szerver /etc/wireguard/wg0.conf fájljában, a megnyitandó port a 51820. Ha másik portot választott a konfiguráció szerkesztésekor, győződjön meg róla, hogy azt helyettesíti a következő UFW parancsban.
Ha véletlenül elfelejtetted megnyitni az SSH portot a szükséges előkészítő útmutató követése közben, itt is add hozzá:
sudo ufw allow 51820/udp
sudo ufw allow OpenSSHMegjegyzés: Ha más tűzfalat használ vagy testreszabta az UFW konfigurációját, előfordulhat, hogy további tűzfal szabályokat kell hozzáadnia. Például, ha úgy dönt, hogy az összes hálózati forgalmát a VPN-kapcsolaton keresztül irányítja, biztosítania kell, hogy a 53 port forgalma engedélyezett legyen DNS-kérésekhez, valamint az olyan portok, mint a 80 és a 443 az HTTP és HTTPS forgalomhoz. Ha más protokollokat is használ a VPN-en keresztül, akkor azokhoz is hozzá kell adnia a szabályokat.
Miután hozzáadtad ezeket a szabályokat, kapcsold ki és vissza a UFW-t, hogy újrainduljon és betöltse a módosított fájlokból származó változtatásokat:
sudo ufw disable
sudo ufw enableA szabályok érvényben vannak, ha futtatja a ufw status parancsot. Futtassa, és az alábbihoz hasonló kimenetet kell kapnia:
sudo ufw statusStatus: active
To Action From
-- ------ ----
51820/udp ALLOW Anywhere
22/tcp ALLOW Anywhere
51820/udp (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)A WireGuard szerver most már úgy van beállítva, hogy megfelelően kezelje a VPN forgalmát, beleértve a peer-ek továbbítását és álcázását. A tűzfalszabályok érvényben tartásával elindíthatja a WireGuard szolgáltatást, hogy figyelje a peer kapcsolódásokat.
6. lépés — A WireGuard szerver indítása
A WireGuard konfigurálható úgy, hogy systemd szolgáltatásként fusson a beépített wg-quick szkript segítségével. Bár manuálisan is használhatnád a wg parancsot a tunel létrehozásához minden alkalommal, amikor a VPN-t használni szeretnéd, ez egy kézi folyamat, amely ismétlődővé és hibára hajlamossá válik. Ehelyett a systemctl segítségével is kezelheted a tunelt a wg-quick szkript segítségével.
A systemd szolgáltatás használata azt jelenti, hogy beállíthatod a WireGuardot, hogy a rendszerindításkor automatikusan elinduljon, így bármikor csatlakozhatsz a VPN-hez, amíg a szerver fut. Ehhez engedélyezd a wg-quick szolgáltatást az általad definiált wg0 alagút számára, hozzáadásával a systemctl-hez:
sudo systemctl enable wg-quick@wg0.serviceVegyük észre, hogy a parancs a tunnel wg0 eszköz nevét a szolgáltatás nevének részeként adja meg. Ez a név a /etc/wireguard/wg0.conf konfigurációs fájlra utal. Ez az elnevezési módszer lehetővé teszi, hogy tetszőleges számú külön VPN-tunnel-t hozz létre a szervereden.
Például lehet egy tunnel eszközöd prod névvel, és a konfigurációs fájlja /etc/wireguard/prod.conf lenne. Minden tunnel konfiguráció tartalmazhat különböző IPv4, IPv6 és kliens tűzfal beállításokat. Így több különböző peer kapcsolatot támogathatsz, mindegyik saját egyedi IP-címekkel és útvonal szabályokkal.
Most indítsa el a szolgáltatást:
sudo systemctl start wg-quick@wg0.serviceEllenőrizze duplán, hogy a WireGuard szolgáltatás aktív-e a következő parancs segítségével. A szolgáltatásnak aktívként kell megjelennie. Vegye figyelembe, hogy a wg-quick kilép az interfész konfigurálása után, így a active (exited) normális.
sudo systemctl status wg-quick@wg0.service● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
Active: active (exited) since Wed 2021-08-25 15:24:14 UTC; 5s ago
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 3245 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
Main PID: 3245 (code=exited, status=0/SUCCESS)
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] wg setconf wg0 /dev/fd/63
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip -4 address add 10.8.0.1/24 dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip -6 address add fd0d:86fa:c3bc::1/64 dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip link set mtu 1420 up dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ufw route allow in on wg0 out on eth0
Aug 25 15:24:14 wg0 wg-quick[3279]: Rule added
Aug 25 15:24:14 wg0 wg-quick[3279]: Rule added (v6)
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Aug 25 15:24:14 wg0 systemd[1]: Finished WireGuard via wg-quick(8) for wg0.A kimenet azokat a ip parancsokat mutatja, amelyeket a virtuális wg0 eszköz létrehozására és az IPv4 és IPv6 címek hozzárendelésére használnak, amelyeket a konfigurációs fájlhoz adtál. Ezeket a szabályokat használhatod a tunnel hibakeresésére, vagy magával a wg paranccsal is, ha kézzel szeretnéd konfigurálni a VPN interfészt.
Miután a szerver be van állítva és működik, a következő lépés a kliens gép konfigurálása WireGuard-peerként, majd csatlakozás a WireGuard szerverhez.
7. lépés — Egy WireGuard társ konfigurálása
Egy WireGuard Peer konfigurálása hasonló a WireGuard szerver beállításához. Miután telepítetted a kliens szoftvert, létrehozol egy nyilvános és egy privát kulcspárt, kiválasztod a peerhez tartozó IP-címet vagy címeket, definiálsz egy konfigurációs fájlt a peer számára, majd elindítod az alagutat a wg-quick szkript segítségével.
Annyi peer-t adhatsz hozzá a VPN-hez, amennyit szeretnél, ha létrehozol egy kulcspárt és konfigurációt az alábbi lépések szerint. Ha több peert is hozzáadsz a VPN-hez, ügyelj arra, hogy nyomon kövesd a privát IP-címeiket az ütközések elkerülése érdekében.
A WireGuard Peer konfigurálásához győződjön meg arról, hogy a WireGuard csomag telepítve van a következő apt parancsokkal. A WireGuard Peer-en futtassa:
sudo apt update
sudo apt install wireguardA WireGuard Partner kulcspárjának létrehozása
Ezután létre kell hoznia a kulcspárt a peer-en ugyanazokkal a lépésekkel, amelyeket a szerveren használt. A helyi gépéről vagy a távoli szerverről, amely a peer szerepét fogja betölteni, folytassa, és hozza létre a peer privát kulcsát az alábbi parancsok használatával:
wg genkey | sudo tee /etc/wireguard/private.key
sudo chmod go= /etc/wireguard/private.keyIsmét kapsz egyetlen sort base64 kódolt kimenettel, ami a privát kulcs. A kimenet egy másolata a /etc/wireguard/private.key fájlban is el van tárolva. Figyelmesen jegyezd fel a megjelenő privát kulcsot, mivel később hozzá kell adnod a WireGuard konfigurációs fájlhoz ebben a részben.
Ezután a következő parancsot használd a nyilvános kulcs fájl létrehozásához:
sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.keyIsmét kapsz egyetlen sort base64 kódolt kimenetet, amely a WireGuard peer nyilvános kulcsa. Másold el valahova, hogy legyen róla másolatod, mivel a nyilvános kulcsot el kell juttatnod a WireGuard szerverhez az titkosított kapcsolat létrehozásához.
A WireGuard Partner konfigurációs fájljának létrehozása
Most, hogy van egy kulcspárod, létrehozhatsz egy konfigurációs fájlt a peer számára, amely tartalmazza az összes információt, amire szüksége van a kapcsolat létrehozásához a WireGuard szerverrel.
A konfigurációs fájlhoz néhány információra lesz szükséged:
- A
base64formátumú privát kulcs, amelyet a peer-en generáltál. - Az IPv4- és IPv6-cím tartományok, amelyeket a WireGuard szerveren definiáltál.
- A WireGuard szerver
base64formátumú nyilvános kulcsa. - A WireGuard szerver nyilvános IP-címe és portszáma. Általában ez az IPv4-cím lesz, de ha a szervernek van IPv6-címe, és a kliens gépnek van IPv6 kapcsolat az internethez, akkor ezt használhatja az IPv4 helyett.
Mindezekkel az információkkal a rendelkezésre, nyiss meg egy új /etc/wireguard/wg0.conf fájlt a WireGuard Peer gépen a nano segítségével, vagy a kedvenc szerkesztőddel:
sudo nano /etc/wireguard/wg0.confAdja hozzá a következő sorokat a fájlhoz, a kiemelt részekbe szükség szerint helyettesítve be az egyes adatokat:
/etc/wireguard/wg0.conf[Interface]
PrivateKey = base64_encoded_peer_private_key_goes_here
Address = 10.8.0.2/24
Address = fd0d:86fa:c3bc::2/64
[Peer]
PublicKey = U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
AllowedIPs = 10.8.0.0/24, fd0d:86fa:c3bc::/64
Endpoint = 203.0.113.1:51820Figyeld meg, hogy az első Address sor egy IPv4-címet használ a korábban kiválasztott 10.8.0.0/24 alhálózatból. Ez az IP-cím bármi lehet az alhálózaton belül, amíg különbözik a szerver IP-címétől. Általában a legegyszerűbb módja az IP-címek kiosztásának, ha minden új peer hozzáadásakor 1-gyel növeled a címet.
Hasonlóképpen vedd észre, hogy a második Address sor az előzőleg létrehozott alhálózatból származó IPv6 címet használ, és a szerver címét eggyel növeli. Ismét, a tartomány bármely IP-címe érvényes, ha úgy döntesz, hogy másik címet használsz.
A fájl másik figyelemre méltó része az utolsó AllowedIPs sor. Ezek a két IPv4 és IPv6 tartomány azt utasítják a peer-t, hogy csak akkor küldjön forgalmat a VPN-en keresztül, ha a célrendszer IP-címe az egyik tartományba esik. Az AllowedIPs direktíva segítségével korlátozhatod a VPN-t a peer-en, hogy csak más peer-ekhez és a VPN-en található szolgáltatásokhoz csatlakozzon, vagy beállíthatod úgy, hogy az összes forgalmat a VPN-en keresztül terelje, és a WireGuard szervert használja átjáróként.
Ha csak IPv4-et használsz, hagyd ki a végén lévő fd0d:86fa:c3bc::/64 tartományt (beleértve a , vesszőt is). Ezzel szemben, ha csak IPv6-ot használsz, akkor csak a fd0d:86fa:c3bc::/64 előtagot tartalmazd, és hagyd ki a 10.8.0.0/24 IPv4 tartományt.
Mindkét esetben, ha szeretnéd az összes társaid forgalmát a VPN-en keresztül küldeni, és a WireGuard szervert használni minden forgalom átjárójaként, akkor használhatod a 0.0.0.0/0-t, ami az egész IPv4 címteret jelenti, és a ::/0-t az egész IPv6 címterületre.
(Opcionális) Egy partner konfigurálása az összes forgalom alagúton keresztüli irányítására
Ha úgy döntött, hogy az összes partneri forgalmat a 0.0.0.0/0 vagy ::/0 útvonalak használatával irányítja a tunelre, és a partner egy távoli rendszer, akkor el kell végeznie a jelen szakaszban leírt lépéseket. Ha a partnere egy helyi rendszer, akkor a legjobb, ha kihagyja ezt a szakaszt.
Távoli partnerek esetén, akikhez SSH-n vagy valamilyen más protokollon keresztül, nyilvános IP-címet használva csatlakozol, néhány extra szabályt kell hozzáadnod a partner wg0.conf fájljához. Ezek a szabályok biztosítják, hogy a rendszerhez a tunnel kívülről is csatlakozhass, amikor az létrejött. Ellenkező esetben, amikor a tunnel létrejön, minden forgalom, amelyet normál esetben a nyilvános hálózati interfész kezelt volna, nem lesz megfelelően irányítva a wg0 tunnel interfész megkerülésére, ami elérhetetlenné teszi a távoli rendszert.
Először meg kell állapítanod azt az IP-címet, amelyet a rendszer alapértelmezett átjáróként használ. Futtasd a következő ip route parancsot:
ip route list table main defaultA következőhöz hasonló kimenetet fogsz kapni:
default via 203.0.113.1 dev eth0 proto staticJegyezze fel a hálózati átjáró kiemelt IP-címét 203.0.113.1 a későbbi használathoz, valamint az eszközt eth0. Az ön eszközneve eltérő lehet. Ha igen, cserélje ki a következő parancsokban az eth0-t az ön eszköznevére.
Ezután találja meg a rendszer nyilvános IP-címét úgy, hogy a készüléket a ip address show parancs segítségével vizsgálja meg:
ip -brief address show eth0A következőhöz hasonló kimenetet fogsz kapni:
eth0 UP 203.0.113.5/20 10.20.30.40/16 2604:a880:400:d1::3d3:6001/64 fe80::68d5:beff:feff:974c/64Ebben a példa kimenetben a kiemelt 203.0.113.5 IP-cím (a /20 végződés nélkül) az a nyilvános cím, amelyet az eth0 eszközhöz rendelnek, és amelyet hozzá kell adnod a WireGuard konfigurációhoz.
Most nyisd meg a WireGuard Peer /etc/wireguard/wg0.conf fájlját a nano segítségével vagy a kedvenc szerkesztőddel.
sudo nano /etc/wireguard/wg0.confA [Peer] sor előtt add hozzá a következő 4 sort:
PostUp = ip rule add table 200 from 203.0.113.5
PostUp = ip route add table 200 default via 203.0.113.1
PreDown = ip rule delete table 200 from 203.0.113.5
PreDown = ip route delete table 200 default via 203.0.113.1
[Peer]
. . .Ezek a sorok egy egyedi útválasztási szabályt hoznak létre, és hozzáadnak egy egyedi útvonalat annak biztosítására, hogy a rendszer felé irányuló nyilvános forgalom az alapértelmezett átjárót használja.
PostUp=ip rule add table 200 from 203.0.113.5- Ez a parancs létrehoz egy szabályt, amely ellenőrzi a200számú táblázatban található útvonal-bejegyzéseket, amikor az IP megegyezik a rendszer nyilvános203.0.113.5címével.PostUp=ip route add table 200 default via 203.0.113.1- Ez a parancs biztosítja, hogy a200táblán feldolgozott minden forgalom a203.0.113.1átjárót használja az útválasztáshoz, a WireGuard interfész helyett.
A PreDown sorok eltávolítják az egyedi szabályt és útvonalat, amikor a tunel leáll.
Megjegyzés: A 200 táblaszám önkényes ezeknek a szabályoknak az összeállításakor. Használhat egy értéket 2 és 252 között, vagy használhat egy egyéni nevet a /etc/iproute2/rt_tables fájlhoz címke hozzáadásával, majd hivatkozhat a névre a számérték helyett.
További információkért arról, hogyan működnek az útválasztási táblák Linux alatt, látogassa meg az IP réteg hálózati adminisztráció útmutató Linuxban című útmutató Útválasztási táblák szekcióját.
Ha az összes partner forgalmát a VPN-en keresztül irányítja, győződjön meg róla, hogy a helyes sysctl és iptables szabályokat konfigurálta a WireGuard szerveren a A WireGuard szerver hálózati konfigurációjának beállítása és a A WireGuard szerver tűzfalának konfigurálása részekben.
(Opcionális) A WireGuard partner DNS-felbontóinak konfigurálása
Ha a WireGuard szervert VPN átjáróként használja az összes társ forgalmához, akkor a [Interface] szakaszhoz hozzá kell adnia egy sort, amely megadja a DNS feloldókat. Ha nem adja hozzá ezt a beállítást, akkor a DNS-kérései nem lehetnek védve a VPN által, vagy akár az internetszolgáltatójának vagy más harmadik feleknek is láthatóvá válhatnak.
Ha csak a WireGuardot használod a VPN-hálózaton található erőforrások elérésére, vagy peer-to-peer konfigurációban, akkor ezt a szakaszt kihagyhatod.
A DNS-felvevők hozzáadásához a társa konfigurációjához először határozza meg, mely DNS-kiszolgálókat használ a WireGuard szervere. Futtassa a következő parancsot a WireGuard szerveren, cserélve ki az ethernet eszköz nevét a eth0-ra, ha az ebben a példában szereplőtől eltér:
resolvectl dns eth0A következőhöz hasonló kimenetet kellene kapnod:
Link 2 (eth0): 67.207.67.2 67.207.67.3 2001:4860:4860::8844 2001:4860:4860::8888Azok az IP-címek, amelyek kimenetként jelennek meg, a szerver által használt DNS-felbontók. Választhatod bármelyiket vagy mindet, esetleg csak az IPv4-et vagy az IPv6-ot az igényeid szerint. Jegyezd fel azokat a felbontókat, amelyeket használni fogsz.
Ezután hozzá kell adnia a kiválasztott feloldókat a WireGuard Peer konfigurációs fájljához. Menjen vissza a WireGuard Peer gépre, és nyissa meg a /etc/wireguard/wg0.conf fájlt a nano vagy a kedvenc szerkesztője segítségével:
sudo nano /etc/wireguard/wg0.confA [Peer] sor előtt add hozzá a következőt:
DNS = 67.207.67.2 2001:4860:4860::8844
[Peer]
. . .Ismételten, az IPv4 és IPv6 iránti preferenciáidtól vagy követelményeidtől függően szerkesztheted a listát a saját igényeid szerint.
Miután a következő lépésben csatlakoztál a VPN-hez, ellenőrizheted, hogy a DNS-kéréseidet a VPN-en keresztül küldöd-e, például egy olyan oldallal, mint a DNS leak test.
A resolvectl dns parancs segítségével azt is ellenőrizheted, hogy a társoldalad a beállított feloldókat használja-e, ahogy a szerveren is futtattad. Olyan kimenetet kell kapnod, mint az alábbi, amely megmutatja a VPN alagúthoz konfigurált DNS-feloldókat:
Global: 67.207.67.2 67.207.67.3
. . .Mindezen DNS-felbontó beállítások után készen állsz arra, hogy hozzáadd a társ nyilvános kulcsát a szerverhez, majd elindítsd a WireGuard alagutat a társon.
8. lépés — A partner nyilvános kulcsának hozzáadása a WireGuard szerverhez
Mielőtt csatlakoztatná a társat a szerverhez, fontos, hogy hozzáadja a társa nyilvános kulcsát a WireGuard szerverhez. Ez a lépés biztosítja, hogy képes lesz csatlakozni és forgalmat irányítani a VPN-en keresztül. Ennek a lépésnek a befejezése nélkül a WireGuard szerver nem engedélyezi a társnak, hogy bárminemű forgalmat küldjön vagy fogadjon a tunelen keresztül.
Győződjön meg róla, hogy van egy példánya a WireGuard Peer base64 formátumú nyilvános kulcsáról a következő parancs futtatásával:
sudo cat /etc/wireguard/public.keyPeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=Most jelentkezz be a WireGuard szerverre, és futtasd a következő parancsot:
sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= allowed-ips 10.8.0.2,fd0d:86fa:c3bc::2Vegye figyelembe, hogy a allowed-ips rész a parancsban vesszővel elválasztott IPv4 és IPv6 címeket vesz fel. Megadhat egyedi IP-címeket, ha korlátozni szeretné, hogy egy peer milyen IP-címet rendelhet magának, vagy megadhat egy tartományt az példában látható módon, ha a peer-ek a VPN-tartomány bármely IP-címét használhatják. Azt is vegye figyelembe, hogy két peer nem rendelkezhet ugyanazzal a allowed-ips beállítással.
Ha frissíteni szeretné a meglévő peer allowed-ips beállításait, ugyanazt a parancsot futtathatja újra, de módosítsa az IP-címeket. Több IP-cím is támogatott. Például, ha a nemrég hozzáadott WireGuard Peer-hez szeretne egy 10.8.0.100 IP-címet hozzáadni a meglévő 10.8.0.2 és fd0d:86fa:c3bc::2 IP-címekhez, az alábbi parancsot kell futtatnia:
sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= allowed-ips 10.8.0.2,10.8.0.100,fd0d:86fa:c3bc::2Miután lefuttattad a parancsot a peer hozzáadásához, ellenőrizd a tunnel státuszát a szerveren a wg parancs segítségével:
sudo wginterface: wg0
public key: U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
private key: (hidden)
listening port: 51820
peer: PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=
allowed ips: 10.8.0.2/32, fd0d:86fa:c3bc::/128Figyeld meg, hogyan mutatja a peer sor a WireGuard peer nyilvános kulcsát, valamint azokat az IP-címeket vagy címtartományokat, amelyeket használhat saját IP-címének kijelölésére.
Most, hogy meghatároztad a peer kapcsolati paramétereit a szerveren, a következő lépés a tunnel elindítása a peer-en.
9. lépés — A WireGuard-társ csatlakoztatása az alagúthoz
Most, hogy a szerver és a partner is úgy van beállítva, hogy támogassa az IPv4, IPv6, csomagátirányítás és DNS-felbontás lehetőségeit, itt az ideje, hogy a partnert csatlakoztassuk a VPN-alagúthoz.
Mivel előfordulhat, hogy a VPN-t csak bizonyos használati eseteknél szeretnéd bekapcsolni, a kapcsolat kézi létrehozásához a wg-quick parancsot fogjuk használni. Ha automatikusan szeretnéd indítani a tunelt, ahogy a szerveren tetted, akkor kövesd a A WireGuard szerver indítása szakasz lépéseit a wg-quick parancs használata helyett.
Ha az összes forgalmat a VPN-en keresztül irányítja, és beállította a DNS-továbbítást, telepítenie kell a resolvconf segédprogramot a WireGuard Peer-re, mielőtt elindítja a tunelést. A beállításhoz futtassa a következő parancsot:
sudo apt install resolvconfA tunnel elindításához futtassa a következőt a WireGuard Peer-en:
sudo wg-quick up wg0A következőhöz hasonló kimenetet fogsz kapni:
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip -6 address add fd0d:86fa:c3bc::2/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -xFigyelje meg a kiemelt IPv4 és IPv6 címeket, amelyeket a peer számára rendelt.
Ha a partnernél a AllowedIPs értékét 0.0.0.0/0-ra és ::/0-ra állítod (vagy más tartományokat használsz, mint amiket a VPN-hez választottál), akkor a kimeneted a következőhöz fog hasonlítani:
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip -6 address add fd0d:86fa:c3bc::2/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x
[#] wg set wg0 fwmark 51820
[#] ip -6 route add ::/0 dev wg0 table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip6tables-restore -n
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -nEbben a példában figyelje meg a kiemelt útvonalakat, amelyeket a parancs hozzáadott, és amelyek megfelelnek a peer konfigurációban szereplő AllowedIPs beállításnak.
A tunnel állapotát a peer-en a wg parancs segítségével ellenőrizheti:
sudo wginterface: wg0
public key: PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=
private key: (hidden)
listening port: 49338
fwmark: 0xca6c
peer: U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
endpoint: 203.0.113.1:51820
allowed ips: 10.8.0.0/24, fd0d:86fa:c3bc::/64
latest handshake: 1 second ago
transfer: 6.50 KiB received, 15.41 KiB sentÚjra ellenőrizheted a szerver állapotát is, és hasonló eredményt kapsz.
Ellenőrizze, hogy a társ valójában a VPN-t használja-e a ip route és a ip -6 route parancsokkal. Ha a VPN-t minden internethasználatánál átjáróként használja, ellenőrizze, melyik interfész lesz használva az olyan célforgalmakhoz, amelyek a CloudFlare 1.1.1.1 és 2606:4700:4700::1111 DNS feloldóihoz irányulnak.
Ha csak a WireGuardot használja VPN-en keresztüli erőforrások elérésére, helyettesítsen egy érvényes IPv4- vagy IPv6-címet, például magát a gatewayt ezekbe a parancsokba. Például 10.8.0.1 vagy fd0d:86fa:c3bc::1.
ip route get 1.1.1.11.1.1.1 dev wg0 table 51820 src 10.8.0.2 uid 1000
cacheFigyeld meg, hogy a wg0 eszközt használják, és az IPv4-címet 10.8.0.2, amit a peerhez rendeltél. Hasonlóképpen, ha IPv6-ot használsz, futtasd a következőt:
ip -6 route get 2606:4700:4700::11112606:4700:4700::1111 from :: dev wg0 table 51820 src fd0d:86fa:c3bc::2 metric 1024 pref mediumFigyeld meg ismét a wg0 interfészt, valamint az IPv6 címet fd0d:86fa:c3bc::2, amelyet a peer-hez rendeltél.
Ha a partnerednek van böngészője telepítve, akkor azt is meglátogathatod, hogy az ipleak.net és az ipv6-test.com oldalakon ellenőrizd, valóban a VPN-en keresztül irányítja-e a forgalmát.
Amint készen állsz a VPN lecsatlakoztatására a peer-en, használd a wg-quick parancsot:
sudo wg-quick down wg0Olyan kimenetet fog kapni, amely azt jelzi, hogy a VPN-alagút le van állítva:
[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -fHa a partnernél a AllowedIPs értékét 0.0.0.0/0-ra és ::/0-ra állítja (vagy más tartományokat használ, mint amelyeket a VPN-hez választott), akkor a kimenete a következőhöz fog hasonlítani:
[#] ip rule delete table 200 from 203.0.113.5
[#] ip route delete table 200 default via 203.0.113.1
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip -6 rule delete table 51820
[#] ip -6 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f
[#] iptables-restore -n
[#] ip6tables-restore -nA VPN-hez való újbóli csatlakozáshoz futtassa újra a wg-quick up wg0 parancsot a peer-en. Ha teljesen el szeretné távolítani egy peer konfigurációját a WireGuard szerverről, futtathatja a következő parancsot, ügyelve arra, hogy a helyes publikus kulcsot adja meg a törölni kívánt peerhez:
sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= removeÁltalában csak akkor kell eltávolítani egy peer konfigurációt, ha a peer már nem létezik, vagy ha az titkosítási kulcsai kompromittálódtak vagy megváltoztak. Egyébként jobb a konfigurációt a helyén hagyni, hogy a peer újra csatlakozni tudjon a VPN-hez anélkül, hogy minden alkalommal hozzá kellene adnia a kulcsát és az allowed-ips-t.
A WireGuard kulcsok kezelése és forgatása
A WireGuard a hitelesítéshez és titkosításhoz statikus nyilvános és privát kulcspárokra támaszkodik. Ez a kialakítás jelentősen csökkenti a konfigurációs bonyolultságot, ugyanakkor a kulcskezelés teljes felelősségét az adminisztrátorra helyezi. Hosszú távú VPN-telepítések, megosztott infrastruktúrák vagy több szereplőt tartalmazó környezetek esetén a gondos kulcskezelés elengedhetetlen a biztonság és a működési stabilitás fenntartásához.
A WireGuard kulcstípusainak megértése
Minden WireGuard peer kétféle kriptográfiai kulcsot használ.
Hosszú távú privát kulcsok: Egy privát kulcs egyedi módon azonosít egy tagnak, és mindig titokban kell maradnia. Ezt a kulcsot titkosított kézfogások során használják a tag hitelesítésére és rövid élettartamú munkamenet-kulcsok létrehozására. Ha egy privát kulcs kiszivárog, bármely rendszer, amely ezt a kulcsot birtokolja, képes lehet a tag személyazonosságának megszemélyesítésére.
Hosszú távú nyilvános kulcsok: A nyilvános kulcs a privát kulcsból származik, és megosztják más felhasználókkal. A központi csomóponton a nyilvános kulcsok határozzák meg, mely felhasználók kommunikálhatnak, és mely IP-címeket használhatják.
Ezeken a hosszú távú kulcsokon kívül a WireGuard automatikusan létrehoz rövid életű munkamenet-kulcsokat a titkosított kézfogások során. Ezeket a munkamenet-kulcsokat időszakosan cserélik, és tökéletes előre titkosságot biztosítanak az adminisztrátor beavatkozása nélkül.
Ajánlott kulcskezelési gyakorlatok
A következő gyakorlatok segítenek csökkenteni a kockázatot és egyszerűsíteni a folyamatos működést:
Rendelj egyedi kulcspárt minden csapathoz: Minden eszköznek saját privát és nyilvános kulcspárral kell rendelkeznie. Az egyedi kulcsok használata lehetővé teszi, hogy a hozzáférést egyetlen eszközre korlátozottan visszavonjuk anélkül, hogy másokra hatással lenne. Az ugyanazon kulcsok több rendszeren történő újrafelhasználása növeli egy esetleges kompromittálás hatását és bonyolítja az auditálást.
Korlátozza a privát kulcs anyaghoz való hozzáférést: A privát kulcs fájlokat csak a root felhasználónak kell olvashatóvá tenni. Linux rendszereken ez általában azt jelenti, hogy a jogosultságokat
600-ra állítják egy olyan parancs segítségével, mint példáulchmod 600 /etc/wireguard/private.key. A fájlhozzáférés korlátozása segít megelőzni a véletlen kiszivárgást mentések, naplók vagy nem jogosult felhasználók által.Tarts fenn egy nyilvános peer-nyilvántartást: Vezessen nyilvántartást, amely minden peer nyilvános kulcsát összekapcsolja a készülék nevével, a hozzárendelt IPv4- és IPv6-címekkel, valamint a szándékolt felhasználási céllal. Ez a dokumentáció egyre fontosabbá válik, ahogy a peer-ek száma nő, és megkönnyíti a hibakeresést, az ellenőrzéseket és a rutinszerű karbantartást.
Távolítsa el a használaton kívüli vagy inaktív partnereket időben: Amikor egy eszközt kivonnak a használatból, vagy már nincs szüksége VPN-hozzáférésre, távolítsa el a nyilvános kulcsát a központi partnerkonfigurációból. A használaton kívüli kulcsok megtartása növeli a támadási felületet, és megnehezíti a jövőbeli ellenőrzéseket.
Helyzetek, amelyek kulcscsere igényelnek
A kulcscserét több gyakori esetben kell elvégezni:
Feltételezett vagy megerősített kulcskiszivárgás: Ha egy privát kulcsot esetleg lemásoltak, kiszivárogtattak vagy illetéktelen személy hozzáférhetett, azt azonnal cserélni kell a hamisítás megelőzése érdekében.
Elveszett vagy ellopott eszközök: Ha egy eszköz elveszik vagy ellopják, a kulcsok cseréje biztosítja, hogy az már ne tudjon csatlakozni a VPN-hez, még akkor sem, ha az eredeti konfiguráció visszaállításra kerül.
Szervezeti biztonsági követelmények: Bizonyos környezetekben időszakos kulcscserére van szükség a belső szabályzatok vagy megfelelési előírások betartása érdekében, még akkor is, ha nincs gyanú a kompromittálódásra.
Változások az eszköz tulajdonjogában vagy szerepében: Amikor egy társ eszközt másik felhasználóhoz vagy célhoz rendelnek, a kulcsok cseréje megakadályozza a nem kívánt továbbra is fennálló hozzáférést.
A partner kulcsainak biztonságos cseréje
A WireGuard a belső IP-címeket konkrét nyilvános kulcsokhoz rendeli egy kriptokulcs útválasztási tábla segítségével. Emiatt a kialakítás miatt ugyanaz a belső IP-cím nem rendelhető biztonságosan két nyilvános kulcshoz egyszerre. A kulcscserék tehát általában rövid megszakítást okoznak a kapcsolatban, amíg a konfiguráció frissítésre kerül.
A partner kulcsainak forgatásához kövesse ezt a folyamatot:
- Generáljon egy új privát és nyilvános kulcspárt a peer-en.
- Frissítse a központi peer konfigurációját úgy, hogy a régi nyilvános kulcsot az újra cseréli, miközben megtartja ugyanazokat az
AllowedIPsértékeket. Ne indítsa újra még az interfészt. - Frissítse a peer konfigurációs fájlját, hogy az új privát kulcsot használja.
- Alkalmazza a frissített konfigurációt a központi peer-en, például a WireGuard szolgáltatás újratöltésével vagy a
wg syncconfhasználatával. Ekkor a peer ideiglenesen elveszíti a kapcsolatot. - Indítsd újra a WireGuard interfészt a peer-en, hogy az elkezdhesse használni az új privát kulcsot.
- Ellenőrizze, hogy az új kézfogás befejeződik-e és hogy a forgalom megfelelően áramlik-e.
- Távolíts el minden maradék hivatkozást a régi kulcsra, ha még léteznek.
Ez a cserén alapuló megközelítés tükrözi, hogyan érvényesíti a WireGuard a kriptográfiai útválasztást, és kerüli az ellentmondásos vagy ütköző konfigurációkat.
A kulcsok forgatása a központi csomóponton
A központi peer privát kulcsának cseréje az összes csatlakozó peerre hatással van. Minden peer konfigurációját frissíteni kell az új nyilvános kulccsal, mielőtt a kapcsolat helyreállítható lenne.
Mivel ez a változás egyszerre minden peer-t érint, a központi peer kulcs cseréjét gondosan kell megtervezni, és karbantartási időszak alatt kell végrehajtani. Gyakorlatban a központi kulcsokat ritkábban cserélik, mint a peer kulcsokat.
Előre megosztott kulcsok kezelése (opcionális)
A nyilvános és privát kulcspárok mellett a WireGuard opcionálisan támogatja az előre megosztott kulcsot (PSK) minden peer esetében. A PSK további réteg szimmetrikus titkosítást ad a WireGuard meglévő kriptográfiája tetejére.
Az előre megosztott kulcsokat általában nagy biztonságú környezetekben használják a jövőbeli kriptográfiai fejlesztések elleni védelemként. Ha a ma titkosított forgalmat rögzítik, és a mögöttes nyilvános kulcsú algoritmust a jövőben feltörik, egy PSK még mindig megakadályozná a múltbeli munkamenetek visszafejtését.
Ha PSK-kat használnak, azokat érzékeny titkokként kell kezelni, és időszakosan cserélni kell. Egy PSK cseréje ugyanazt az operatív mintát követi, mint a partnerek kulcsainak cseréje, és mindkét félnek koordinálnia kell a kapcsolat során.
A forgási frekvencia kiválasztása
A WireGuard nem ír elő rögzített kulcscsere ütemtervet. A megfelelő csereidőköz a környezettől függ.
- A személyes vagy rövid távú telepítésekhez előfordulhat, hogy nincs szükség ütemezett forgatásra.
- A megosztott vagy éles környezetekben a kulcsokat általában 6–12 havonta cserélik.
- A magas biztonságú környezetekben a szabályzat alapján gyakrabban kell cserélni.
A rendszeres forgatás csökkenti a hosszú élettartamú hitelesítő adatokkal járó kockázatot, és a WireGuard telepítéseket a megszokott biztonsági gyakorlatokhoz igazítja.
WireGuard vs OpenVPN: Gyakorlati különbségek
A WireGuard és az OpenVPN egyaránt széles körben használt VPN-technológiák, de nagyon eltérő megközelítést alkalmaznak a titkosítás, a konfiguráció és a hálózati viselkedés terén. E különbségek megértése segít a fejlesztőknek kiválasztani a működési korlátaiknak leginkább megfelelő megoldást.
Konfigurációs és működési modell
A WireGuard egy statikus konfigurációs modellt használ, amely nyilvános és privát kulcspárokon alapul. Minden csomópont kifejezetten van meghatározva, és az útválasztás viselkedését rögzített konfigurációs értékek szabályozzák. Nincs vezérlőcsatorna, tanúsítványhatóság vagy a paraméterek dinamikus egyeztetése.
Az OpenVPN a TLS-re és az X.509 tanúsítványokra támaszkodik. Egy vezérlőcsatornát használ a kliensek hitelesítésére, a titkosítási beállítások egyeztetésére és a munkamenetek kezelésére. Ez a modell rugalmasságot biztosít, de növeli a konfiguráció és az üzemeltetés bonyolultságát.
A gyakorlatban a WireGuard konfigurációk rövidebbek, könnyebben ellenőrizhetők, és kevésbé hajlamosak a finom hibákra. Az OpenVPN konfigurációk nagyobb irányítást kínálnak, de gondos kezelést igényelnek a biztonság és a konzisztencia megőrzése érdekében.
Kriptográfia és biztonsági tervezés
A WireGuard egy meghatározott, modern kriptográfiai módszerekből álló készletet használ. Ezek a beállítások nem konfigurálhatók. Ez a kialakítás kiküszöböli a kriptográfiai visszalépéses támadásokat, és megszünteti a titkosítási készletek kiválasztásának szükségességét.
Az OpenVPN számos titkosítási algoritmust és hitelesítési módszert támogat. Bár ez a rugalmasság lehetővé teszi a kompatibilitást régi rendszerekkel, egyben növeli a gyenge vagy következetlen konfigurációk kockázatát is.
Mindkét megoldás támogatja a tökéletes előremenő titoktartást. A WireGuard automatikusan végzi a kulcscserét a kézfogási mechanizmusán keresztül, míg az OpenVPN a TLS munkamenetek viselkedésére támaszkodik.
Teljesítménymutatók
A WireGuard magas teljesítmény és alacsony késleltetés érdekében készült. A Linux kernelében fut, és kicsi a kódbázisa, ami csökkenti a terhelést és a kontextusváltást. A legtöbb környezetben a WireGuard magasabb átviteli sebességet és következetesebb késleltetést biztosít minimális beállítással.
Történelmileg az OpenVPN felhasználói térben fut, és további terhelést okoz a kontextusváltásokból és a protokollkezelésből adódóan. Az OpenVPN modern verziói támogatják a Kernel Data Channel Offload (DCO) funkciót, ami jelentősen javítja a teljesítményt, de ez a funkció nem mindig van engedélyezve vagy elérhető az alapértelmezett telepítésekben.
Még a DCO használatával is a WireGuard általában erős teljesítményt nyújt kevesebb konfigurációs változóval.
Hálózati vándorlás és tűzfal átlépés
A WireGuard zökkenőmentesen kezeli a hálózati változásokat. Ha egy partner IP-címe megváltozik, például WiFi és mobilhálózat közötti váltáskor, az alagút újratárgyalás nélkül folytatja a működést.
A WireGuard azonban kizárólag UDP-n keresztül működik. Bár az UDP hatékony, bizonyos szigorú nyilvános WiFi hálózatokon, vállalati tűzfalakon vagy intézményi hálózatokon néha le van tiltva. A WireGuardnak nincs beépített tartalék megoldása, ha az UDP-forgalmat blokkolják.
Az OpenVPN mind az UDP-t, mind a TCP-t támogatja. Ha az UDP nem érhető el, az OpenVPN konfigurálható úgy, hogy a TCP 443-as porton fusson, így a VPN-forgalom hasonlóan fog kinézni, mint a szabványos HTTPS-forgalom. Ez a képesség megbízhatóbbá teszi az OpenVPN-t azokban a környezetekben, ahol szigorú tűzfal szabályok vagy cenzúra van.
A korlátozó hálózatok mögött dolgozó felhasználók számára a TCP-támogatás gyakran döntő tényező az OpenVPN választásában a WireGuarddal szemben.
Funkciók hatóköre és bővíthetősége
Az OpenVPN olyan funkciókat tartalmaz, amelyeket a WireGuard szándékosan nem biztosít. Ide tartozik a felhasználó alapú hitelesítés, a dinamikus címhozzárendelés és a külső identitásrendszerekkel való integráció.
A WireGuard kizárólag a biztonságos alagútképzésre összpontosít. A hitelesítési folyamatokat, a hozzáférés-ellenőrzést és a dinamikus konfigurációt a protokollon kívül kell kezelni.
Ezért az OpenVPN jobban megfelel olyan környezetekben, ahol összetett hitelesítésre vagy központosított felhasználókezelésre van szükség, míg a WireGuard inkább az infrastruktúraszintű VPN-ekhez és az egyenrangú hozzáféréshez illik.
Összegző összehasonlítás
| Aspektus | WireGuard | OpenVPN |
|---|---|---|
| Adatátviteli protokoll | Csak UDP | UDP és TCP |
| Konfigurációs stílus | Statikus, kulcsalapú | Dinamikus, tanúsítvány alapú |
| Kódalap mérete | Kicsi | Nagy |
| Titkosítási lehetőségek | Rögzített | Konfigurálható |
| Teljesítmény | Magas | Mérsékeltől magasig |
| Roaming támogatás | Beépített | Korlátozott |
| Tűzfal-ellenállás | Korlátozott a szigorú hálózatokon | Erős a TCP 443-on |
| Bonyolultság | Alacsony | Magas |
A WireGuard és az OpenVPN közötti választás
A WireGuard jól alkalmas infrastruktúra VPN-ekhez, telephelyek közötti alagutakhoz, mobil klienshez, valamint olyan környezetekhez, ahol az egyszerűség, a teljesítmény és az előrejelezhetőség az elsődleges szempont.
Az OpenVPN továbbra is erős választás vállalati környezetekben, ahol TCP-alapú alagútépítésre, fejlett hitelesítésre vagy megbízható működésre van szükség szigorú tűzfalak mögött.
Sok modern telepítésben a WireGuard azért váltja fel az OpenVPN-t, nem azért, mert több funkciót kínálna, hanem azért, mert kevesebb funkciója van, átláthatóbb működéssel.
Teljesítményhangolás és optimalizálás
A WireGuard jól teljesít az alapértelmezett beállításaival, de a valós hálózati körülmények befolyásolhatják a megbízhatóságot és az átbocsátóképességet. Olyan tényezők, mint a csomagméret, az útválasztás hatóköre, a NAT viselkedése és a DNS-felbontás mind befolyásolják, hogyan viselkedik a tunnel folyamatos vagy időszakos használat során.
Nézzük meg a leggyakoribb hangolási területeket, és mikor szükséges a beállításuk.
MTU kiválasztása és csomagfelosztás
A maximális átviteli egység (MTU) meghatározza a legnagyobb csomagméretet, amely törés nélkül továbbítható. A WireGuard titkosítja és kapszulázza a csomagokat, ami csökkenti a hatékony MTU-t a fizikai hálózati interfészhez képest.
Alapértelmezés szerint a WireGuard 1420 MTU-t használ. Ez az érték figyelembe veszi az IPv6 fejlécek, a UDP és a WireGuard kapszulázás összesített overhead-jét, és a legtöbb Ethernet-alapú hálózaton jól működik. Bizonyos környezetek kisebb MTU-t igényelnek. Ez gyakori a mobilhálózatokon, PPPoE kapcsolatoknál és olyan felhőplatformokon, ahol további kapszulázási rétegek vannak. Ha az MTU túl nagy, a csomagok elveszhetnek vagy feldarabolódhatnak. Ez gyakran olyan kapcsolatokat eredményez, amelyek kis kérésekre működnek, de nagyobb adatátvitel esetén megrekednek vagy meghiúsulnak. Ha ezek a tünetek jelentkeznek, az MTU fokozatos csökkentése ajánlott. Az olyan értékek, mint a 1360, vagy szigorúbb környezetben a 1280, amely az IPv6 minimális MTU-ja, gyakran megoldják ezeket a problémákat minimális hatással az átvitelre.
Az MTU értékét kifejezetten a konfigurációs fájl [Interface] szakaszában kell beállítani a következetes működés biztosítása érdekében újraindítások során.
AllowedIPs hatóköre és hatása
Az AllowedIPs direktíva befolyásolja mind az útválasztási viselkedést, mind a teljesítményt. A széles címtartományok több forgalmat irányítanak át a tunneleken, ami megnöveli a titkosítási terhelést és a szerverre nehezedő terhelést. Szűk AllowedIPs értékek használatával a tunnel csak a védelmet igénylő forgalomra korlátozódik. Ez csökkenti a CPU-használatot és elkerüli a felesleges kapszulázást.
Amikor a 0.0.0.0/0 vagy ::/0 van beállítva, az összes forgalom a VPN-en keresztül halad. Ez a konfiguráció megfelelő, ha a magánélet, a központi kimeneti irányítás vagy a megbízhatatlan hálózatok fontos szempontok, de növeli a késleltetést és az erőforrás-felhasználást az általános internetforgalom esetében.
A teljesítményoptimalizálás gyakran magában foglalja az AllowedIPs lehető legszűkítését, és a teljes alagútrouting elkerülését, hacsak nem szükséges.
NAT áteresztés és kapcsolat stabilitása (PersistentKeepalive)
A WireGuard szándékosan csendben marad, ha nincs adatátvitel. Alapértelmezés szerint nem küld időszakos keepalive csomagokat. Olyan környezetekben, ahol NAT-ot használnak, például otthoni routereknél, mobil hálózatokban vagy sok felhőalapú hálózatban, ez a csend azt eredményezheti, hogy a NAT eszköz lezárja a kapcsolati térképet. Amikor ez megtörténik, a szervertől érkező bejövő forgalmat blokkolja, amíg a peer újra nem küld forgalmat. Ezt a viselkedést gyakran késleltetésnek, késői kapcsolódásnak vagy időszakos hibáknak érzékelik.
Ennek megelőzésére a WireGuard biztosítja a PersistentKeepalive beállítást. Ezt az opciót a peer konfiguráció [Peer] szakaszához lehet hozzáadni. Ez azt eredményezi, hogy a peer egy kis keepalive csomagot küld meghatározott időközönként, hogy a NAT leképezés nyitva maradjon. A 25 másodperces értéket gyakran használják, és a legtöbb NAT eszközzel jól működik. Ha egy kapcsolat kezdetben működik, de hosszabb ideig inaktív állapot után megszakad, a PersistentKeepalive=25 engedélyezése az elsődleges és ajánlott megoldás.
DNS-felbontás és alagútviselkedés
A DNS-konfigurációnak jelentős hatása van a tapasztalt VPN-teljesítményre. Ha a DNS-felbontók nincsenek helyesen átirányítva az alagúton keresztül, az alkalmazások lassúnak vagy megbízhatatlannak tűnhetnek, még akkor is, ha maga az alagút megfelelően működik.
A hálózati átjáró beállításaiban a DNS-lekérdezéseket a VPN-en keresztül kell küldeni a következetes forgalomirányítás biztosítása és a szivárgások elkerülése érdekében. Ehhez a DNS-felbontókat kifejezetten meg kell határozni a peer konfigurációban. Ha a DNS helytelenül van beállítva, a gyakori tünetek közé tartozik az oldalak lassú betöltése, a bizonytalan csatlakozás, vagy hogy a forgalom a VPN-tunneleken kívülre kerül, annak ellenére, hogy a tunnel aktív.
Olyan feloldók kiválasztása, amelyek elérhetők a tunelen keresztül és gyorsan válaszolnak, javítja mind a megbízhatóságot, mind a felhasználói élményt.
IPv4 és IPv6 teljesítménykülönbségek
A kettős protokollos környezetekben az IPv4 és az IPv6 viselkedése eltérő lehet. Az IPv6 útvonalakon eltérő MTU-korlátok, útválasztási szabályok vagy tűzfal viselkedés is előfordulhatnak.
A két protokoll független tesztelése segít azonosítani a protokollspecifikus problémákat. Olyan eszközök, mint a ping, a tracepath és az ip route get, hasznosak az egyes címcsaládokra vonatkozó útválasztás és MTU viselkedés ellenőrzésére.
Ha az IPv6 teljesítménye ingadozónak tűnik, ellenőrizze, hogy az ICMPv6-forgalom engedélyezve van-e. Az ICMPv6 szükséges az útvonal MTU-felfedezéshez, és ennek blokkolása nagyobb csomagoknál a kapcsolatok akadozását okozhatja.
CPU és titkosítási ráfordítás
A WireGuard modern kriptográfiát használ, amely a legtöbb rendszeren hatékony. Azonban a titkosítás még mindig CPU-erőforrásokat igényel.
Kisméretű virtuális gépeken, beágyazott routereken vagy hardveres gyorsítás nélküli rendszereken a teljes alagút konfigurációk tartós terhelés mellett leterhelhetik a CPU-t.
A CPU-használat figyelése magas forgalom esetén segít meghatározni, hogy a teljesítményproblémákat a titkosítási terhelés okozza-e, és nem a hálózati konfiguráció. Ilyen esetekben szükség lehet a csatornázott forgalom csökkentésére vagy a szerver példány frissítésére.
A teljesítményváltozások érvényesítése
A teljesítményhangolást fokozatosan kell végezni. Minden változtatás után ellenőrizni kell a kapcsolódást és a stabilitást, mielőtt további beállításokat alkalmaznánk.
Hasznos érvényesítési lépések közé tartozik a kézfogás stabilitásának ellenőrzése a wg segítségével, a késleltetés és a sávszélesség mérése a változtatások előtt és után, valamint az irányítási viselkedés megerősítése a ip route és a ip -6 route parancsokkal. Ez a megközelítés minimalizálja a kockázatot és egyszerűsíti a hibakeresést.
GYIK
1. Mi az a WireGuard, és hogyan működik Ubuntun?
A WireGuard egy modern VPN-technológia, amelyet úgy terveztek, hogy sokkal gyorsabb és könnyebben beállítható legyen, mint a régebbi megoldások, például az OpenVPN vagy az IPsec. Úgy gondolhatunk rá, mint egy biztonságos alagútra, amely közvetlenül összeköti az eszközeidet. Az olyan régi VPN-ekkel ellentétben, amelyek nehezek és bonyolultak, a WireGuard rendkívül könnyű. Ubuntun úgy működik, hogy közvetlenül a Linux kernelben fut; az operációs rendszer „motorjában”. Mivel a rendszer mélyén fut, nem pedig külön alkalmazásként a tetején, nagyon kevés akkumulátort használ és hihetetlen gyorsasággal dolgozza fel az adatokat.
A kapcsolat létrehozásához a WireGuard egy az SSH-hoz nagyon hasonló módszert használ. Minden eszközhöz generál egy "kulcspárt": egy privát kulcsot (ami titokban marad az eszközön) és egy publikus kulcsot (amit megosztasz azokkal az eszközökkel, amelyekhez csatlakozni szeretnél). A kapcsolat csak akkor jön létre, ha a kulcsok tökéletesen egyeznek, így a kézfogás gyors és biztonságos marad.
2. Biztonságosabb a WireGuard, mint az OpenVPN?
A legtöbb felhasználó számára a WireGuard biztonságosabbnak számít az egyszerűsége és modern kialakítása miatt. Az elsődleges oka a kód mérete. A WireGuard mindössze körülbelül 4 000 sor kóddal készült, míg az OpenVPN kódja több mint 100 000 sorból áll. Ez az óriási különbség azt jelenti, hogy a biztonsági szakértők sokkal könnyebben tudják átolvasni a WireGuard kódját és felfedezni a sérülékenységeket (hibákat) a rosszindulatú szereplők előtt.
A WireGuard arra is kényszerít, hogy a mai legújabb, legerősebb titkosítási szabványokat használd. A régebbi VPN-ek lehetővé teszik a kripta-agilitást, ami azt jelenti, hogy gyengébb titkosítási módszerekre válthatnak az régi eszközök támogatása érdekében. A WireGuard ezt a lehetőséget megszünteti, megakadályozva, hogy a támadók a VPN-t gyengébb zárrendszer használatára csalják. Ezenkívül a WireGuard alapértelmezés szerint lopakodó; ha egy jogosulatlan eszköz csomagot küld a szerverednek, a WireGuard egyszerűen nem válaszol. Ez láthatatlanná teszi a szervered a portokat kereső hackerek számára.
3. Be tudom állítani a WireGuardi-t Ubuntun Docker nélkül?
Igen, könnyedén beállíthatja közvetlenül a rendszeren anélkül, hogy Docker-konténereket használna. Valójában a közvetlen futtatás gyakran az előnyben részesített módszer Ubuntun, mivel a szoftver benne van az alapértelmezett Ubuntu szoftvertárakban. Általában csak az alábbi standard telepítési parancsokat kell futtatnia, amelyek közvetlenül az Ubuntu hivatalos forrásából húzzák le a szükséges szoftvert.
sudo apt update
sudo apt install wireguard4. Hogyan adhatok hozzá több WireGuard klienset (peer-t)?
A WireGuard peer-to-peer (pont-pont közötti) koncepciót használ, ami azt jelenti, hogy minden csatlakoztatott eszközt „társként” kezelnek. Több eszköz, például egy laptop, egy okostelefon és egy tablet hozzáadásához egyszerűen szerkeszteni kell a szerver konfigurációs fájlját (általában a /etc/wireguard/wg0.conf helyen található).
Minden új eszköznél adj hozzá egy új szövegrészt, amelyet [Peer] címkével látsz el. Ebben a blokkban be kell illesztened az adott eszköz Nyilvános Kulcsát, és egy egyedi belső IP-címet kell hozzárendelned (például 10.0.0.2 az első eszközhöz, 10.0.0.3 a másodikhoz, és így tovább). Kritikus fontosságú, hogy ezek a belső IP-címek ne ütközzenek egymással.
Íme egy egyszerű példa konfigurációs blokk:
[Interface]
# Server settings...
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <Server_Private_Key>
[Peer]
# Client 1 (Laptop)
PublicKey = <Laptop_Public_Key>
AllowedIPs = 10.0.0.2/32
[Peer]
# Client 2 (Phone)
PublicKey = <Phone_Public_Key>
AllowedIPs = 10.0.0.3/325. Mely portokat használ a WireGuard?
A WireGuard alapértelmezés szerint a 51820 UDP-portot használja. Szigorúan az UDP protokollra támaszkodik, mivel az gyorsabb az adatok alagúton keresztüli továbbítására, mint a TCP. A TCP minden elküldött adatcsomaghoz visszaigazolást igényel, ami jelentősen lassíthatja a VPN-kapcsolatot. Az UDP egyszerűen elküldi az adatokat, anélkül hogy várna a visszaigazolásra, ami tökéletes a WireGuard nagysebességű működéséhez. Az Ubuntu tűzfal (UFW) beállításakor kifejezetten engedélyezni kell a forgalmat ezen az UDP-porton, különben a kapcsolati kérések blokkolva lesznek, mielőtt elérnék a VPN-szoftvert.
6. Hogyan háríthatom el a WireGuard kapcsolati problémákat?
A WireGuard hibakeresése általában egyszerű, mivel kevesebb mozgó alkatrésze van. Ha nem tud csatlakozni, a következő ellenőrzési sorrendet kell követnie:
Először ellenőrizze a handshake állapotát a sudo wg show parancs futtatásával a szerverén. Ha a kapcsolat érvényes, látni fog egy sort, amelyen a latest handshake szerepel, amit egy idő követ (például „1 perce”). Ha ez a sor hiányzik, az eszközök egyáltalán nem kommunikálnak egymással. Ennek szinte mindig az az oka, hogy egy tűzfal blokkolja az UDP portot, vagy a nyilvános és privát kulcsok nincsenek összhangban.
Másodszor, ha a kapcsolat létrejön, de nem tudsz internetezni, a probléma valószínűleg az IP-továbbítás. Gondoskodnod kell arról, hogy az Ubuntu szerverednek engedélyezve legyen a forgalom továbbítása a VPN-ről az internetre. Ezt ellenőrizheted a /etc/sysctl.conf fájl megtekintésével, és annak biztosításával, hogy a net.ipv4.ip_forward=1 sor aktív legyen (ne legyen kikommentezve).
7. Támogatja a WireGuard az IPv6-ot Ubuntun?
Igen, a WireGuard kiváló IPv6-támogatással rendelkezik. Nagyon rugalmas, és különböző típusú forgalmakat képes becsomagolni (beágyazni). Például egy IPv6 kapcsolaton keresztül is hozzáférhetsz egy kizárólag IPv4-es weboldalhoz, vagy fordítva. Ehhez egyszerűen csak a konfigurációs fájlodba kell beillesztened a vesszővel elválasztott IPv6-címeket az alapértelmezett IPv4-címek mellé. Ezeket mind a Address mezőbe (a szerver saját IP-címéhez), mind az AllowedIPs mezőbe (a kliens IP-címekhez) hozzá kell adnod.
8. Hogyan tudom engedélyezni a WireGuard automatikus indítását a rendszerindításkor?
Annak érdekében, hogy a VPN automatikusan bekapcsoljon, amikor újraindítod az Ubuntu szerveredet, a systemd használatára van szükség, amely a Linux rendszerkezelője. A enable parancsot használod arra, hogy a rendszer észlelje a konkrét konfigurációs fájlodat (pl. wg0) és betöltse azt a rendszerindulás során. Ez biztosítja, hogy ha a szervered frissítés miatt újraindul, a VPN kapcsolat visszatérjen online állapotba anélkül, hogy manuálisan kellene elindítanod.
sudo systemctl enable wg-quick@wg0Következtetés
Ebben a bemutatóban beállítottál egy WireGuard VPN-t egy Ubuntu szerveren, és csatlakoztattál egy klienst IPv4 és IPv6 használatával. A folyamat során konfiguráltad a kulcsokat, hozzárendelted a tunnel-címeket, és engedélyezted a szerveren a forgalom biztonságos irányítását, így egy jól működő, könnyen érthető és kezelhető VPN-t kaptál.
Az útmutató néhány gyakorlati részletet is tartalmazott, amelyek a VPN rendszeres használata során fontosak, például a kulcsok időbeli kezelése, az IPv6 és a dual-stack hálózatkezelés, valamint a megbízhatóság és a teljesítmény javítása MTU beállításokkal, keepalive-ekkel és DNS beállításokkal. Ezzel a tudással jól felkészültnek kell lenned arra, hogy a WireGuardot valós környezetben futtasd, vagy igény szerint alkalmazkodj a változó szükségletekhez.
Ha szeretnél többet megtudni a WireGuardról, beleértve a haladóbb alagutak konfigurálását, vagy a WireGuard használatát konténerekkel, látogasd meg a hivatalos WireGuard dokumentációt. További útmutatókért az Ubuntu rendszerek biztonságosabbá tételéhez, nézd meg a következő cikkeket:
- Hogyan állítsunk be tűzfalat UFW-vel Ubuntun
- UFW alapjai: Gyakori tűzfal szabályok és parancsok a Linux biztonsághoz
- VPC vs VPN: Melyik illik jobban a biztonságos hálózati igényeidhez?
- Hogyan állítsunk be és konfiguráljunk egy OpenVPN szervert Ubuntun
Köszönjük, hogy a Linux-Console.net közösséggel tanultál.
