Hvilken komponent eier egentlig en OpenVPN-rutegrense?

En profil med to hundre ruter virker på én maskin og installerer førti på en annen. Motoren, integrasjonen som starter den, og tjeneren som mater den har hver sitt ord, og hver av dem kan stoppe listen på et ulikt punkt. Leser man feilen som én enkelt grense, sendes man til feil fil. Mekanismen har tre trinn, og trinnet som stoppet etterlater synlige spor når man vet hva man skal se etter.

Tre trinn, tre ulike grenser

Først tolker motoren valget og avgjør om denne versjonen forstår det. Deretter installerer integrasjonen det motoren rapporterer, og dens egen kode kan begrense eller omforme listen. Til slutt avgjør tjeneren hvor mange ruter den vil sende til en gitt identitet, før noen klienttrinn ser noe som helst. Tre trinn, tre tak, og bare ett av dem er tallet i profilen.

Å heve ett tak gjør ingenting for de andre. En avvist sendt rute kan være et politikkvedtak på tjeneren, en overlapping klienten løste, eller en installasjonsgrense som kastet overskuddet. Hver av disse har en annen retting.

Skil de tre før du måler noe. En parserfeil navngir et symbol, en installasjonsgrense etterlater en kort rutetabell, og et politikkvedtak etterlater ingenting i det hele tatt. Sporene forteller deg hvilket trinn du skal undersøke først.

Parseren snakker først

Et ukjent valg feiler høyt og tidlig, og feilteksten navngir symbolet. Det er det letteste trinnet å kjenne igjen: sammenlign den nøyaktige meldingen med den installerte motorversjonen, for et valg som ble lagt til i en utgivelse er ukjent i den forrige. En profil kopiert fra en nyere utrulling er den vanlige kilden til denne uoverensstemmelsen. Parseren ignorerer aldri stille et direktiv den ikke kjenner igjen.

Et akseptert valg sier ingenting om resultatet. Parsingen lykkes, og listen kan likevel bli kuttet av installasjonen eller aldri tilbudt av tjeneren. Behandle en ren parsing som tillatelse til å fortsette, ikke som bevis.

Noter versjonsstrengen fra binæren som faktisk kjørte, ikke fra pakkebehandlerens forestilling om hva som er installert. De to er uenige oftere enn forventet.

Installasjonen har sitt eget tak

Komponenten som eier aktiveringen kan være en NetworkManager-utvidelse i stedet for motorens binær, og den kan påtvinge sin egen grense før noen tunnel finnes. Editoren kan vise et felt som den kjørende motoren aldri leser, eller lese et felt som editoren ikke viser. Begge situasjonene ser ut som en klientfeil utenfra. Ingen av dem rettes ved å redigere profilen.

Tell det som landet i stedet for det som ble konfigurert. Kommandoen ip route show dev tun0 viser de installerte rutene, og å sammenligne det tallet med den sendte listen skiller en forkastet rute fra en som aldri ble sendt. Et tall som stemmer med sendingen flytter mistanken tilbake til tjeneren.

En skallinnpakning rundt motorens binær for å tvinge fram et større tall slører oppgraderinger og gjør tilbakerulling til gjetning. Den skjuler også den virkelige grensen for alle som leser konfigurasjonen neste gang.

Tjeneren avgjør hva du ble tilbudt

Politikk per klient kan krympe listen før den overføres. En klientspesifikk fil kan legge til ruter for én identitet, eller en gruppepolitikk kan utelate dem, og klienten kan ikke skille en filtrert rute fra en som aldri ble definert. Nettopp denne uklarheten er grunnen til at tjenerposten betyr noe. Be om den effektive sendelisten for den identiteten, ikke malen.

Sammenlign tjenerposten med den mottatte listen. Gapet mellom dem er politikkaget, og det er vanligvis mindre enn profilen antyder.

Når designet tillater det, slå sammen tilstøtende nettverk og slett foreldede oppføringer. Færre og større ruter løser flere tilfeller enn et høyere tak.

Endre tallet på riktig sted

Bruk den dokumenterte innstillingen til komponenten som faktisk eier grensen. Hvis feltet mangler i utvidelsen, sjekk om utvidelsen er eldre enn funksjonen eller om en annen bakgrunn eier rutene. Deretter dokumenterer du versjonene til motoren, utvidelsen og tjeneren ved siden av verdien du valgte. Neste oppgradering åpner spørsmålet på nytt, og notatet er det som gjør det mulig å svare.

Test på nytt etter enhver oppgradering av hvilken som helst av de tre. En grense hevet på riktig sted flytter seg likevel når komponenten som håndhever den endres. Versjonsnotatet er det eneste som gjør den flyttingen forutsigbar.