Kvifor ruter med lik kostnad gjer VPN-feil vanskelege å sjå
Når fleire tunnelar deler same kostnad, kan kvar straum velje ein annan. Ein vellukka ping seier ingenting om vegen applikasjonen din faktisk brukar.
Ein brukar melder at den interne applikasjonen verkar frå éin maskin og feilar frå ein annan, medan pinget du køyrer frå gatewayen lukkast i begge tilfelle. Med fleire tunnelar med lik kostnad er ikkje det ei sjølvmotseiing. Kvar straum blir plassert på sitt eige neste hopp, så testen din og økta til brukaren brukar kanskje berre ulike vegar. Gjennomgangen nedanfor attskapar valet før noko blir endra.
Éin ping, fleire moglege vegar
Når ei rute har meir enn eitt neste hopp til same kostnad, må rutaren velje eitt per pakke. Dei fleste implementasjonar hashar felt frå pakken, typisk kjelde- og mål-adressene saman med protokollen og portane, slik at svar blir verande på same veg. Ulike applikasjonar, eller jamvel ulike tilkoplingar frå éin applikasjon, gjev ulike hashar.
Difor beviser ein diagnose frå gatewayen så lite. Gatewayen sin eigen test har sine eigne adresser og portar, og dermed sin eigen hash. Han kan lande på den sunne tunnelen medan brukaren held fram med å lande på den øydelagde.
Korleis plattformen vel eit neste hopp
Attskap valet i staden for å gjette det. Spør kjernen kva rute han ville bruke for same kjelde og mål som den feilande økta. Det oppslaget omfattar felt som eit vanleg mål-oppslag ignorerer. Køyr det òg frå ein fungerande klient, og samanlikn dei to svara:
ip route get 10.20.5.7 from 10.20.0.14Nyare iproute2-utgåver godtek òg protokollen og målporten, noko som tel når hashen omfattar dei. Samanlikn den utskrifta med det same oppslaget frå ein fungerande klient, og skilnaden er beviset du mangla.
| 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 feilande straumen, ikkje rutetabellen
Rutetabellen listar begge tunnelane og ser per definisjon riktig ut. Spørsmålet er kva kvar tunnel gjer med pakken når han er vald. Stadfest at begge ber dei same verna prefiksa, same vidaresendingstilgang og ein returveg som når same klient.
Ver merksam på tilstandsbaserte einingar i midten. Viss ein førespurnad går ut gjennom den eine tunnelen og svaret kjem tilbake gjennom den andre, vil ein brannmur eller NAT som aldri har sett den opphavlege straumen, droppe han. Dei to tunnelane vidaresender trafikk riktig, og tilkoplinga feilar likevel.
Kontroller òg MTU per veg. Ein veg med ekstra innkapsling krympar den brukbare storleiken, og ei overføring som lukkast på den eine tunnelen, stoggar på den andre nøyaktig ved den storleiken der den minste knekk.
Samanlikn éin veg om gongen
Der designet tillèt vedlikehald, ta ein tunnel ut av drift og gjenta oppgåva til brukaren. Viss feilen forsvinn, høyrer problemet til vegen du fjerna, og neste steg er å samanlikne konfigurasjonen med naboen sin i staden for å undersøkje rutetabellen på nytt.
Samanlikn den ekte applikasjonen, ikkje gjentekne ping. Noter om feilen følgjer eit bestemt neste hopp, ein pakkestorleik eller ein overgang etter attkopling, fordi dei tre mønstra peikar på ulike reparasjonar.
Til slutt, skriv ned kvifor vegane blir rekna som likeverdige og korleis ein feil skal ta ein av dei ut av drift. Multipath er berre trygt når vegane verkeleg kan bytast om, og det er ein designpåstand som er verdt å kontrollere i staden for å ta for gitt.