Hvorfor ruter med samme pris gør VPN-fejl svære at se
Når flere tunneler deler samme pris, kan hver strøm vælge en anden. Et vellykket ping siger intet om den vej, din applikation faktisk bruger.
En bruger rapporterer, at den interne applikation virker fra én maskine og fejler fra en anden, mens det ping, du kører fra gatewayen, lykkes i begge tilfælde. Med flere tunneler med samme pris er det ikke en selvmodsigelse. Hver strøm placeres på sit eget næste hop, så din test og brugerens session bruger måske blot forskellige veje. Gennemgangen nedenfor genskaber valget, før noget ændres.
Ét ping, flere mulige veje
Når en rute har mere end ét næste hop til samme pris, skal routeren vælge ét pr. pakke. De fleste implementeringer hasher felter fra pakken, typisk kilde- og destinationsadresserne sammen med protokollen og portene, så svar bliver på samme vej. Forskellige applikationer, eller endda forskellige forbindelser fra én applikation, giver forskellige hashes.
Derfor beviser en diagnostik fra gatewayen så lidt. Gatewayens egen test har sine egne adresser og porte og dermed sin egen hash. Den kan lande på den sunde tunnel, mens brugeren bliver ved med at lande på den ødelagte.
Sådan vælger platformen et næste hop
Genskab valget i stedet for at gætte det. Spørg kernen, hvilken rute den ville bruge til samme kilde og destination som den fejlende session. Det opslag omfatter felter, som et almindeligt destinationsopslag ignorerer. Kør det også fra en fungerende klient, og sammenlign de to svar:
ip route get 10.20.5.7 from 10.20.0.14Nyere iproute2-udgivelser accepterer også protokollen og destinationsporten, hvilket betyder noget, når hashen omfatter dem. Sammenlign det output med det samme opslag fra en fungerende klient, og forskellen er det bevis, du manglede.
| 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 fejlende strøm, ikke rutetabellen
Rutetabellen viser begge tunneler og ser per definition rigtig ud. Spørgsmålet er, hvad hver tunnel gør ved pakken, når den er valgt. Bekræft, at begge bærer de samme beskyttede præfikser, den samme videresendelsestilladelse og en returvej, der når samme klient.
Vær opmærksom på stateful enheder i midten. Hvis en anmodning forlader gennem den ene tunnel, og svaret vender tilbage gennem den anden, vil en firewall eller NAT, der aldrig har set den oprindelige strøm, droppe den. De to tunneler videresender hver især trafik korrekt, og forbindelsen fejler stadig.
Kontroller også MTU pr. vej. En vej med en ekstra indkapsling krymper den brugbare størrelse, og en overførsel, der lykkes på den ene tunnel, går i stå på den anden præcis ved den størrelse, hvor den mindre knækker.
Sammenlign én vej ad gangen
Hvor designet tillader vedligeholdelse, tag en tunnel ud af drift, og gentag brugerens opgave. Hvis fejlen forsvinder, hører problemet til den vej, du fjernede, og næste skridt er at sammenligne dens konfiguration med naboens i stedet for at undersøge rutetabellen igen.
Sammenlign den rigtige applikation, ikke gentagne ping. Notér, om fejlen følger et bestemt næste hop, en pakkestørrelse eller en overgang efter genopkobling, fordi de tre mønstre peger på forskellige reparationer.
Skriv til sidst ned, hvorfor vejene anses for ækvivalente, og hvordan en fejl skal fjerne en af dem fra drift. Multipath er kun sikkert, når vejene virkelig kan udskiftes, og det er en designpåstand, der er værd at kontrollere i stedet for at antage.