Varför rutter med samma kostnad gör VPN-fel svåra att se
När flera tunnlar delar samma kostnad kan varje flöde välja en annan. Ett lyckat ping säger ingenting om den väg din applikation faktiskt använder.
En användare rapporterar att den interna applikationen fungerar från en maskin och misslyckas från en annan, medan pinget du kör från gatewayen lyckas i båda fallen. Med flera tunnlar med samma kostnad är det ingen motsägelse. Varje flöde placeras på sitt eget nästa hopp, så din kontroll och användarens session använder kanske bara olika vägar. Genomgången nedan återskapar valet innan något ändras.
Ett ping, flera möjliga vägar
När en rutt har mer än ett nästa hopp till samma kostnad måste routern välja ett per paket. De flesta implementationer hashar fält från paketet, vanligen käll- och måladresserna tillsammans med protokollet och portarna, så att svar stannar på samma väg. Olika applikationer, eller till och med olika anslutningar från en applikation, ger olika hashvärden.
Därför bevisar en diagnos från gatewayen så lite. Gatewayens egen kontroll har sina egna adresser och portar och därmed sin egen hash. Den kan hamna på den friska tunneln medan användaren fortsätter hamna på den trasiga.
Hur plattformen väljer ett nästa hopp
Återskapa valet i stället för att gissa det. Fråga kärnan vilken rutt den skulle använda för samma källa och mål som den misslyckade sessionen. Den uppslagningen omfattar fält som en vanlig målsökning ignorerar. Kör den också från en fungerande klient och jämför de två svaren:
ip route get 10.20.5.7 from 10.20.0.14Nyare iproute2-utgåvor accepterar också protokollet och målporten, vilket spelar roll när hashen omfattar dem. Jämför den utskriften med samma uppslagning från en fungerande klient, och skillnaden är beviset du saknade.
| 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ölj det misslyckade flödet, inte routingtabellen
Routingtabellen listar båda tunnlarna och ser per definition korrekt ut. Frågan är vad varje tunnel gör med paketet när det valts. Kontrollera att båda bär samma skyddade prefix, samma vidarebefordranstillstånd och en returväg som når samma klient.
Var uppmärksam på tillståndskänsliga enheter i mitten. Om en begäran går ut genom den ena tunneln och svaret kommer tillbaka genom den andra, kommer en brandvägg eller NAT som aldrig sett det ursprungliga flödet att släppa den. De två tunnlarna vidarebefordrar trafik korrekt, och anslutningen misslyckas ändå.
Kontrollera också MTU per väg. En väg med extra inkapsling krymper den användbara storleken, och en överföring som lyckas på den ena tunneln fastnar på den andra exakt vid den storlek där den mindre brister.
Jämför en väg i taget
Där designen tillåter underhåll, ta en tunnel ur drift och upprepa användarens uppgift. Om felet försvinner hör problemet till vägen du tog bort, och nästa steg är att jämföra dess konfiguration med grannens i stället för att undersöka routingtabellen igen.
Jämför den riktiga applikationen, inte upprepade ping. Notera om felet följer ett visst nästa hopp, en paketstorlek eller en övergång efter återanslutning, eftersom de tre mönstren pekar på olika reparationer.
Skriv slutligen ned varför vägarna anses likvärdiga och hur ett fel ska ta en av dem ur drift. Multipath är bara säkert när vägarna verkligen kan bytas ut, och det är ett designpåstående som är värt att kontrollera i stället för att anta.