Hvilken komponent ejer egentlig en OpenVPN-rutegrænse?
En rutegrænse kan tilhøre OpenVPN-motoren, NetworkManager-pluginet eller serveren. Navngiv ejeren, før du redigerer en profil eller hæver et tal.
En profil med to hundrede ruter virker på én maskine og installerer fyrre på en anden. Motoren, integrationen der starter den, og serveren der fodrer den har hver deres ord, og hver af dem kan stoppe listen på et forskelligt punkt. Læser man fejlen som én enkelt grænse, sendes man til den forkerte fil. Mekanismen har tre trin, og det trin, der stoppede, efterlader synlige spor, når man ved, hvad man skal lede efter.
Tre trin, tre forskellige grænser
Først tolker motoren indstillingen og afgør, om denne version forstår den. Derefter installerer integrationen det, motoren rapporterer, og dens egen kode kan begrænse eller omforme listen. Til sidst afgør serveren, hvor mange ruter den vil sende til en given identitet, før nogen klientfase ser noget. Tre trin, tre lofter, og kun ét af dem er tallet i profilen.
At hæve ét loft gør intet for de andre. En afvist sendt rute kan være en politikbeslutning på serveren, et overlap klienten har løst, eller en installationsgrænse, der kasserede overskuddet. Hver af dem har en anden løsning.
Skil de tre ad, før du måler noget. En parserfejl navngiver et symbol, en installationsgrænse efterlader en kort rutetabel, og en politikbeslutning efterlader slet intet. Sporene fortæller dig, hvilket trin du skal undersøge først.
| Stage | Who decides | What you can see |
|---|---|---|
| Parse | Client engine | An error naming the option |
| Install | Activation owner | A route count below the pushed count |
| Offer | Server policy | A route absent from the pushed list |
Parseren taler først
En ukendt indstilling fejler højlydt og tidligt, og fejlteksten navngiver symbolet. Det er det letteste trin at genkende: sammenlign den præcise meddelelse med den installerede motorversion, for en indstilling, der blev tilføjet i en udgivelse, er ukendt i den foregående. En profil kopieret fra en nyere udrulning er den sædvanlige kilde til den uoverensstemmelse. Parseren ignorerer aldrig lydløst en direktiv, den ikke genkender.
En accepteret indstilling siger intet om resultatet. Parsingen lykkes, og listen kan stadig blive trimmet af installationen eller aldrig udbudt af serveren. Behandl en ren parsing som tilladelse til at fortsætte, ikke som bevis.
Noter versionsstrengen fra den binære fil, der faktisk kørte, ikke fra pakkehåndteringsprogrammets forestilling om, hvad der er installeret. De to er uenige oftere, end man forventer.
Installationen har sit eget loft
Den komponent, der ejer aktiveringen, kan være et NetworkManager-plugin i stedet for motorens binære fil, og den kan påtvinge sin egen grænse, før der findes nogen tunnel. Dets editor kan vise et felt, som den kørende motor aldrig læser, eller læse et felt, som editoren ikke viser. Begge situationer ser ud som en klientfejl udefra. Ingen af dem rettes ved at redigere profilen.
Tæl, hvad der landede, i stedet for hvad der blev konfigureret. Kommandoen ip route show dev tun0 viser de installerede ruter, og at sammenligne det antal med den sendte liste skiller en kasseret rute fra en, der aldrig blev sendt. Et antal, der matcher afsendelsen, flytter mistanken tilbage til serveren.
En skalkappe omkring motorens binære fil for at fremtvinge et større tal slører opgraderinger og gør tilbagerulning til gætteri. Den skjuler også den reelle grænse for enhver, der læser konfigurationen næste gang.
Serveren afgør, hvad du blev tilbudt
Politik per klient kan mindske listen, før den overføres. En klientspecifik fil kan tilføje ruter for én identitet, eller en gruppepolitik kan udelade dem, og klienten kan ikke skelne en filtreret rute fra en, der aldrig blev defineret. Den uklarhed er grunden til, at serverposten betyder noget. Bed om den effektive sendeliste for den identitet, ikke om skabelonen.
Sammenlign serverposten med den modtagne liste. Gabet mellem dem er politiklaget, og det er sædvanligvis mindre, end profilen antyder.
Når designet tillader det, sammenfat tilstødende netværk og slet forældede poster. Færre og større ruter løser flere tilfælde end et højere loft.
Ret tallet på det rigtige sted
Brug den dokumenterede indstilling for den komponent, der faktisk ejer grænsen. Hvis feltet mangler i pluginet, så undersøg, om pluginet er ældre end funktionen, eller om en anden baggrund ejer ruterne. Dokumentér derefter motor-, plugin- og serverversionerne ved siden af den valgte værdi. Den næste opgradering åbner spørgsmålet igen, og noten er det, der gør det muligt at besvare det.
Test igen efter enhver opgradering af enhver af de tre. En grænse hævet det rigtige sted flytter sig stadig, når den komponent, der håndhæver den, ændres. Versionsnoten er det eneste, der gør den flytning forudsigelig.