Hvorfor ruter med lik kostnad gjør VPN-feil vanskelige å se
Når flere tunneler deler samme kostnad, kan hver strøm velge en annen. En vellykket ping sier ingenting om veien applikasjonen din faktisk bruker.
En bruker melder at den interne applikasjonen virker fra én maskin og feiler fra en annen, mens pinget du kjører fra gatewayen lykkes i begge tilfeller. Med flere tunneler med lik kostnad er ikke det en selvmotsigelse. Hver strøm plasseres på sitt eget neste hopp, så testen din og brukerens sesjon bruker kanskje bare forskjellige veier. Gjennomgangen nedenfor gjenskaper valget før noe endres.
Én ping, flere mulige veier
Når en rute har mer enn ett neste hopp til samme kostnad, må ruteren velge ett per pakke. De fleste implementasjoner hasher felter fra pakken, typisk kilde- og måladressene sammen med protokollen og portene, slik at svar blir værende på samme vei. Ulike applikasjoner, eller til og med ulike tilkoblinger fra én applikasjon, gir ulike hasher.
Derfor beviser en diagnose fra gatewayen så lite. Gatewayens egen test har sine egne adresser og porter, og dermed sin egen hash. Den kan lande på den sunne tunnelen mens brukeren fortsetter å lande på den ødelagte.
Hvordan plattformen velger et neste hopp
Gjenskap valget i stedet for å gjette det. Spør kjernen hvilken rute den ville brukt for samme kilde og mål som den feilende sesjonen. Det oppslaget omfatter felter som et vanlig mål-oppslag ignorerer. Kjør det også fra en fungerende klient, og sammenlign de to svarene:
ip route get 10.20.5.7 from 10.20.0.14Nyere iproute2-utgivelser godtar også protokollen og målporten, noe som betyr noe når hashen omfatter dem. Sammenlign den utskriften med det samme oppslaget fra en fungerende klient, og forskjellen er beviset du manglet.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
Følg den feilende strømmen, ikke rutetabellen
Rutetabellen viser begge tunnelene og ser per definisjon riktig ut. Spørsmålet er hva hver tunnel gjør med pakken når den er valgt. Bekreft at begge bærer de samme beskyttede prefiksene, samme videresendingstillatelse og en returvei som når samme klient.
Vær oppmerksom på tilstandsbaserte enheter i midten. Hvis en forespørsel går ut gjennom den ene tunnelen og svaret kommer tilbake gjennom den andre, vil en brannmur eller NAT som aldri har sett den opprinnelige strømmen, droppe den. De to tunnelene videresender trafikk riktig, og tilkoblingen feiler likevel.
Kontroller også MTU per vei. En vei med ekstra innkapsling krymper den brukbare størrelsen, og en overføring som lykkes på den ene tunnelen, stopper på den andre nøyaktig ved den størrelsen der den minste knekker.
Sammenlign én vei om gangen
Der designet tillater vedlikehold, ta en tunnel ut av drift og gjenta brukerens oppgave. Hvis feilen forsvinner, hører problemet til veien du fjernet, og neste steg er å sammenligne konfigurasjonen med naboens i stedet for å undersøke rutetabellen på nytt.
Sammenlign den ekte applikasjonen, ikke gjentatte ping. Noter om feilen følger et bestemt neste hopp, en pakkestørrelse eller en overgang etter gjentilkobling, fordi de tre mønstrene peker på ulike reparasjoner.
Til slutt, skriv ned hvorfor veiene anses som likeverdige og hvordan en feil skal ta en av dem ut av drift. Multipath er bare trygt når veiene virkelig kan byttes om, og det er en designpåstand som er verdt å kontrollere i stedet for å anta.