Statusfilen teller økter, ikke LAN-et bak dem

Noen spør hvor mange maskiner som er på VPN-en, og statusfilen legges fram som bevis. Den svarer på et smalere spørsmål: hvor mange økter som finnes i dette øyeblikksbildet, og hvilke virtuelle adresser serveren ruter. Gapet mellom de to spørsmålene er der de fleste rapporteringsfeilene bor, og å lukke det begynner med å lese filens egne overskrifter.

Hva øyeblikksbildet faktisk inneholder

Filen skrives med et intervall når statusutdata er konfigurert for den serverinstansen, så det er et periodisk bilde og ikke en direktestrøm. Seksjonene lister økter og intern rutetilstand hver for seg, og formatversjonen avgjør kolonneoppsettet.

status /run/openvpn/office.status 30
status-version 3

Versjon 3 skriver tabulatordelte felt med en overskriftsrad, mens eldre formater er annerledes og senere versjoner kan legge til felt. Les overskriften i stedet for å hardkode et kolonnenummer, fordi et skript som antar posisjoner brytes stille ved neste oppgradering.

Tell økter, ikke personer eller maskiner

Én nettstedstilkobling kan bære trafikk for flere autoriserte maskiner bak seg. Én person kan også holde mer enn én økt samtidig, fra en bærbar PC og en telefon. Ingen av mønstrene er synlige i tellingen, og derfor gir tilkoblede brukere bare mening når du definerer enheten. Spør hvilken enhet rapporten trenger før noen begynner å telle.

Hvis tallet betyr noe for lisensiering eller kapasitet, definer enheten i samme dokument som rapporten. En rapport som ikke sier om den teller økter, identiteter eller enheter, vil bli lest som den enheten leseren forventet.

Den ytre adressen er ikke en identifikator

Feltet for den reelle adressen er peer-adressen og porten slik serveren ser dem. Flere klienter bak én oversatt offentlig adresse deler den adressen, så gruppering etter den slår sammen urelaterte økter. Porten endres også mellom tilkoblinger, noe som gjør paret ubrukelig som stabil nøkkel. En rapport gruppert slik ser presis ut og er feil.

Bruk den effektive klientidentiteten til gruppering, og behandle adressen som en transportdetalj. Når to rader deler en identitet, betyr det vanligvis samtidige økter og ikke en duplikatpost.

Ruterader er ikke en vertsoversikt

En ruteoppføring kan navngi et subnett som én peer er ansvarlig for, og et subnett er ikke en liste over vertene sine. Serveren vet at den skal sende det området til en bestemt økt, og den aner ikke hvilke av maskinene som er slått på, autentisert i en applikasjon eller nyttige for noen. Rutertabellen beskriver tilgjengelighet, ikke belegg. Den forskjellen er hele grunnen til at en VPN ikke kan svare på et inventarspørsmål.

Flere rader kan også peke på samme peer, fordi et nettsted kan annonsere mer enn ett område. Å telle rader og kalle resultatet et enhetsantall overdriver utrullingen med en vilkårlig faktor.

Hvis kravet virkelig er en aktivainventar, bruk inventarprosessen som eier det nettverket. VPN-en kan identifisere hvilken peer som bærer en rute, og det er et annet faktum enn hvilke verter som finnes bak den.

Alder, tillatelser og en direkte visning

Ta vare på filens endringstid sammen med hvert svar. En server som stoppet for timer siden, lar sitt siste øyeblikksbilde bli stående, og en utdatert fil presentert som gjeldende er verre enn ingen rapport.

Katalogen må finnes og være skrivbar for kontoen tjenesten faktisk kjører som, noe som er lett å glemme etter en herdingsrunde. Filen inneholder vanligvis navn og adresser, så oppbevar den på et administrativt sted og ikke hvor som helst en webserver kan levere den. Kontroller tillatelsene fra tjenestekontoen, ikke fra skallet ditt. Et øyeblikksbilde som stille slutter å oppdateres, ser akkurat ut som et rolig nettverk.

For hendelsesdrevne behov, bruk det støttede administrasjonsgrensesnittet i stedet for å polle raskere. Behandle det grensesnittet som kontroll, ikke som målinger, og aldri eksponer det mot internett bare for å telle økter.