Unua lanĉo: registriĝo por floto de WireGuard-aparatoj

Unu bildo, unu ŝlosilo po tabulo kaj paŝo de rajtigo, kiu ne fidas la propran aserton de la aparato. Kvar etapoj de lanĉo ĝis konfirmita peer.

La tabulo lanĉiĝas el la komuna bildo, ricevas DHCP-luon, kaj provizoskripto ruliĝas antaŭ ol iu ajn tuŝis la aparaton. Ie en tiu skripto ĝi devas akiri WireGuard-identecon, kiu apartenas al ĉi tiu tabulo kaj al neniu alia, rajtigi tiun identecon, kaj skribi profilon, kiun la enirejo akceptos. La bildo povas porti la klientan programaron, reviziitan ŝablonon kaj la publikan ŝlosilon de la enirejo. Kion ĝi neniam rajtas porti, estas unu privata ŝlosilo komuna al la tuta floto, ĉar tio igas unu ŝtelitan tabulon okazaĵo por la tuta floto. La suba ordo tenas la identecon loka kaj la rajtigon eksplicita.

Kion la bildo portas, kaj kion ne

Sendu la pakaĵon, la ŝablonon kun anstataŭigiloj, la publikan ŝlosilon de la enirejo kaj la registriĝan klienton. La ŝablono estas formo, ne sekreto: ĝi devus esti legebla de la provizouzanto kaj enhavi neniun ŝlosilmaterialon.

La privata ŝlosilo estas generata sur la aparato ĉe la unua lanĉo kaj neniam forlasas ĝin. Nur la publika duono vojaĝas, ene de registriĝpeto rajtigita per io alia ol la propra aserto de la aparato pri tio, kiu ĝi estas. Ĝuste tiu distingo malhelpas, ke ŝtelita tabulo fariĝu problemo por la tuta floto. Ĝi estas ankaŭ la parto, kiun plej multaj unualanĉaj skriptoj faras malĝuste.

Paŝo 1: generi la ŝlosilon loke

Rulu la generadon en protektita dosierujo post kiam la suba retkonekto estas aprobita kaj funkcias. La subŝelo tenas la umask-ŝanĝon loka por ĉi tiu operacio, kaj set -C rifuzas anstataŭigi ekzistantan dosieron:

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

WireGuard rapida komenco dokumentas la ŝlosilgeneran rilaton, sur kiu baziĝas ĉi tiuj du komandoj. Se la generado estas interrompita, lasu la aparaton neregistrita kaj lasu la laborfluon kongruigi la dosierojn. Ne forigu ekzistantan identecon nur por ke la skripto ruliĝu pure de la komenco.

Konservu la pritraktatan ŝlosilon tra ripetoj. Regeneri identecon post ĉiu provizora retfiasko estas kiel floto restas kun orfaj peer, kiujn neniu povas ligi al aparato.

Paŝo 2: rajtigi aparatan rikordon

Supozu, ke la inventaro nomas ĉi tiun tabulon device-042 kaj atribuas al ĝi 10.90.0.42/32. La registriĝservo devas kontroli, ke ĉi tiu petanto rajtas al tiu rikordo. Seria numero tajpita en formularon ne estas pruvo, ĉar seri-numeroj estas presitaj sur la ekstero de la skatolo.

Laŭaparata starta legitimilo, aprobo de operatoro aŭ aparataro-subtenata atesto povas firmigi la aserton. Protektu la integrecon de la peto kaj la aŭtentecon de la respondo, kaj ne anstataŭigu unu komunan VPN-sekreton per unu komuna fabrika legitimilo.

La registrita rikordo ligas la aparaton, ĝian publikan ŝlosilon, ĝian atribuitan adreson kaj ĝian permesitan administran rolon. WireGuard mem difinas neniun registriĝ-API, do tiu servo estas io, kion vi konstruas kaj funkciigas konscie.

Paŝo 3: skribi du kongruajn agordojn

La aparato bezonas profilon, kiu enkursigas la administrajn prefiksojn en la tunelon, kaj la enirejo bezonas peer-rikordon, kiu permesas nur la propran fontadreson de ĉi tiu aparato. Kun enirejo ĉe 10.90.0.1 kaj administra reto de 10.60.0.0/16, la aparata flanko aspektas tiel:

[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

La valoroj en krampoj estas anstataŭigiloj, ne ŝlosiloj. La keepalive gravas, kiam la tabulo staras malantaŭ NAT kaj devas resti atingebla; ĝi ne necesas ĉie, kaj aldoni ĝin el kutimo tenas radion veka sen kialo.

Sur la enirejo, la peer-rikordo estas intence mallarĝa:

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

Ne kopiu la celoliston de la aparato al la enireja peer. Sur la aparato tiu listo diras, kion enkursigi en la tunelon; sur la enirejo ĝi diras, kiujn fontadresojn ĉi tiu peer rajtas uzi, kaj tio estas malsamaj asertoj.

Plusendado, fajroŝirmilaj reguloj kaj la reenvojo al la administra reto ankoraŭ devas permesi la aprobitan aliron. Registrita peer ne estas permeso por ĉiu aplikaĵo malantaŭ ĝi.

Paŝo 4: firmigi registriĝon kiel vivciklan staton

Apliku la enirejan rikordon kaj la aparatan profilon per tiu, kiu posedas la koncernan agordon, poste marku la registriĝon kompleta nur kiam la celata identeco kaj adreso estas akceptitaj. Ripetoj devus kongruigi tiun saman rikordon anstataŭ atribui duan peer aŭ duan adreson.

Tenu restaŭran vojon por interrompita provizado, inkluzive la kazon, kiam la enirejo akceptis la ŝlosilon kaj la aparato neniam skribis sian profilon.

Kiam tabulo estas anstataŭigita aŭ elservigita, forigu ĝian publikan ŝlosilon kaj ĝian rajtigon kune. Nova ŝlosilo estas intenca re-registriĝa okazaĵo, ne kromefiko de re-bildigo. Ordo de laboro: generi loke, rajtigi kontraŭ la inventaro, skribi ambaŭ flankojn, firmigi la staton, poste testi unu administran peton tra la tunelo.

Rilataj artikoloj