ആദ്യ ബൂട്ട്: WireGuard ഉപകരണങ്ങളുടെ ഫ്ലീറ്റിനുള്ള രജിസ്ട്രേഷൻ

ബോർഡ് പൊതു ഇമേജിൽ നിന്ന് ബൂട്ട് ചെയ്യുന്നു, DHCP ലീസ് ലഭിക്കുന്നു, ആരും ഉപകരണം സ്പർശിക്കുന്നതിന് മുൻപേ പ്രൊവിഷനിംഗ് സ്ക്രിപ്റ്റ് പ്രവർത്തിക്കുന്നു. ആ സ്ക്രിപ്റ്റിൽ എവിടെയോ അത് ഈ ബോർഡിന് മാത്രം അവകാശപ്പെട്ടതും മറ്റൊന്നിനും അല്ലാത്തതുമായ WireGuard ഐഡന്റിറ്റി നേടണം, ആ ഐഡന്റിറ്റി അംഗീകരിപ്പിക്കണം, ഗേറ്റ്‌വേ സ്വീകരിക്കുന്ന പ്രൊഫൈൽ എഴുതണം. ഇമേജിന് ക്ലൈന്റ് സോഫ്റ്റ്‌വെയർ, പരിശോധിച്ച ടെംപ്ലേറ്റ്, ഗേറ്റ്‌വേയുടെ പൊതു കീ എന്നിവ വഹിക്കാം. ഒരിക്കലും വഹിക്കാൻ പാടില്ലാത്തത് മുഴുവൻ ഫ്ലീറ്റും പങ്കിടുന്ന ഒരു സ്വകാര്യ കീയാണ്, കാരണം അത് മോഷ്ടിക്കപ്പെട്ട ഒരു ബോർഡിനെ മുഴുവൻ ഫ്ലീറ്റിന്റെ സംഭവമാക്കുന്നു. താഴെയുള്ള ക്രമം ഐഡന്റിറ്റി പ്രാദേശികമായും അംഗീകാരം വ്യക്തമായും നിലനിർത്തുന്നു.

ഇമേജ് എന്ത് വഹിക്കുന്നു, എന്ത് വഹിക്കുന്നില്ല

പാക്കേജ്, പ്ലേസ്‌ഹോൾഡറുകളുള്ള ടെംപ്ലേറ്റ്, ഗേറ്റ്‌വേയുടെ പൊതു കീ, രജിസ്ട്രേഷൻ ക്ലൈന്റ് എന്നിവ അയയ്ക്കുക. ടെംപ്ലേറ്റ് ഒരു രൂപമാണ്, രഹസ്യമല്ല: അത് പ്രൊവിഷനിംഗ് ഉപയോക്താവിന് വായിക്കാവുന്നതും കീ വസ്തുക്കൾ അടങ്ങാത്തതുമായിരിക്കണം.

സ്വകാര്യ കീ ആദ്യ ബൂട്ടിൽ ഉപകരണത്തിൽ തന്നെ ഉത്പാദിപ്പിക്കപ്പെടുന്നു, ഒരിക്കലും അത് വിട്ടുപോകുന്നില്ല. പൊതു പകുതി മാത്രം യാത്ര ചെയ്യുന്നു, ഉപകരണം താൻ ആരാണെന്നുള്ള സ്വന്തം അവകാശവാദമല്ലാത്ത മറ്റെന്തോ ഉപയോഗിച്ച് അംഗീകരിക്കപ്പെടുന്ന രജിസ്ട്രേഷൻ അഭ്യർത്ഥനയ്ക്കുള്ളിൽ. ഈ വ്യത്യാസമാണ് മോഷ്ടിക്കപ്പെട്ട ബോർഡ് മുഴുവൻ ഫ്ലീറ്റിന്റെ പ്രശ്നമാകുന്നത് തടയുന്നത്. ഇതുതന്നെയാണ് മിക്ക ആദ്യ-ബൂട്ട് സ്ക്രിപ്റ്റുകളും തെറ്റായി ചെയ്യുന്ന ഭാഗം.

ഘട്ടം 1: കീ പ്രാദേശികമായി ഉത്പാദിപ്പിക്കുക

അടിസ്ഥാന നെറ്റ്‌വർക്ക് കണക്ഷൻ അംഗീകരിക്കപ്പെട്ട് പ്രവർത്തിച്ചതിന് ശേഷം സംരക്ഷിത ഡയറക്ടറിയിൽ ഉത്പാദനം നടത്തുക. സബ്‌ഷെൽ umask മാറ്റം ഈ പ്രവർത്തനത്തിൽ മാത്രം പ്രാദേശികമായി നിർത്തുന്നു, set -C നിലവിലുള്ള ഫയൽ മുകളിൽ എഴുതാൻ വിസമ്മതിക്കുന്നു:

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

