Handa na ba ang WireGuard para sa produksyon? Ang sagot ay hindi ang protocol

Nagtatanong ang mga tao kung handa na ang WireGuard para sa produksyon, na parang tanong tungkol sa kriptograpiya at sa totoo ay tanong tungkol sa iyong kapaligiran. Sinuri na ang protocol sa loob ng maraming taon; kailangan pa ring sagutin ng deployment kung dinadala ng iyong mga network ang transport nito, sino ang nagpaparehistro at nag-aalis ng mga device, at sino ang nagtatapal ng pakete sa dalawang dulo. Nagkakaiba ang mga sagot na iyon sa pagitan ng dalawang server sa isang rack at isang libong laptop. Ang protocol ay pareho sa dalawang kaso; ang mga operasyon ay hindi.

Ang tanong sa likod ng tanong

Ang karaniwang gustong malaman ng mga tao ay kung makakapagcommit sila sa isang disenyo na hindi magpapahiya sa kanila sa loob ng anim na buwan. Tanong ito ng deployment na may apat na bahagi, at ang bawat bahagi ay maaaring mabigo nang hiwalay sa iba. Ang magagandang sagot sa tatlo ay hindi gumagawa ng para sa ikaapat.

Ang lumang babala tungkol sa isang snapshot bago ang release ay katotohanan tungkol sa snapshot na iyon, hindi permanenteng label sa bawat susunod na pakete. Gayundin, walang blog post ang makapagpapahayag na handa na ang iyong partikular na kombinasyon ng kernel, client, network at tauhan. Ang gawain ay gawing tahasan ang kombinasyon at suriin ito.

Ituring ang kahandaan bilang isang set ng mga tarangkahan na alinman ay nalalampasan mo o naitala mo bilang bukas. Ginagawa nitong checklist na may mga may-ari ang isang debate. Ginagawa rin nitong nakikita ang mga bukas na item ng sinumang nagsasang-ayon, sa halip na mailibing sa isang pilot report.

Unang tarangkahan: dapat dalhin ng ruta ang UDP

Dinadala ng WireGuard ang trapiko nito sa UDP at idinodokumento na hindi ito nag-aalok ng TCP mode o pagtatago ng trapiko. Ang disenyong umaasa sa pagmumukhang ordinaryong web traffic, o sa pagpapalit ng port para makakuha ng pag-uugaling TCP, ay nakatayo sa isang palagay na hindi sinusuportahan ng software.

Kaya ang unang tarangkahan ay isang survey, hindi isang pagsubok sa isang makina. Ilahad ang mga kapaligirang ina-access ng iyong mga user kung saan talaga sila nagtatrabaho, pagkatapos i-verify ang aprubadong ruta ng UDP sa bawat isa at magpasya kung ano ang mangyayari kapag wala ito.

Ang koneksyong gumagana mula sa opisina ay walang pinatutunayan tungkol sa network ng hotel, firewall ng campus o mobile carrier na iba ang paghawak sa UDP. Ang mga kapaligirang iyon ang dahilan kung bakit nabibigo ang mga deployment ng remote access pagkatapos ng matagumpay na pilot. Hindi mali ang pilot; makitid lang ito. Ang pagpapalawak nito ang tarangkahan.

Isulat din ang fallback. Kung ang sagot ay walang fallback, ito ay desisyong sulit na ipahayag nang maaga kaysa matuklasan habang nasa business trip.

Ikalawang tarangkahan: dapat may nagmamay-ari ng mga susi

Nagpapatotoo ang mga peer ng WireGuard gamit ang mga susi, isang pares bawat kalahok. Madaling ilarawan at mabigat sa operasyon, dahil wala sa protocol ang nagpaparehistro ng device, sumusubaybay kung sino ang may aling susi o nag-aalis ng access kapag nawala ang laptop. Ipinapalagay ng protocol na tama na ang mga susi, at ang pagiging tama ay trabaho ng iba.

Pangalanan ang taong nagpaparehistro ng device, ang record na nag-uugnay ng public key sa isang tao at device, at ang pamamaraan ng pag-alis. Kung ang pag-alis ay nakasalalay sa pag-alala kung saan inilagay ang mga kopya ng configuration file, hindi pa tapos ang pamamaraan.

Pumili ng isang device sa panahon ng pilot at alisin ito mula simula hanggang wakas. Ang pagsasanay na iyon ay nagbibigay ng mas kapaki-pakinabang na impormasyon kaysa sa isa pang pagsubok ng koneksyon, dahil inilalantad nito ang mga puwang sa iyong mga record.

Ikatlong tarangkahan: kailangan ng pakete ng tagapangalaga

Maaaring dumating ang WireGuard bilang implementasyon sa kernel, bilang pakete ng distribusyon o bilang client sa user space, at bawat isa ay may sariling landas ng update. Ang operasyonal na tanong ay alin ang pinapatakbo mo, saan ito galing at sino ang naglalapat ng security bulletin.

Gumagamit kami ng WireGuard ay hindi imbentaryo. Hindi nito tinutukoy ang paketeng dapat tapalan, ang bersyon sa gateway o ang taong makakapagbalik ng masamang update.

Ikaapat na tarangkahan: tanggapin ang workload, hindi ang handshake

Dapat ilarawan ng acceptance criteria kung ano ang ginagawa ng mga user. Ang maabot ang isang internal na aplikasyon, maresolba ang pribadong pangalan nito, matanggihan sa isang hindi awtorisadong destinasyon at masunod ang tinukoy na pag-uugali kapag down ang tunnel ay lahat napapansin, at ang matagumpay na handshake ay wala sa mga iyon.

Patakbuhin ang mga pagsusuring iyon sa pamamagitan ng pagbabago ng network, pag-restart ng device at maintenance window ng gateway, dahil sa mga paglilipat na iyon nasisira ang mga deployment.

Itabi ang ebidensya sa tabi ng criteria, kasama ang lokal na estado na lumikha nito:

wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1

Ang berdeng pagsubok sa tahimik na network na may isang laptop ay paunang obserbasyon. Hindi ito pag-aangkin tungkol sa pagiging maaasahan, at ang ituring itong ganoon ang paraan kung paano nagiging disenyong pinagkakatiwalaan ang isang disenyong gumagana.