Ska du släppa chrooten eller kopiera iproute2 in i fängelset?

Tjänsten startar, en klient associerar, och ingen rutt dyker någonsin upp på serversidan. Eller så vägrar daemonen att starta och namnger ett kommando den inte kunde köra. Båda utfallen följer samma tre rader, som oftast kopieras ihop från en härdningsguide: byt till ett oprivilegierat konto, släpp gruppen och ändra filsystemets root. Bara en av de tre gömmer filer, och bara en av dem tar bort behörigheten att ändra routingtabellen. Att dela upp dem är hur du lär dig vilken rad du egentligen vill ha.

Vad fängelset tar bort som daemonen fortfarande behöver

Rootbytet sker efter start, så daemonen behåller allt den redan har öppnat och förlorar allt den skulle öppna senare. Varje helper som anslutningen kör efter den punkten måste finnas inne i den nya rooten, tillsammans med de delade bibliotek den laddar. Ett fängelse byggt av en konfigurationsfil och ett certifikat har inget av dem.

Att byta till ett oprivilegierat konto är en separat begränsning. En process som har gett upp root kan kanske inte ändra rutter eller få ett gränssnitt att gå upp, även när binärfilen ligger precis där, så de två felen måste diagnostiseras var för sig.

Tre villkor avgör vilken åtgärd du behöver

Det första villkoret är hur din build installerar rutter. Nyare OpenVPN utgåvor konfigurerar gränssnitt och routingtabell i processen, medan äldre paket och egna uppsättningar lutar sig mot externa verktyg eller mot up- och down-skript. Namnger loggen ett kommando är ett externt verktyg inblandat och fängelset gömmer det. Visar loggen i stället ett behörighetsfel är kontot problemet.

Det andra är underhåll. Ett fängelse med kopierade binärfiler måste uppdateras varje gång paketet som tillhandahåller dem uppgraderas, annars lämnar den första uppgraderingen en trasig tunnel efter sig. Det tredje är om en viss kontroll verkligen kräver en chroot; handlar kravet egentligen om behörighetsseparering kan kontobytet ensamt räcka.

Vad ett fungerande fängelse måste innehålla

Ett fängelse som kör kommandon behöver binärfilen, varje bibliotek den länkar mot och varje enhetsnod som daemonen öppnar sent. Kopiera delarna och testa dem utan VPN i bilden:

ldd /usr/sbin/ip
chroot /etc/openvpn/jail /sbin/ip route show
chroot /etc/openvpn/jail /sbin/ip link set tun0 up

Det första kommandot listar beroendena, och det är det folk hoppar över. En kopierad binärfil som inte hittar ett bibliotek fallerar med ett annat meddelande än en saknad binärfil, och båda ser ut som ett OpenVPN-fel när de läses från klientsidan. Att köra kommandot för hand i fängelset återskapar felet utan att starta om tjänsten.

Kopiera också konfigurationen, certifikaten och en eventuell CRL in i fängelset, för en fil som daemonen väntar sig att läsa om efter start hittas inte när rooten har ändrats. Skriv upp vad du kopierade, eftersom nästa uppgradering av nätverkspaketet ersätter originalen och lämnar fängelset på den gamla kopian.

Krympa i stället härdningen

Om fängelset finns bara för att en guide sade det, är det ett försvarbart utfall att ta bort den enda raden och behålla kontobegränsningarna. Daemonen behåller sin filsystemsbild och blir av med problemet, och behörighetssänkningen tar fortfarande bort root från den långlivade processen.

Skriv ner vad som återstår, och varför. En konfiguration som tyst tappade en kontroll utan en anteckning är hur härdning driver, och nästa revision frågar varför raden försvann.

Bisektera de tre raderna innan du väljer

Kopiera konfigurationen, inaktivera alla tre direktiven och bekräfta att en klient ansluter och att de förväntade rutterna dyker upp. Aktivera sedan bara kontoraderna, därefter chrooten ensam. Steget där tunneln bryts pekar ut gränsen, och du slipper bygga om ett fängelse som aldrig var orsaken.

När det routar igen, kör en klientsession med högre verbosity och läs raden som namnger kommandot eller den misslyckade behörigheten. Den raden är värd mer än den timeout som klienten till slut rapporterar.