Vilken komponent äger egentligen en OpenVPN-ruttgräns?

En profil med två hundra rutter fungerar på en maskin och installerar fyrtio på en annan. Motorn, integrationen som startar den och servern som matar den har var sitt ord, och var och en kan stoppa listan vid olika punkter. Läser man felet som en enda gräns hamnar man i fel fil. Mekanismen har tre steg, och steget som stoppade lämnar synliga spår när man vet vad man ska leta efter.

Tre steg, tre olika gränser

Först tolkar motorn alternativet och avgör om den här versionen förstår det. Sedan installerar integrationen det motorn rapporterar, och dess egen kod kan begränsa eller omforma listan. Till sist avgör servern hur många rutter den skickar till en viss identitet, innan något klientsteg ser någonting. Tre steg, tre tak, och bara ett av dem är talet i profilen.

Att höja ett tak gör ingenting för de andra. En avvisad skickad rutt kan vara ett policybeslut på servern, en överlappning som klienten löste, eller en installationsgräns som slängde överskottet. Var och en av dessa har en annan åtgärd.

Skilj de tre åt innan du mäter något. Ett parserfel namnger en token, en installationsgräns lämnar en kort rutttabell, och ett policybeslut lämnar ingenting alls. Spåren säger vilket steg du ska undersöka först.

Parsern talar först

Ett okänt alternativ misslyckas högljutt och tidigt, och feltexten namnger token. Det är det lättaste steget att känna igen: jämför det exakta meddelandet med den installerade motorversionen, för ett alternativ som lades till i en utgåva är okänt i den föregående. En profil kopierad från en nyare utrullning är den vanliga källan till den missanpassningen. Parsern ignorerar aldrig tyst ett direktiv som den inte känner igen.

Ett accepterat alternativ säger ingenting om resultatet. Tolkningen lyckas, och listan kan ändå kapas av installationen eller aldrig erbjudas av servern. Behandla en ren tolkning som tillstånd att fortsätta, inte som bevis.

Anteckna versionssträngen från binären som faktiskt kördes, inte från pakethanterarens bild av vad som är installerat. De två är oense oftare än väntat.

Installationen har sitt eget tak

Komponenten som äger aktiveringen kan vara ett NetworkManager-tillägg i stället för motorns binär, och den kan införa sin egen gräns innan någon tunnel finns. Dess redigerare kan visa ett fält som den körande motorn aldrig läser, eller läsa ett fält som redigeraren inte visar. Båda situationerna ser ut som ett klientfel utifrån. Ingen av dem åtgärdas genom att redigera profilen.

Räkna det som landade i stället för det som konfigurerades. Kommandot ip route show dev tun0 listar de installerade rutterna, och att jämföra det antalet med den skickade listan skiljer en kasserad rutt från en som aldrig skickades. Ett antal som stämmer med sändningen flyttar misstanken tillbaka till servern.

Ett skalhölje runt motorns binär för att tvinga fram ett större tal grumlar uppgraderingar och gör återställningen till gissning. Det döljer också den verkliga gränsen för alla som läser konfigurationen härnäst.

Servern avgör vad du erbjöds

Policyn per klient kan krympa listan innan den överförs. En klientspecifik fil kan lägga till rutter för en identitet, eller en gruppolicy kan utelämna dem, och klienten kan inte skilja en filtrerad rutt från en som aldrig definierades. Det är just den otydligheten som gör serverposten viktig. Begär den faktiska sändningslistan för den identiteten, inte mallen.

Jämför serverposten med den mottagna listan. Gapet mellan dem är politiklagret, och det är vanligtvis mindre än profilen antyder.

När designen tillåter det, sammanfatta angränsande nätverk och ta bort föråldrade poster. Färre och större rutter löser fler fall än ett högre tak.

Ändra talet på rätt ställe

Använd den dokumenterade inställningen för komponenten som faktiskt äger gränsen. Om fältet saknas i tillägget, kontrollera om tillägget är äldre än funktionen eller om en annan bakgrund äger rutterna. Dokumentera sedan versionerna för motorn, tillägget och servern bredvid det värde du valde. Nästa uppgradering öppnar frågan igen, och anteckningen är det som gör den besvarbar.

Testa igen efter varje uppgradering av någon av de tre. En gräns som höjts på rätt ställe flyttar sig ändå när komponenten som genomdriver den ändras. Versionsanteckningen är det enda som gör den flyttningen förutsägbar.