Vilka programvaruroller en skärmlös OpenVPN-gateway behöver

En maskin som vigs åt en OpenVPN-gateway behöver en stödd serverinstallation och programvaran för de uppgifter den faktiskt utför. En installationsmeny som erbjuder SSH, webbhotell och andra serverroller är inte en lista över förutsättningar för OpenVPN. En driftsättning utan skärm är helt rimlig. Det viktiga är att skilja tre uppgifter: att bära tunneln, att administrera värden och att utfärda autentiseringsuppgifter.

Här är inventeringsordningen jag använder, med kontrollen som stänger varje steg.

1. Ge tunneltjänsten ett eget paket och en egen profil

Ubuntus OpenVPN-serverguide använder distributionens openvpn-paket med en kommandorad och en tjänstekonfiguration. Samma paket tjänar som Linux-klient, och konfigurationen väljer rollen.

Det betyder att installation av ett klient-GUI inte är det som gör värden till en server, och att ta bort det är inte det som gör den skärmlös. Notera vilken profil den körande instansen läser, eftersom en andra konfigurationsfil i samma katalog kan laddas utan att någon märker det, och daemonen rapporterar framgång i båda fallen. När det finns två profiler avgör tjänstehanteraren vilken som vinner, och det beslutet hör hemma i dina anteckningar och inte i en gissning.

2. Bestäm administrationsvägen före tunneln

OpenSSH kommer från ett separat openssh-server-paket och körs som sin egen tjänst. Det är användbart när en administratör ska nå maskinen över SSH, men OpenVPN behöver ingen SSH-server för att utbyta VPN-paket. En lokal konsol eller en godkänd plattformsadministrationskanal är en annan giltig väg. Bestäm vilken du förlitar dig på innan du ändrar routning eller filtrering, eftersom en ny tunnel aldrig bör vara det enda otestade sättet att reparera sig själv.

3. Utfärda autentiseringsuppgifter från den godkända ägaren

Ubuntu-exemplet installerar easy-rsa vid sidan av OpenVPN för att bygga en liten PKI, vilket är en roll för att utfärda autentiseringsuppgifter och inte en körande tunneltjänst. Om organisationen redan har en godkänd utfärdandeprocess, använd den i stället för att skapa en orelaterad CA bara för att en handledning innehåller en. Håll gatewayens egen privata nyckel och certifikat åtskilda från CA:ns signeringsnyckel, och välj plats för signering och säkerhetskopia medvetet. Att kopiera varje PKI-fil till varje värd är inget programvarukrav.

4. Låt skrivbordsinsticksprogram stanna på skrivborden

En NetworkManager-redigerare eller ett importinsticksprogram har en uppgift på en maskin som använder det arbetsflödet. Det är inte en extra serverfunktion som behövs för att gatewayen talar OpenVPN.

Välj en ägare för anslutningen, och starta inte en andra, skrivbordsstyrd kopia av samma profil.

5. Acceptera gatewayen med en riktig klient

Färre paket är inte en färdig gateway. Servern behöver fortfarande en godkänd lyssnare, identiteter, rutter, vidarebefordran där det behövs, en snäv brandväggspolicy och den avsedda returvägen. Skriv ned var dess loggar dyker upp och hur uppdateringar tillämpas, eftersom de två svaren avgör hur ett fel diagnostiseras senare.

En design med internetutgång och en design med åtkomst till ett privat nätverk har olika krav på vidarebefordran, så bestäm vilken du bygger innan du öppnar något. Starta en godkänd klient och kontrollera den avsedda resursen i stället för tunnelindikatorn. Starta sedan om tjänsten på ett kontrollerat sätt och bekräfta uppstartsvägen utan övervakning, eftersom en gateway som bara kommer upp medan någon tittar ännu inte är driftsatt.