Hvilke softwareroller har en skærmløs OpenVPN-gateway brug for

En maskine, der er viet til en OpenVPN-gateway, har brug for en understøttet serverinstallation og softwaren til de opgaver, den faktisk udfører. En installationsmenu, der tilbyder SSH, webhosting og andre serverroller, er ikke en liste over forudsætninger for OpenVPN. En udrulning uden skærm er helt rimelig. Det vigtige er at adskille tre opgaver: at bære tunnelen, at administrere værten og at udstede legitimationsoplysninger.

Her er den inventarrækkefølge, jeg bruger, med den kontrol, der lukker hvert trin.

1. Giv tunneltjenesten sin egen pakke og profil

Ubuntus OpenVPN-servervejledning bruger distributionens openvpn-pakke med en kommandolinje og en tjenestekonfiguration. Den samme pakke tjener som Linux-klient, og konfigurationen vælger rollen.

Det betyder, at installation af en klient-GUI ikke er det, der gør værten til en server, og fjernelse af den er ikke det, der gør den skærmløs. Notér, hvilken profil den kørende instans læser, fordi en ekstra konfigurationsfil i samme mappe kan blive indlæst, uden at nogen bemærker det, og dæmonen rapporterer succes under alle omstændigheder. Når der findes to profiler, afgør tjenestestyringen, hvilken der vinder, og den beslutning hører hjemme i dine noter og ikke i et gæt.

2. Beslut administrationsvejen før tunnelen

OpenSSH kommer fra en separat openssh-server-pakke og kører som sin egen tjeneste. Det er nyttigt, når en administrator skal nå maskinen via SSH, men OpenVPN har ikke brug for en SSH-server for at udveksle VPN-pakker. En lokal konsol eller en godkendt platformshåndteringskanal er en anden gyldig vej. Beslut, hvilken du stoler på, før du ændrer routing eller filtrering, fordi en ny tunnel aldrig bør være den eneste uafprøvede måde at reparere sig selv på.

3. Udsted legitimationsoplysninger fra den godkendte ejer

Ubuntu-eksemplet installerer easy-rsa sammen med OpenVPN for at bygge en lille PKI, hvilket er en rolle til at udstede legitimationsoplysninger og ikke en kørende tunneltjeneste. Hvis organisationen allerede har en godkendt udstedelsesproces, så brug den i stedet for at oprette en urelateret CA, fordi en vejledning indeholder en. Hold gatewayens egen private nøgle og certifikat adskilt fra CA-signeringsnøglen, og vælg bevidst signerings- og backupstedet. Kopiering af hver PKI-fil til hver vært er ikke et softwarekrav.

4. Lad desktop-plugins blive på skrivebordene

En NetworkManager-editor eller et import-plugin har et formål på en maskine, der bruger den arbejdsgang. Det er ikke en ekstra serverfunktion, der er nødvendig, fordi gatewayen taler OpenVPN.

Vælg én ejer af forbindelsen, og start ikke en anden, skrivebordsstyret kopi af den samme profil.

5. Acceptér gatewayen med en rigtig klient

Færre pakker er ikke en færdig gateway. Serveren har stadig brug for en godkendt lytter, identiteter, ruter, videresendelse hvor det er nødvendigt, en snæver firewallpolitik og den tilsigtede returvej. Skriv ned, hvor dens logfiler vises, og hvordan opdateringer anvendes, fordi de to svar bestemmer, hvordan en fejl diagnosticeres senere.

Et design med internetudgang og et design med adgang til et privat netværk har forskellige krav til videresendelse, så beslut, hvilket du bygger, før du åbner noget. Start én godkendt klient, og kontrollér den tilsigtede ressource i stedet for tunnelindikatoren. Genstart derefter tjenesten på en kontrolleret måde, og bekræft opstartsvejen uden opsyn, fordi en gateway, der kun kommer op, mens nogen kigger, endnu ikke er udrullet.