OpenVPN-apparatrute: konfigurasjonseier eller oppstartsskript?
En filialrute som overlever én omstart kan likevel forsvinne etter en lagring i GUI-et eller en fastvareoppdatering. Sammenlign den støttede konfigurasjonseieren med et patchskript.
Du legger til en filialrute, den virker, og så fjerner en fastvareoppdatering eller en lagring fra webgrensesnittet den. To rettelser ser like rimelige ut i det øyeblikket: å legge ruten i apparatets støttede konfigurasjonskilde, eller å føye den til den genererte filen fra et oppstartsskript. De oppfører seg likt i en uke og skiller lag ved den andre oppgraderingen. Denne artikkelen sammenligner hva hver av dem faktisk eier.
De to kandidatene eier forskjellige ting
Den støttede konfigurasjonskilden er alt apparatet behandler som inndata: et GUI-felt, en importert profil, en dokumentert mappe per klient, en innstillingsdatabase som administrasjonspakken leser. Den genererte server.conf er utdata. Å redigere utdata virker til generatoren kjører igjen, og det skjer ved lagring, ved omstart og ved oppgradering.
Skripttilnærmingen patcher den utdataen etter at generatoren er ferdig. Det er en legitim teknikk for et laboratorium, og det er feil standard for et filialkontor, fordi det gjør ruten avhengig av tekstmatch i stedet for et dokumentert felt.
| Question | Supported config source | Post-generation script |
|---|---|---|
| Survives a GUI save | Yes | Only if the save does not regenerate the file |
| Survives a package upgrade | Usually, when the field is documented | No guarantee; the wrapper can be replaced |
| Supportable by the vendor | Yes | No |
| Obvious to the next admin | Yes, it is in the UI | No, it lives in a wrapper |
Hva apparatet regenererer, og når
Administrasjonspakker holder vanligvis innstillinger i en database eller et sett med maler og genererer daemonkonfigurasjonen ved start. En lagring fra webgrensesnittet skriver ofte om hele filen i stedet for å patche én linje. Hvis endringen din levde i den filen, er den nå borte, og ingenting logger en advarsel, fordi fra apparatets synspunkt gikk ingenting tapt.
Oppstartsinnpakninger har en andre feilmodus. En grep etter en direktiv med bestemt avstand slutter å matche etter en malendring, og skriptet gjør stille ingenting. Verre, en fastvareoppdatering kan erstatte innpakningen med en ny versjon og ta patchen med seg. Da har du en rute som fantes i et år og forsvant under vedlikehold som ingen koblet til ruting.
Hva den støttede eieren må uttrykke
Et filialprefiks trenger tre utsagn, ikke ett. Klienten må lære ruten, serveren må vite hvilken autentisert klient som eier prefikset, og filialsiden må sende trafikken tilbake til tunneladressen den fikk. I OpenVPN-termer betyr det en pushet route, en samsvarende iroute bundet til klienten, og en returvei på den andre siden.
Det er her apparatets grensesnitt villeder. En avkrysningsboks merket «la klienter få tilgang til serverens LAN» beskriver trafikk mot serverens eget nettverk. Filialen din er motsatt retning: et nettverk bak én klient, tilgjengelig fra serversiden. Den samme etiketten betyr ikke støtte for det, og en gyldig direktiv i en fil er ikke et løfte om at pakken bevarer den.
Når det ikke finnes noen støttet kontroll
Noen ganger kan den installerte utgaven virkelig ikke uttrykke en peer-spesifikk rute. Da er de ærlige alternativene en annen gateway du kontrollerer, eller en støttet site-til-site-modus i begge ender. Begge endene må snakke den. En produktside som sier site-til-site gjør ikke en vilkårlig OpenVPN-profil utskiftbar med en annen protokolls tunnel, og å tvinge det paret gir vanligvis en halvtilsluttet tunnel som ser fin ut på en statusside.
Velg alternativet du kan beskrive i én setning til den som arver nettverket. Hvis svaret krever å nevne en skriptsti og et tekstmønster, er designet allerede skjørt.
Gjør intensjonen reviderbar
Registrer kontrakten utenfor apparatet: effektiv klientidentitet, prefiks, returgateway og det støttede feltet som leverer hver av dem. Eksporter konfigurasjonen gjennom den støttede mekanismen slik at en gjenoppbygging har en referanse, og verifiser tjenesten etter en gjentilkobling, en omstart og en oppgradering i stedet for bare etter endringen.
Sammenlign det genererte resultatet med den registreringen når noe bryter, i stedet for å gjenopprette en uforklart linje og håpe.OpenVPN 2.6-referansen er stedet for å bekrefte hvordan route og iroute samspiller før du krangler med et grensesnitt.
Sjekkliste for neste endring: navngi eieren, angi den tredelte kontrakten, eksporter intensjonen, og test på nytt etter apparatets egne livssyklushendelser i stedet for etter redigeringen din.