Wêrom’t rûtes mei gelikense kosten VPN-fouten min sichtber meitsje
As ferskate tunnels deselde kosten diele, kin elke stream in oare nimme. In slagge ping seit neat oer it paad dat jo applikaasje echt brûkt.
In brûker meldt dat de ynterne applikaasje fan ien masine ôf wurket en fan in oare ôf mislearret, wylst de ping dy’t jo fan de gateway ôf rinne litte yn beide gefallen slagget. Mei ferskate tunnels fan gelikense kosten is dat gjin tsjinstelling. Elke stream wurdt op syn eigen folgjende hop pleatst, dat jo probe en de sesje fan de brûker kinne gewoan ferskillende paden brûke. De trochrin hjirûnder reprodusearret dy kar foardat der eat feroare wurdt.
Ien ping, ferskate mooglike paden
As in rûte mear as ien folgjende hop hat tsjin deselde kosten, moat de router der ien per pakket kieze. De measte ymplemintaasjes hashje fjilden út it pakket, meast de boarne- en bestimmingsadressen tegearre mei it protokol en de poarten, sadat antwurden op itselde paad bliuwe. Ferskillende applikaasjes, of sels ferskillende ferbiningen fan ien applikaasje, meitsje ferskillende hashes.
Dêrom bewiist in diagnoaze fan de gateway sa min. De eigen probe fan de gateway hat syn eigen adressen en poarten, en dus syn eigen hash. It kin op de sûne tunnel lânje wylst de brûker op ’e stikene bliuwt lânjen.
Hoe’t it platfoarm in folgjende hop kiest
Reprodusearje de kar yn stee fan te rieden. Freegje de kernel hokker rûte dy brûke soe foar deselde boarne en bestimming as de mislearjende sesje. Dy syktocht omfettet fjilden dy’t in gewoane bestimmingssyktocht negearret. Rin it ek fan in wurkjende klient ôf en fergelykje de beide antwurden:
ip route get 10.20.5.7 from 10.20.0.14Nijere ferzjes fan iproute2 akseptearje ek it protokol en de bestimmingspoart, wat fan belang is as de hash dy befettet. Fergelykje dy útkomst mei deselde syktocht fan in wurkjende klient, en it ferskil is it bewiis dat jo misten.
| 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 |
Folchje de mislearjende stream, net de rûtetabel
De rûtetabel listet beide tunnels en sjocht der per definysje goed út. De fraach is wat elke tunnel mei it pakket docht as it ienris keazen is. Ferifiearje dat beide deselde beskerme prefiksen, deselde trochstjoerpermissy en in werompaad drage dat deselde klient berikt.
Let op steatbefettende apparaten yn ’e midden. As in fersyk troch ien tunnel fuortgiet en it antwurd troch de oare weromkomt, sil in firewal of NAT dy’t de oarspronklike stream nea sjoen hat, it fuortsmite. De beide tunnels stjoere ferkear elk korrekt troch, en de ferbining mislearret noch altyd.
Kontrolearje ek de MTU per paad. In paad mei in ekstra ynkapseling ferlytset de brûkbere grutte, en in oerdracht dy’t op ien tunnel slagget, stûket op ’e oare krekt by de grutte dêr’t de lytsere brekt.
Fergelykje ien paad tagelyk
Dêr’t it ûntwerp ûnderhâld tasteat, helje ien tunnel út tsjinst en werhelje de taak fan de brûker. As de flater ferdwynt, heart it probleem by it paad dat jo fuorthellen, en de folgjende stap is om syn konfiguraasje mei dy fan ’e buorman te fergelykjen yn stee fan de rûtetabel op ’e nij te ûndersykjen.
Fergelykje de echte applikaasje, net werhelle pings. Skriuw op oft de flater in bepaald folgjend hop, in pakketgrutte of in oergong nei opnij ferbinen folget, want dy trije patroanen wize op ferskillende reparaasjes.
Skriuw ta beslút op wêrom’t de paden as lykweardich beskôge wurde en hoe’t in flater ien derfan út tsjinst heart te heljen. Multypaad is allinnich feilich as de paden echt útwikselber binne, en dat is in ûntwerpstelling dy’t it wurdich is te kontrolearjen yn stee fan te ferûnderstellen.