Fallstudie 01 — VPN & Routing
VPN:et som slumpmässigt slutade fungera — och ingen visste varför
Slumpmässiga bortkopplingar, inga tydliga loggar, leverantörssupport hittade inget fel. Den verkliga orsaken var tre separata faktorer som bara blev kritiska i kombination.
Situation
VPN på plats, modern brandvägg, inga uppenbara fel. Ändå kopplades användare bort ständigt och utan förvarning. Loggarna visade inget tydligt fel. Leverantörssupport hittade ingenting. Problemet kvarstod under veckor av försök till åtgärder.
Kunden hade specifikt investerat i aktuell brandväggshårdvara för att förbättra VPN-stabiliteten. Bortkopplingarna fortsatte ändå. Ökande frustration — bland slutanvändare och intern IT — skapade press att byta ut utrustning som kanske inte alls var problemet.
Vad som faktiskt pågick
Undersökningen avslöjade tre separata problem som opererade samtidigt. Vart och ett var hanterbart på egen hand. Tillsammans skapade de ett felmönster som verkade slumpmässigt utifrån men var strukturellt deterministiskt.
- Asymmetrisk routing — inkonsistenta trafikvägar beroende på last och tajming innebar att returpaket tog andra vägar än utgående paket
- MTU-felmatchningar som orsakade tyst paketfragmentering mitt i sessioner — paket förkastades tyst istället för att fragmenteras korrekt
- Brandväggens sessionstabeller bröt ihop under specifika trafikförhållanden — stateful inspection tappade koll på etablerade sessioner under last
- Varje faktor enskilt ofarlig — tillsammans skapade de systemisk instabilitet som verkade slumpmässig utifrån
Problemet med asymmetrisk routing var särskilt subtilt. Under låg last följde paket typiskt sett konsistenta vägar. Under högre last förändrades routningsbesluten — och brandväggen, konstruerad för stateful inspection, tappade koll på etablerade sessioner när returtrafik anlände på ett oväntat gränssnitt.
Varför standarddiagnostik missade det
Varje enskild komponent klarade sin egen diagnostik. Brandväggen rapporterade friska sessionstabeller. Routing såg korrekt ut från vilken punkt som helst i topologin. MTU-problem var inte synliga i genomsnittlig paketanalys eftersom fragmenteringen skedde tyst — paket förkastades utan att generera uppenbara fel.
Vad FM-NetSec Nordic gjorde
- Byggde om routinglogiken för att tvinga fram deterministiska trafikvägar — eliminerade de förhållanden under vilka asymmetrisk routing kunde uppstå
- Åtgärdade MTU- och MSS-hantering från ände till ände på alla relevanta gränssnitt — säkerställde korrekt fragmentering istället för tyst förkastning
- Stabiliserade brandväggens sessionsbeteende under varierande lastförhållanden — justerade sessionstabellsparametrar för att hantera de faktiska trafikmönstren
Resultat
- Noll slumpmässiga bortkopplingar efter åtgärd
- Supportärenden relaterade till VPN minskade drastiskt
- Förutsägbar, stabil anslutning mellan alla platser
"Om ditt VPN 'slumpmässigt fallerar' är det nästan aldrig VPN:et."
Hårdvaran var inte problemet. VPN-programvaran var inte problemet. Problemet låg i den omgivande infrastrukturen — i routningsbesluten, MTU-konfigurationen och det stateful brandväggsbeteendet under verklig last. Att byta ut utrustning hade inte förändrat någonting.
Frågor om detta fall
Vad orsakade VPN-frånkopplingarna?
Tre samtidiga problem: asymmetrisk routing som förändrades under last, en MTU/MSS-felmatchning som orsakade tysta paketförluster och stateful-brandväggsbeteende som tappade sessioner när returtrafik anlände på ett oväntat interface. Vart och ett var hanterbart separat – tillsammans skapade de ett felmönster som verkade slumpmässigt.
Varför missade standarddiagnostik problemet?
Varje komponent klarade sin egen diagnostik isolerat. Brandväggen rapporterade friska sessionstabeller. Routing såg korrekt ut från varje enskild punkt. MTU-problem var inte synliga i genomsnittlig paketanalys. Felmönstret blev synligt först genom samtidig analys över flera lager under verkliga trafikförhållanden.
Hade ett hårdvaruutbyte löst problemet?
Nej – och det hade inte förändrat något. Hårdvaran fungerade som designad. Problemet låg i den omgivande infrastrukturen: routinglogik, MTU-konfiguration och brandväggens sessionsspårning under asymmetriska trafikvägar.
Vad kan man lära av detta fall?
Flerfaktorproblem avslöjar sig sällan vid standarddiagnostik. Rätt tillvägagångssätt är metodisk analys över alla relevanta lager simultant – inte sekventiell eliminering av enskilda komponenter som var för sig verkar friska.
