OpenVPN konfigurēšana LXC konteinerā
OpenVPN izvietošana LXC konteinerā ir populārs risinājums situācijās, kad nepieciešams izolēts VPN serviss bez pilnas atsevišķas virtuālās mašīnas. Šāda pieeja ļauj samazināt resursu patēriņu, saglabāt elastīgu pārvaldību un vienlaikus atdalīt VPN funkciju no pārējās Linux vides. Tā ir īpaši noderīga, ja vienā hosta sistēmā darbojas vairāki servisi un administrators vēlas tīru, prognozējamu un viegli uzturamu VPN mezglu, kuram var piešķirt atsevišķus tīkla iestatījumus, ugunsmūra noteikumus un piekļuves kontroli.
Praksē OpenVPN LXC konteinerā visbiežāk tiek izmantots drošai attālinātai piekļuvei uzņēmuma resursiem, iekšējiem serveriem, failu glabātuvēm vai administrēšanas videi. Šādu modeli bieži veido uz virtuālajiem serveriem, jo tie dod pilnu kontroli pār Linux hostu, tīklu un konteineru konfigurāciju. Ja nepieciešama lielāka slodze vai vairāki vienlaikus strādājoši VPN lietotāji, infrastruktūra bieži tiek izvietota arī uz serveru īres risinājumiem. Sarežģītākos scenārijos, kur jāapvieno VPN, maršrutēšana, attālinātas darbavietas un individuālas piekļuves politikas, loģisks turpinājums ir individuālie risinājumi.
Pirms konfigurēšanas svarīgi saprast vienu būtisku niansi: OpenVPN konteinerā nav pilnīgi tas pats, kas OpenVPN klasiskā virtuālajā mašīnā. LXC konteineram nav pilna kernel līmeņa neatkarība, tāpēc tam jāpiešķir piekļuve vajadzīgajām kernel iespējām, piemēram, TUN ierīcei. Ja šis solis netiek izdarīts, OpenVPN var korekti uzinstalēties, bet nespēs palaist tun interfeisu un faktiski nepildīs savu uzdevumu. Lielākā daļa praktisko problēmu šajā tēmā saistās nevis ar pašas OpenVPN pakotnes uzstādīšanu, bet tieši ar LXC izolācijas robežām un hosta puses iestatījumiem.
Tipiskā darba secība ir šāda: vispirms sagatavot pašu LXC konteineru, pēc tam pārliecināties, ka tam ir atļauta TUN/TAP izmantošana, tad uzstādīt OpenVPN un nepieciešamos rīkus, pēc tam sakārtot sertifikātus vai atslēgas, servera konfigurāciju, IP forwarding un NAT vai maršrutēšanu. Tikai pēc tam var testēt klientu pieslēgšanos. Ja šie soļi tiek ievēroti pareizā secībā, ieviešana ir daudz prognozējamāka un kļūdu novēršana kļūst vienkāršāka.
Pirmais praktiskais uzdevums ir pārliecināties, ka hosta pusē konteineram ir pieejama TUN ierīce. Atkarībā no LXC vai Proxmox konfigurācijas tas parasti nozīmē konteineram atļaut attiecīgo device piekļuvi un, ja vajag, papildināt konfigurācijas failu ar mount un cgroup noteikumiem. Tieši šis posms bieži nosaka, vai OpenVPN vispār spēs startēt.
# Piemēra LXC konfigurācijas rindas lxc.cgroup.devices.allow = c 10:200 rwm lxc.mount.entry = /dev/net/tun dev/net/tun none bind,create=file
Pēc tam konteinerā var uzstādīt pašas OpenVPN pakotnes. Daudzās Debian vai Ubuntu bāzētās LXC vidēs pietiek ar standarta pakotņu pārvaldnieku. Vienlaikus noder arī easy-rsa, ja plānots lokāli veidot sertifikātu infrastruktūru. Ja sertifikāti jau ir sagatavoti citur, šis solis var būt vieglāks, jo konteinerā būs jāievieto tikai gatavie servera faili.
apt update apt install -y openvpn easy-rsa iproute2 iptables
Nākamais svarīgais solis ir servera sertifikātu un atslēgu sagatavošana. OpenVPN var darboties ar klasisku TLS modeli, kur ir CA, servera sertifikāts, servera privātā atslēga un klientu sertifikāti. Mazākām vidēm tas joprojām ir ļoti uzticams un pārskatāms risinājums. Ja sertifikāti tiek ģenerēti ārpus konteinera, konteinerā tie jāievieto droši un ar korektām failu atļaujām. Privātās atslēgas nekad nevajag glabāt pasaules lasāmās mapēs vai kopēt pa nedrošiem kanāliem.
# Piemēra faili /etc/openvpn/server/ca.crt /etc/openvpn/server/server.crt /etc/openvpn/server/server.key /etc/openvpn/server/dh.pem /etc/openvpn/server/ta.key
Servera konfigurācijas fails ir vieta, kur nosaka galveno OpenVPN darbības loģiku: ports, protokols, tun tips, sertifikātu ceļi, piešķirtais VPN tīkls, DNS push iestatījumi un maršrutēšana. Nelielā vidē bieži izmanto UDP un atsevišķu privāto VPN tīklu, piemēram, 10.8.0.0/24. Labi ir uzreiz izvēlēties tīklu, kas nekonfliktē ar klientu tipiskajiem mājas vai biroja tīkliem, jo vēlāk šādi konflikti rada ļoti nepatīkamas maršrutēšanas problēmas.
# /etc/openvpn/server/server.conf piemērs port 1194 proto udp dev tun ca /etc/openvpn/server/ca.crt cert /etc/openvpn/server/server.crt key /etc/openvpn/server/server.key dh /etc/openvpn/server/dh.pem tls-auth /etc/openvpn/server/ta.key 0 server 10.8.0.0 255.255.255.0 ifconfig-pool-persist /var/log/openvpn/ipp.txt push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 1.1.1.1" keepalive 10 120 user nobody group nogroup persist-key persist-tun cipher AES-256-GCM auth SHA256 verb 3
Tomēr ar OpenVPN konfigurācijas failu vien nepietiek. VPN serverim parasti jāspēj maršrutēt klientu trafiku uz ārējiem tīkliem vai iekšējiem uzņēmuma resursiem. Tas nozīmē, ka jāieslēdz IP forwarding un jāizveido NAT vai maršrutēšanas noteikumi. Ja šis posms tiek aizmirsts, klients var veiksmīgi pieslēgties VPN, bet nespēt piekļūt ne internetam, ne iekšējai infrastruktūrai. Tāpēc testēšana vienmēr jāveic ne tikai līmenī “savienojums izveidojās”, bet arī “datu plūsma tiešām strādā”.
# IP forwarding echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf sysctl -p # NAT piemērs iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
LXC konteineru vidē jāatceras, ka daļa tīkla loģikas var atrasties ne tikai konteinera iekšienē, bet arī hosta pusē. Ja hosts filtrē trafiku, izmanto bridge noteikumus vai papildus ugunsmūri, OpenVPN plūsma var tikt ietekmēta arī ārpus paša konteinera. Tas nozīmē, ka veiksmīga konfigurācija ir jāskatās kā kopējs hosta un konteinera projekts, nevis tikai viena server.conf faila uzrakstīšana.
Pēc konfigurācijas sagatavošanas servisu var palaist un pārbaudīt žurnālus. OpenVPN parasti diezgan labi pasaka, ja tam trūkst TUN ierīces, atslēgu, atļauju vai maršrutēšanas iespēju. Tas ir labs iemesls neignorēt systemd status un žurnālus. Daudzas kļūdas kļūst atrisināmas daudz ātrāk, ja administrators sāk ar žurnālu lasīšanu, nevis ar nejaušu konfigurācijas rindu pārrakstīšanu.
systemctl enable openvpn-server@server systemctl start openvpn-server@server systemctl status openvpn-server@server journalctl -u openvpn-server@server -n 50
Drošība, stabilitāte un biežākās kļūdas
Drošības ziņā OpenVPN LXC konteinerā jāuztver tāpat kā jebkurš cits publiski sasniedzams serviss. Jāierobežo piekļuve tikai nepieciešamajiem portiem, regulāri jāatjaunina pakotnes, droši jāglabā sertifikāti un jāparedz kārtība klientu atslēgu atsaukšanai. Ja uzņēmumā vairāki lietotāji izmanto vienu un to pašu klienta failu vai koplietotu atslēgu, tas ilgtermiņā kļūst grūti pārvaldāms un drošības ziņā vājš modelis. Daudz labāk ir katram lietotājam vai ierīcei izsniegt atsevišķu klienta profilu.
Stabilitātes ziņā biežākās problēmas ir TUN piekļuves trūkums, aizmirsts IP forwarding, nepareizi NAT noteikumi, konfliktējoši tīkli starp klientu un VPN vidi, kā arī hosta ugunsmūra noteikumi, kas bloķē trafiku. Vēl viena bieža kļūda ir uzskatīt, ka, ja OpenVPN process startējās, viss strādā. Patiesībā pareizais tests ir pārbaudīt, vai klients saņem adresi, vai sasniedz vajadzīgos resursus, vai DNS darbojas un vai trafiks plūst tieši tā, kā paredzēts.
Laba prakse ir dokumentēt izmantoto VPN tīklu, servera portu, protokolu, sertifikātu glabāšanas vietu, NAT noteikumus un hosta puses LXC iestatījumus. Tieši hosta konfigurācijas daļa bieži tiek aizmirsta, un pēc vairākiem mēnešiem neviens vairs neatceras, kāpēc konkrētais konteiners vispār var piekļūt /dev/net/tun. Šāda dokumentācija būtiski paātrina problēmu novēršanu un atvieglo migrāciju vai rezerves sistēmas izveidi.
Kopumā OpenVPN LXC konteinerā ir ļoti noderīgs risinājums, ja nepieciešams viegls, izolēts un pārvaldāms VPN serviss Linux vidē. Tas dod elastību un efektīvu resursu izmantošanu, bet prasa rūpīgu izpratni par tīklu, kernel ierobežojumiem, sertifikātiem un hosta konfigurāciju. Ja šīs daļas ir sakārtotas, rezultāts ir stabila un droša VPN vide, ko var uzturēt skaidri un prognozējami arī ilgtermiņā.