Waarom gelyke-koste-roetes VPN-foute moeilik sigbaar maak
Wanneer verskeie tonnels dieselfde koste deel, kan elke vloei ’n ander een neem. ’n Geslaagde ping sê niks oor die pad wat jou toepassing werklik gebruik nie.
’n Gebruiker meld dat die interne toepassing van een masjien af werk en van ’n ander af misluk, terwyl die ping wat jy vanaf die gateway uitvoer in beide gevalle slaag. Met verskeie tonnels van gelyke koste is dit nie ’n teenstrydigheid nie. Elke vloei word op ’n eie volgende sprong geplaas, so jou toets en die gebruiker se sessie gebruik dalk eenvoudig verskillende paaie. Die deurloop hieronder herhaal die keuse voordat enigiets verander word.
Een ping, verskeie moontlike paaie
Wanneer ’n roete meer as een volgende sprong teen dieselfde koste het, moet die router een per pakkie kies. Die meeste implementasies hash velde uit die pakkie, tipies die bron- en bestemmingsadresse saam met die protokol en die poorte, sodat antwoorde op dieselfde pad bly. Verskillende toepassings, of selfs verskillende verbindings van een toepassing, lewer verskillende hashes.
Dit is waarom ’n diagnostiek vanaf die gateway so min bewys. Die gateway se eie toets het sy eie adresse en poorte, en dus sy eie hash. Dit kan op die gesonde tonnel beland terwyl die gebruiker aanhou om op die stukkende een te beland.
Hoe die platform ’n volgende sprong kies
Herhaal die keuse in plaas daarvan om dit te raai. Vra die kernel watter roete dit vir dieselfde bron en bestemming as die mislukte sessie sou gebruik. Daardie opsoek sluit velde in wat ’n gewone bestemmingsopsoek ignoreer. Voer dit ook vanaf ’n werkende kliënt uit en vergelyk die twee antwoorde:
ip route get 10.20.5.7 from 10.20.0.14Nuwer weergawes van iproute2 aanvaar ook die protokol en die bestemmingspoort, wat saak maak wanneer die hash hulle insluit. Vergelyk daardie uitset met dieselfde opsoek vanaf ’n werkende kliënt, en die verskil is die bewys wat jy gemis het.
| 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 |
Volg die mislukte vloei, nie die roetetabel nie
Die roetetabel lys beide tonnels en lyk per definisie korrek. Die vraag is wat elke tonnel met die pakkie doen nadat dit gekies is. Verifieer dat albei dieselfde beskermde voorvoegsels dra, dieselfde deurstuurregte het en ’n terugpad het wat dieselfde kliënt bereik.
Let op toestandsvolle toestelle in die middel. As ’n versoek deur een tonnel vertrek en die antwoord deur die ander terugkom, sal ’n firewall of NAT wat nooit die oorspronklike vloei gesien het nie, dit laat val. Die twee tonnels stuur elkeen verkeer korrek deur, en die verbinding misluk steeds.
Kyk ook na die MTU per pad. ’n Pad met ’n ekstra inkapseling verklein die bruikbare grootte, en ’n oordrag wat op een tonnel slaag, stagneer op die ander presies by die grootte waar die kleiner een breek.
Vergelyk een pad op ’n slag
Waar die ontwerp instandhouding toelaat, neem een tonnel uit diens en herhaal die gebruiker se taak. As die fout verdwyn, hoort die probleem aan die pad wat jy verwyder het, en die volgende stap is om sy konfigurasie met sy buurman te vergelyk eerder as om die roetetabel weer te ondersoek.
Vergelyk die werklike toepassing, nie herhaalde pings nie. Teken aan of die fout ’n bepaalde volgende sprong, ’n pakkiegrootte of ’n oorgang ná herverbinding volg, want daardie drie patrone wys op verskillende herstellings.
Skryf laastens neer waarom die paaie as gelykwaardig beskou word en hoe ’n fout veronderstel is om een uit diens te neem. Multipad is net veilig wanneer die paaie werklik uitruilbaar is, en dit is ’n ontwerpstelling wat die moeite werd is om na te gaan eerder as om te aanvaar.