Anong mga kakayahan ng Linux ang kailangan ng iyong VPN process?

Ang isang VPN daemon ay nangangailangan ng mga pribilehiyadong operasyon sa network kahit na ang mga ordinaryong aplikasyon ay nagbubukas ng palabas na socket nang walang anumang pribilehiyo. Sa puwang na iyon nagsisimula ang karamihan ng mga pagkakamali sa kakayahan: may nakakita ng error sa pahintulot, ibinibigay ang buong set, at gumagana ang serbisyo dahil sa mga dahilang wala nang makapagpapaliwanag mamaya. Ang paglalakbay sa ibaba ay nagsisimula sa operasyong nabigo, iniuugnay ito sa isang awtoridad, at pagkatapos ay sinusuri ang konteksto kung saan talagang tumatakbo ang proseso. Ang pagtakbo bilang walang limitasyong root ay isang wastong sagot para sa ilang deployment, ngunit dapat itong maging desisyon at hindi default.

Magsimula sa operasyong nabigo

Basahin ang error bago magbasa ng tutorial. Ang «operasyon ay hindi pinapayagan» sa pagbabago ng interface, pagtanggi na buksan ang node ng device at pagkabigo ng bind sa mababang port ay tatlong magkakaibang problema na may tatlong magkakaibang pahintulot. Kung ang proseso ay nagsisimula at nabigo lamang sa unang pagbabago ng ruta, nagsasabi rin iyon na nagtagumpay na ang paglikha ng interface, na lubos na nagpapaliit sa sagot.

Kopyahin muli ang pagkabigo habang naka-stop ang serbisyo, pagkatapos ay simulan ito sa foreground sa ilalim ng parehong user kung pinapayagan ng implementasyon. Ang error na nakikita mo ay mas mabuti kaysa sa log line na kailangan mong hulaan, at ginagawang malinaw ang pagkakaiba ng problema sa kakayahan at ng pagtanggi ng SELinux o AppArmor.

Iugnay ang bawat operasyon sa isang awtoridad

Ang talahanayan ay panimulang mapa, hindi kapalit ng dokumentasyon ng implementasyon:

Ang dalawang hilera sa talahanayang iyon ang madalas pinagsasama-sama ng mga tao. Ang pagbukas ng /dev/net/tun ay tanong ng pahintulot sa file; ang paghingi sa kernel na i-configure ang binuksan mo ay tanong ng kakayahan. Ang pagbibigay ng CAP_NET_ADMIN ay hindi nag-aayos ng node ng device na hindi mabasa ng iyong service user, at ang pag-aayos ng node ay hindi nagbibigay sa iyo ng awtoridad sa ruta. Suriin ang pareho bago mo baguhin ang alinman.

Ang WireGuard sa kernel at mga programang tunnel sa user space ay wala ring magkaparehong pangangailangan. Ang landas ng kernel module ay nagko-configure ng umiiral na interface sa pamamagitan ng netlink, habang ang implementasyon sa user space ay maaaring mangailangan din ng device at, para sa ilang transport, ng raw socket.

Basahin ang konteksto: serbisyo, container o shell

Ang isang kakayahan sa network namespace ng host ay maaaring makaapekto nang higit pa kaysa sa parehong operasyon sa loob ng sadyang hiwalay na stack. Ang container runtime ay karaniwang nagsisimula sa pinababang set ng hangganan; ang pagdaragdag ng NET_ADMIN sa container na nagbabahagi ng network ng host ay mas malaking pahintulot kaysa sa pagdaragdag nito sa isang may sariling network namespace at walang host mount.

Para sa mga systemd unit, basahin ang aktwal na ipinapatupad at hindi ang tila sinasabi ng unit file: iniuulat ng systemctl show -p CapabilityBoundingSet -p AmbientCapabilities ang mga epektibong halaga, na maaaring itakda ng drop-in na nakalimutan mo. Humingi ng epektibong halaga, hindi kailanman ang nilalayon. Mahalaga ang ambient na kakayahan dahil ang serbisyong hindi root ay nawawalan ng kakayahan sa exec kung wala ang mga ito.

Gawing batayan ang sinusuportahang setup ng package o image. Huwag magdagdag ng pahintulot sa raw socket o privileged mode dahil lang inilista ito ng ibang tutorial para sa ibang tool; ang pangangatwiran na iyon ay walang naipapasa at nawawala sa iyo ang isolation na binayaran mo. Kung may pagdududa, huwag magbigay ng anuman at basahin ang mga tala ng implementasyon para sa eksaktong operasyong kailangan mo.

Pagmasdan kung ano ang nangyayari matapos bumaba ang mga pribilehiyo

Maraming daemon ay nagsisimula nang may pribilehiyo, nagko-configure ng interface, pagkatapos ay lumilipat sa user na walang pribilehiyo at pinapanatili ang tunnel. Mula sa puntong iyon hindi na makakapagdagdag ng ruta, makakapagsulat muli ng firewall rule o makakapagbukas ng bagong pribilehiyadong device ang proseso, na ayos lang hanggang sa kailanganin ng muling pagkonekta ang eksaktong iyon. Ang pagbasa ng file at pagpapatakbo ng hook sa ibang pagkakataon ay maaaring mabigo sa parehong dahilan.

Subukan ang buong lifecycle at hindi ang unang segundo: pagsisimula, pag-renew o muling pagkonekta, at paglilinis sa paghinto. Ang unang matagumpay na paglikha ng interface ay hindi nagpapatunay na ang bawat susunod na pribilehiyadong operasyon ay gagana pa, at ang pagkabigo ay karaniwang lumilitaw pagkalipas ng mga oras sa production.

Ang mga implementasyong nagpapanatili ng tunnel na bukas sa paglipat ng user ay karaniwang ipinares ito sa mga opsyon na panatilihin ang tunnel at mga key. Sa panig ng systemd, ang katumbas na tanong ay kung ang set ng kakayahan ng unit ay nakaligtas sa paglipat ng user na na-configure mo.

Itala ang ibinigay na pahintulot at ang dahilan

Isulat ang eksaktong pahintulot, ang operasyong pinapagana nito at ang error na inayos nito. Isang linya sa mga tala ng deployment — «CAP_NET_ADMIN sa network namespace ng unit, kailangan para sa mga pagbabago ng ruta pagkatapos ng muling pagkonekta» — ay sapat upang pigilan ang susunod na tao na palawakin muli ang pahintulot.

Pagkatapos ay basahin muli ang epektibong set pagkatapos ng bawat upgrade. Nagdaragdag ng feature ang mga vendor, binabago ng image ang mga default, at ang kakayahang hindi kailangan noong nakaraang taon ay maaaring maging kargada nang walang makapansin.