Hvilke programvareroller trenger en skjermløs OpenVPN-gateway
En liten OpenVPN-gateway trenger en bevisst tunneltjeneste og en administrasjonsvei, ikke hver valgfrie serverrolle. Skill tunnelen fra SSH og PKI.
En maskin som er viet til en OpenVPN-gateway, trenger en støttet serverinstallasjon og programvaren for oppgavene den faktisk utfører. En installasjonsmeny som tilbyr SSH, webhosting og andre serverroller er ikke en liste over forutsetninger for OpenVPN. En utrulling uten skjerm er helt rimelig. Det viktige er å skille tre oppgaver: å bære tunnelen, å administrere verten og å utstede legitimasjon.
Her er inventarrekkefølgen jeg bruker, med kontrollen som lukker hvert trinn.
1. Gi tunneltjenesten sin egen pakke og profil
Ubuntus OpenVPN-serverveiledning bruker distribusjonens openvpn-pakke med en kommandolinje og en tjenestekonfigurasjon. Den samme pakken tjener som Linux-klient, og konfigurasjonen velger rollen.
Det betyr at installasjon av en klient-GUI ikke er det som gjør verten til en server, og fjerning av den er ikke det som gjør den skjermløs. Noter hvilken profil den kjørende instansen leser, fordi en ekstra konfigurasjonsfil i samme katalog kan lastes uten at noen merker det, og daemonen rapporterer suksess i begge tilfeller. Når det finnes to profiler, avgjør tjenestestyringen hvilken som vinner, og den avgjørelsen hører hjemme i notatene dine og ikke i en gjetning.
2. Bestem administrasjonsveien før tunnelen
OpenSSH kommer fra en egen openssh-server-pakke og kjører som sin egen tjeneste. Det er nyttig når en administrator skal nå maskinen over SSH, men OpenVPN trenger ikke en SSH-server for å utveksle VPN-pakker. En lokal konsoll eller en godkjent plattformadministrasjonskanal er en annen gyldig vei. Bestem hvilken du stoler på før du endrer ruting eller filtrering, fordi en ny tunnel aldri bør være den eneste utestete måten å reparere seg selv på.
3. Utsted legitimasjon fra den godkjente eieren
Ubuntu-eksempelet installerer easy-rsa ved siden av OpenVPN for å bygge en liten PKI, noe som er en rolle for utstedelse av legitimasjon og ikke en kjørende tunneltjeneste. Hvis organisasjonen allerede har en godkjent utstedelsesprosess, bruk den i stedet for å opprette en urelatert CA fordi en veiledning inneholder en. Hold gatewayens egen private nøkkel og sertifikat atskilt fra CA-signeringsnøkkelen, og velg signerings- og sikkerhetskopisted bevisst. Kopiering av hver PKI-fil til hver vert er ikke et programvarekrav.
4. La skrivebordsprogramtillegg bli på skrivebordene
En NetworkManager-redigerer eller et importtillegg har en hensikt på en maskin som bruker den arbeidsflyten. Det er ikke en ekstra serverfunksjon som trengs fordi gatewayen snakker OpenVPN.
Velg én eier av tilkoblingen, og ikke start en andre, skrivebordsstyrt kopi av samme profil.
5. Godta gatewayen med en ekte klient
Færre pakker er ikke en ferdig gateway. Serveren trenger fortsatt en godkjent lytter, identiteter, ruter, videresending der det trengs, en smal brannmurpolicy og den tiltenkte returveien. Skriv ned hvor loggene dens vises og hvordan oppdateringer brukes, fordi de to svarene avgjør hvordan en feil diagnostiseres senere.
Et design med internettutgang og et design med tilgang til et privat nettverk har ulike krav til videresending, så bestem hvilket du bygger før du åpner noe. Start én godkjent klient og kontroller den tiltenkte ressursen i stedet for tunnelindikatoren. Start deretter tjenesten på nytt på en kontrollert måte og bekreft oppstartsveien uten tilsyn, fordi en gateway som bare kommer opp mens noen ser på, ennå ikke er rullet ut.