WireGuard വേഗത്തിലുള്ള തുടക്കം ഈ രണ്ട് കമാൻഡുകളും ആശ്രയിക്കുന്ന കീ-ഉത്പാദന ബന്ധം രേഖപ്പെടുത്തുന്നു. ഉത്പാദനം തടസ്സപ്പെട്ടാൽ ഉപകരണം രജിസ്ട്രേഷൻ ഇല്ലാതെ വിടുക, വർക്ക്ഫ്ലോ ഫയലുകൾ യോജിപ്പിക്കട്ടെ. സ്ക്രിപ്റ്റ് തുടക്കം മുതൽ വൃത്തിയായി പ്രവർത്തിക്കാൻ വേണ്ടി മാത്രം നിലവിലുള്ള ഐഡന്റിറ്റി ഇല്ലാതാക്കരുത്.

വീണ്ടും ശ്രമങ്ങൾക്കിടയിൽ കാത്തിരിക്കുന്ന കീ സൂക്ഷിക്കുക. ഓരോ താൽക്കാലിക നെറ്റ്‌വർക്ക് പരാജയത്തിനും ശേഷം ഐഡന്റിറ്റി വീണ്ടും ഉത്പാദിപ്പിക്കുന്നതാണ് ഫ്ലീറ്റിൽ ആർക്കും ഉപകരണവുമായി ചേർക്കാനാകാത്ത അനാഥ peer-കൾ അവശേഷിക്കുന്ന വഴി.

ഘട്ടം 2: ഉപകരണ രേഖ അംഗീകരിക്കുക

ഇൻവെന്ററി ഈ ബോർഡിനെ device-042 എന്ന് വിളിക്കുകയും അതിന് 10.90.0.42/32 അനുവദിക്കുകയും ചെയ്യുന്നു എന്ന് കരുതുക. രജിസ്ട്രേഷൻ സേവനം ഈ അഭ്യർത്ഥകന് ആ രേഖയിൽ അവകാശമുണ്ടെന്ന് പരിശോധിക്കണം. ഫോമിൽ ടൈപ്പ് ചെയ്ത സീരിയൽ നമ്പർ തെളിവല്ല, കാരണം സീരിയൽ നമ്പറുകൾ പെട്ടിയുടെ പുറത്ത് അച്ചടിക്കുന്നു.

ഓരോ ഉപകരണത്തിനുമുള്ള ബൂട്ട്‌സ്ട്രാപ്പ് ക്രെഡൻഷ്യൽ, ഓപ്പറേറ്റർ അംഗീകാരം, അല്ലെങ്കിൽ ഹാർഡ്‌വെയർ പിന്തുണയുള്ള അറ്റസ്റ്റേഷൻ എന്നിവ അവകാശവാദം സ്ഥാപിക്കാം. അഭ്യർത്ഥനയുടെ അഖണ്ഡതയും പ്രതികരണത്തിന്റെ ആധികാരികതയും സംരക്ഷിക്കുക, ഒരു പങ്കിട്ട VPN രഹസ്യത്തെ ഒരു പങ്കിട്ട ഫാക്ടറി ക്രെഡൻഷ്യൽ കൊണ്ട് മാറ്റരുത്.

രജിസ്റ്റർ ചെയ്ത രേഖ ഉപകരണം, അതിന്റെ പൊതു കീ, അനുവദിച്ച വിലാസം, അനുവദിച്ച മാനേജ്‌മെന്റ് റോൾ എന്നിവ ബന്ധിക്കുന്നു. WireGuard തന്നെ ഒരു രജിസ്ട്രേഷൻ API നിർവചിക്കുന്നില്ല, അതിനാൽ ആ സേവനം നിങ്ങൾ ബോധപൂർവം നിർമ്മിച്ച് പ്രവർത്തിപ്പിക്കുന്ന ഒന്നാണ്.

ഘട്ടം 3: പൊരുത്തപ്പെടുന്ന രണ്ട് കോൺഫിഗറേഷനുകൾ എഴുതുക

ഉപകരണത്തിന് മാനേജ്‌മെന്റ് പ്രിഫിക്സുകൾ ടണലിലേക്ക് റൂട്ട് ചെയ്യുന്ന പ്രൊഫൈൽ വേണം, ഗേറ്റ്‌വേയ്ക്ക് ഈ ഉപകരണത്തിന്റെ സ്വന്തം ഉറവിട വിലാസം മാത്രം അനുവദിക്കുന്ന peer എൻട്രി വേണം. ഗേറ്റ്‌വേ 10.90.0.1-ൽ, മാനേജ്‌മെന്റ് നെറ്റ്‌വർക്ക് 10.60.0.0/16 ആയിരിക്കുമ്പോൾ ഉപകരണ വശം ഇങ്ങനെ കാണപ്പെടുന്നു:

