Első indítás: WireGuard-eszközök flottájának regisztrációja

Egy lemezkép, egy kulcs laponként, és egy engedélyezési lépés, amely nem bízik az eszköz saját állításában. Négy szakasz az indítástól a jóváhagyott peerig.

A lap a közös lemezképről indul, DHCP-bérletet kap, és egy előkészítő szkript fut, mielőtt bárki hozzányúlt volna az eszközhöz. Valahol abban a szkriptben olyan WireGuard-identitást kell szereznie, amely ehhez a laphoz tartozik és semmi máshoz, engedélyeztetnie kell ezt az identitást, és olyan profilt kell írnia, amelyet az átjáró elfogad. A lemezkép hordozhatja a kliensszoftvert, egy átnézett sablont és az átjáró nyilvános kulcsát. Amit soha nem hordozhat, az egyetlen privát kulcs, amelyet az egész flotta megoszt, mert ez egyetlen ellopott lapból az egész flottát érintő incidenst csinál. Az alábbi sorrend az identitást helyben, az engedélyezést pedig kifejezett szinten tartja.

Mit hordoz a lemezkép, és mit nem

Szállítsa a csomagot, a helyőrzőket tartalmazó sablont, az átjáró nyilvános kulcsát és a regisztrációs klienst. A sablon forma, nem titok: olvashatónak kell lennie az előkészítő felhasználó számára, és nem tartalmazhat kulcsanyagot.

A privát kulcs az eszközön generálódik az első indításkor, és soha nem hagyja el. Csak a nyilvános fele utazik, egy regisztrációs kérésen belül, amelyet más engedélyez, mint az eszköz saját állítása arról, hogy ki ő. Ez a különbségtétel az, ami megakadályozza, hogy egy ellopott lap az egész flotta problémájává váljon. És ez az a rész is, amelyet a legtöbb első indítási szkript elront.

1. lépés: a kulcs helyi generálása

Futtassa a generálást védett könyvtárban, miután az alapul szolgáló hálózati kapcsolat jóváhagyást kapott és működik. Az alhéj a umask módosítását erre a műveletre korlátozza, és a set -C megtagadja egy meglévő fájl felülírását:

(
    umask 077
    set -C
    wg genkey > /etc/wireguard/device.key &&
        wg pubkey < /etc/wireguard/device.key > /etc/wireguard/device.pub
)

WireGuard gyorsindítás dokumentálja azt a kulcsgenerálási kapcsolatot, amelyre ez a két parancs támaszkodik. Ha a generálás megszakad, hagyja az eszközt regisztrálatlanul, és hagyja, hogy a munkafolyamat összehangolja a fájlokat. Ne töröljön meglévő identitást csak azért, hogy a szkript elejétől tisztán lefusson.

Tartsa meg a függőben lévő kulcsot az újrapróbálkozások során. Az identitás újragenerálása minden ideiglenes hálózati hiba után az, amitől egy flotta árva peerekkel marad, amelyeket senki sem tud eszközhöz rendelni.

2. lépés: egy eszközrekord engedélyezése

Tegyük fel, hogy a leltár ezt a lapot device-042-nek nevezi, és 10.90.0.42/32-t rendel hozzá. A regisztrációs szolgáltatásnak ellenőriznie kell, hogy ez a kérelmező jogosult-e arra a rekordra. Az űrlapba beírt sorozatszám nem bizonyíték, mert a sorozatszámokat a doboz külsejére nyomtatják.

Eszközönkénti bootstrap-hitelesítő adat, üzemeltetői jóváhagyás vagy hardverrel támogatott attestation megalapozhatja az állítást. Védje a kérés integritását és a válasz hitelességét, és ne cseréljen ki egy közös VPN-titkot egy közös gyári hitelesítő adatra.

A regisztrált rekord összeköti az eszközt, annak nyilvános kulcsát, a hozzá rendelt címet és az engedélyezett kezelési szerepét. A WireGuard maga nem definiál regisztrációs API-t, tehát ez a szolgáltatás olyasmi, amit szándékosan épít és üzemeltet.

3. lépés: két egymáshoz illő konfiguráció írása

Az eszköznek olyan profilra van szüksége, amely a kezelési előtagokat az alagútba irányítja, az átjárónak pedig olyan peer-bejegyzésre, amely csak ennek az eszköznek a saját forráscímét engedi. Ha az átjáró 10.90.0.1-en, a kezelési hálózat pedig 10.60.0.0/16, az eszköz oldala így néz ki:

[Interface]
PrivateKey = <device-042 private key>
Address = 10.90.0.42/32

[Peer]
PublicKey = <trusted gateway public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.90.0.1/32, 10.60.0.0/16
PersistentKeepalive = 25

A szögletes zárójelben lévő értékek helyőrzők, nem kulcsok. A keepalive akkor számít, amikor a lap NAT mögött ül, és elérhetőnek kell maradnia; nem mindenhol szükséges, és szokásból hozzáadva ok nélkül ébren tart egy rádiót.

Az átjárón a peer-bejegyzés szándékosan szűk:

[Peer]
PublicKey = <device-042 public key>
AllowedIPs = 10.90.0.42/32

Ne másolja az eszköz célzottlistáját az átjáró peer-bejegyzésébe. Az eszközön ez a lista azt mondja, mit kell az alagútba irányítani; az átjárón azt mondja, mely forráscímeket használhat ez a peer, és ezek különböző állítások.

A továbbításnak, a tűzfal-szabályoknak és a kezelési hálózat felé vezető visszaútnak továbbra is engedélyeznie kell a jóváhagyott hozzáférést. Egy regisztrált peer nem engedély a mögötte lévő minden alkalmazásra.

4. lépés: a regisztráció életciklus-állapotként való rögzítése

Alkalmazza az átjáró rekordját és az eszközprofil azon keresztül, aki az adott konfigurációt birtokolja, majd csak akkor jelölje a regisztrációt befejezettnek, amikor a szándékolt identitás és cím elfogadásra kerül. Az újrapróbálkozásoknak ugyanazt a rekordot kell összehangolniuk, nem pedig második peert vagy második címet kiosztaniuk.

Tartson helyreállítási útvonalat a megszakadt előkészítéshez, beleértve azt az esetet is, amikor az átjáró elfogadta a kulcsot, és az eszköz soha nem írta meg a profilját.

Amikor egy lapot cserélnek vagy kivonnak a használatból, távolítsa el a nyilvános kulcsát és az engedélyezését együtt. Az új kulcs szándékos újraregisztrációs esemény, nem a lemezkép újraírásának mellékhatása. A munka sorrendje: helyben generálni, a leltárral szemben engedélyezni, mindkét oldalt megírni, rögzíteni az állapotot, majd egy kezelési kérést tesztelni az alagúton.

Kapcsolódó cikkek