Bør du droppe chroot eller kopiere iproute2 inn i fengselet?

Tjenesten starter, en klient assosierer, og det dukker aldri opp en rute på serversiden. Eller daemonen nekter å starte og nevner en kommando den ikke kunne kjøre. Begge utfallene følger de samme tre linjene, som vanligvis kopieres samlet fra en herdingsguide: bytt til en uprivilegert konto, slipp gruppen og endre filsystemets rot. Bare én av de tre skjuler filer, og bare én av dem fjerner rettigheten til å endre rutetabellen. Å skille dem er måten du lærer hvilken linje du egentlig vil ha.

Hva fengselet fjerner som daemonen fortsatt trenger

Rotbyttet skjer etter oppstart, så daemonen beholder alt den allerede har åpnet, og mister alt den ville åpne senere. Enhver helper som tilkoblingen kjører etter det punktet, må finnes inne i den nye roten, sammen med de delte bibliotekene den laster. Et fengsel bygget av en konfigurasjonsfil og et sertifikat har ingen av delene.

Å bytte til en uprivilegert konto er en egen begrensning. En prosess som har gitt opp rot, kan kanskje ikke endre ruter eller få et grensesnitt opp, selv når binærfilen ligger rett der, så de to feilene må diagnostiseres hver for seg.

Tre betingelser avgjør hvilken retting du trenger

Den første betingelsen er hvordan bygget ditt installerer ruter. Nyere OpenVPN utgivelser konfigurerer grensesnitt og rutetabell i prosessen, mens eldre pakker og egne oppsett lener seg på eksterne verktøy eller på up- og down-skript. Nevner loggen en kommando, er et eksternt verktøy involvert, og fengselet skjuler det. Viser loggen i stedet en tillatelsesfeil, er kontoen problemet.

Den andre er vedlikehold. Et fengsel med kopierte binærfiler må oppdateres hver gang pakken som leverer dem, oppgraderes, ellers etterlater den første oppgraderingen en ødelagt tunnel. Den tredje er om en bestemt kontroll faktisk krever en chroot; handler kravet egentlig om privilegieseparering, kan kontobytte alene oppfylle det.

Hva et fungerende fengsel må inneholde

Et fengsel som kjører kommandoer, trenger binærfilen, hvert bibliotek den lenker mot, og enhver enhetsnode som daemonen åpner sent. Kopier delene og test dem uten VPN i bildet:

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

Den første kommandoen lister avhengighetene, og det er den folk hopper over. En kopiert binærfil som ikke finner et bibliotek, feiler med en annen melding enn en manglende binærfil, og begge ser ut som en OpenVPN-feil når de leses fra klientsiden. Å kjøre kommandoen for hånd i fengselet gjenskaper feilen uten å starte tjenesten på nytt.

Kopier også konfigurasjonen, sertifikatene og en eventuell CRL inn i fengselet, for en fil som daemonen forventer å lese på nytt etter oppstart, blir ikke funnet når roten er endret. Noter hva du kopierte, siden neste oppgradering av nettverkspakken erstatter originalene og lar fengselet stå på den gamle kopien.

Krympe herdingen i stedet

Hvis fengselet bare finnes fordi en guide sa det, er det et forsvarlig utfall å fjerne den ene linjen og beholde kontobegrensningene. Daemonen beholder filsystemvisningen sin og blir kvitt problemet, og privilegiefallet fjerner fortsatt rot fra den langlivede prosessen.

Skriv ned hva som står igjen, og hvorfor. En konfigurasjon som stille mistet en kontroll uten et notat, er hvordan herding driver, og neste revisjon spør hvorfor linjen forsvant.

Bisektér de tre linjene før du velger

Kopier konfigurasjonen, slå av alle tre direktivene og bekreft at en klient kobler til og at de forventede rutene dukker opp. Slå så på bare kontolinjene, deretter chroot alene. Trinnet der tunnelen bryter, peker ut grensen, og du slipper å bygge om et fengsel som aldri var årsaken.

Når det ruter igjen, kjør én klientsesjon med høyere verbosity og les linjen som nevner kommandoen eller den mislykkede tillatelsen. Den linjen er verdt mer enn tidsavbruddet klienten til slutt rapporterer.