[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

ബ്രാക്കറ്റിനുള്ളിലെ മൂല്യങ്ങൾ പ്ലേസ്‌ഹോൾഡറുകളാണ്, കീകളല്ല. ബോർഡ് NAT-ന് പിന്നിലിരിക്കുകയും എത്തിച്ചേരാവുന്നതായി തുടരേണ്ടതുമാകുമ്പോൾ keepalive പ്രധാനമാണ്; എല്ലായിടത്തും അത് ആവശ്യമില്ല, ശീലത്തിന്റെ പേരിൽ ചേർക്കുന്നത് കാരണമില്ലാതെ റേഡിയോ ഉണർത്തിനിർത്തുന്നു.

ഗേറ്റ്‌വേയിൽ, peer എൻട്രി ബോധപൂർവം ഇടുങ്ങിയതാണ്:

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

ഉപകരണത്തിന്റെ ലക്ഷ്യസ്ഥാന പട്ടിക ഗേറ്റ്‌വേ peer-ലേക്ക് പകർത്തരുത്. ഉപകരണത്തിൽ ആ പട്ടിക ടണലിലേക്ക് എന്ത് റൂട്ട് ചെയ്യണമെന്ന് പറയുന്നു; ഗേറ്റ്‌വേയിൽ അത് ഈ peer ഏത് ഉറവിട വിലാസങ്ങൾ ഉപയോഗിക്കാമെന്ന് പറയുന്നു, ഇവ വ്യത്യസ്ത പ്രസ്താവനകളാണ്.

ഫോർവേഡിംഗ്, ഫയർവാൾ നിയമങ്ങൾ, മാനേജ്‌മെന്റ് നെറ്റ്‌വർക്കിലേക്കുള്ള മടക്കപ്പാത എന്നിവ ഇപ്പോഴും അംഗീകരിച്ച പ്രവേശനം അനുവദിക്കണം. രജിസ്റ്റർ ചെയ്ത peer അതിന് പിന്നിലുള്ള ഓരോ ആപ്ലിക്കേഷനുമുള്ള അനുമതിയല്ല.

ഘട്ടം 4: രജിസ്ട്രേഷൻ ജീവിതചക്ര അവസ്ഥയായി സ്ഥിരീകരിക്കുക

ഓരോ കോൺഫിഗറേഷന്റെയും ഉടമയിലൂടെ ഗേറ്റ്‌വേ രേഖയും ഉപകരണ പ്രൊഫൈലും പ്രയോഗിക്കുക, തുടർന്ന് ഉദ്ദേശിച്ച ഐഡന്റിറ്റിയും വിലാസവും സ്വീകരിക്കപ്പെടുമ്പോൾ മാത്രം രജിസ്ട്രേഷൻ പൂർത്തിയായി അടയാളപ്പെടുത്തുക. വീണ്ടും ശ്രമങ്ങൾ രണ്ടാം peer അല്ലെങ്കിൽ രണ്ടാം വിലാസം അനുവദിക്കുന്നതിനുപകരം അതേ രേഖ യോജിപ്പിക്കണം.

തടസ്സപ്പെട്ട പ്രൊവിഷനിംഗിനായി വീണ്ടെടുപ്പ് പാത സൂക്ഷിക്കുക, ഗേറ്റ്‌വേ കീ സ്വീകരിച്ചു എന്നാൽ ഉപകരണം ഒരിക്കലും പ്രൊഫൈൽ എഴുതിയില്ല എന്ന സന്ദർഭവും ഉൾപ്പെടെ.

ബോർഡ് മാറ്റുകയോ വിരമിക്കുകയോ ചെയ്യുമ്പോൾ അതിന്റെ പൊതു കീയും അംഗീകാരവും ഒരുമിച്ച് നീക്കം ചെയ്യുക. പുതിയ കീ ബോധപൂർവമുള്ള പുനർരജിസ്ട്രേഷൻ സംഭവമാണ്, റീഇമേജിന്റെ പാർശ്വഫലമല്ല. പ്രവർത്തന ക്രമം: പ്രാദേശികമായി ഉത്പാദിപ്പിക്കുക, ഇൻവെന്ററിക്കെതിരെ അംഗീകരിക്കുക, ഇരു വശവും എഴുതുക, അവസ്ഥ സ്ഥിരീകരിക്കുക, തുടർന്ന് ടണലിലൂടെ ഒരു മാനേജ്‌മെന്റ് അഭ്യർത്ഥന പരിശോധിക്കുക.