Miksi samanhintaiset reitit tekevät VPN-vioista vaikeasti havaittavia
Kun useat tunnelit jakavat saman hinnan, jokainen virta voi valita eri tunnelin. Onnistunut ping ei kerro mitään siitä polusta, jota sovelluksesi todella käyttää.
Käyttäjä kertoo, että sisäinen sovellus toimii yhdeltä koneelta ja epäonnistuu toiselta, kun taas yhdyskäytävältä ajettu ping onnistuu molemmissa tapauksissa. Kun usealla tunnelilla on sama hinta, kyse ei ole ristiriidasta. Jokainen virta sijoitetaan omalle seuraavalle hypylleen, joten testisi ja käyttäjän istunto saattavat yksinkertaisesti käyttää eri polkuja. Alla oleva läpikäynti toistaa valinnan ennen kuin mitään muutetaan.
Yksi ping, useita mahdollisia polkuja
Kun reitillä on useampi kuin yksi seuraava hyppy samalla hinnalla, reitittimen on valittava yksi pakettia kohden. Useimmat toteutukset tiivistävät paketin kenttiä, tavallisesti lähde- ja kohdeosoitteet sekä protokollan ja portit, jotta vastaukset pysyvät samalla polulla. Eri sovellukset, jopa yhden sovelluksen eri yhteydet, tuottavat eri tiivisteitä.
Siksi yhdyskäytävältä tehty diagnoosi todistaa niin vähän. Yhdyskäytävän oma testi käyttää omia osoitteitaan ja porttejaan ja siten omaa tiivistettään. Se voi päätyä terveelle tunnelille, kun käyttäjä päätyy yhä rikkinäiselle.
Miten alusta valitsee seuraavan hypyn
Toista valinta sen sijaan, että arvaisit sen. Kysy ytimeltä, mitä reittiä se käyttäisi samalle lähteelle ja kohteelle kuin epäonnistuva istunto. Haku sisältää kenttiä, jotka tavallinen kohdehaku jättää huomiotta. Aja se myös toimivalta asiakkaalta ja vertaa kahta vastausta:
ip route get 10.20.5.7 from 10.20.0.14Uudemmat iproute2-versiot hyväksyvät myös protokollan ja kohdeportin, millä on merkitystä, kun tiiviste sisältää ne. Vertaa tuota tulostetta samaan hakuun toimivalta asiakkaalta, ja ero on se todiste, joka sinulta puuttui.
| 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 |
Seuraa epäonnistuvaa virtaa, älä reititystaulukkoa
Reititystaulukko luettelee molemmat tunnelit ja näyttää määritelmän mukaan oikealta. Kysymys on, mitä kukin tunneli tekee paketille, kun se on valittu. Varmista, että molemmat kuljettavat samat suojatut etuliitteet, saman edelleenlähetysluvan ja paluupolun, joka saavuttaa saman asiakkaan.
Kiinnitä huomiota tilaa ylläpitäviin laitteisiin välissä. Jos pyyntö lähtee yhden tunnelin kautta ja vastaus palaa toisen kautta, palomuuri tai NAT, joka ei koskaan nähnyt alkuperäistä virtaa, pudottaa sen. Molemmat tunnelit välittävät liikennettä oikein, ja yhteys epäonnistuu silti.
Tarkista myös MTU poluittain. Ylimääräisen kapseloinnin polku pienentää käytettävissä olevaa kokoa, ja siirto, joka onnistuu yhden tunnelin kautta, pysähtyy toisella täsmälleen siinä koossa, jossa pienempi katkeaa.
Vertaa yhtä polkua kerrallaan
Missä suunnittelu sallii huollon, ota yksi tunneli pois käytöstä ja toista käyttäjän tehtävä. Jos vika katoaa, ongelma kuuluu poistettuun polkuun, ja seuraava askel on verrata sen kokoonpanoa naapuriin sen sijaan, että tutkisit reititystaulukkoa uudelleen.
Vertaa todellista sovellusta, älä toistuvia pingejä. Kirjaa, seuraako vika tiettyä seuraavaa hyppyä, pakettikokoa vai uudelleenyhdistämisen jälkeistä siirtymää, koska nämä kolme kuvioa viittaavat eri korjauksiin.
Kirjoita lopuksi muistiin, miksi polut katsotaan samanarvoisiksi ja miten vian on tarkoitus poistaa yksi niistä käytöstä. Monipolkuisuus on turvallista vain, kun polut todella ovat vaihdettavissa, ja se on suunnitteluväite, joka kannattaa tarkistaa eikä olettaa.