Зошто рутите со еднаква цена ги прават дефектите на VPN тешко видливи
Кога неколку тунели делат иста цена, секој тек може да земе друг. Успешен ping не кажува ништо за патеката што вашата апликација навистина ја користи.
Корисник известува дека внатрешната апликација работи од една машина и не успева од друга, додека ping-от што го извршувате од портата успева во двата случаи. Со неколку тунели со еднаква цена, тоа не е противречност. Секој тек се поставува на свој следен скок, па вашата проверка и сесијата на корисникот едноставно може да користат различни патеки. Прегледот подолу го репродуцира тој избор пред да се смени нешто.
Еден ping, неколку можни патеки
Кога рутата има повеќе од еден следен скок со иста цена, рутерот мора да избере еден по пакет. Повеќето имплементации хешираат полиња од пакетот, обично изворната и целната адреса заедно со протоколот и портите, за да останат одговорите на истата патека. Различни апликации, дури и различни врски од една апликација, даваат различни хешеви.
Затоа дијагностиката од портата докажува толку малку. Сопствената проверка на портата има свои адреси и порти, а со тоа и свој хеш. Таа може да слета на здравиот тунел додека корисникот сѐ уште слетува на расипаниот.
Како платформата избира следен скок
Репродуцирајте го изборот наместо да го погодувате. Прашајте го јадрото која рута би ја користело за истиот извор и цел како сесијата што не успева. Тоа пребарување вклучува полиња што обичното пребарување по цел ги игнорира. Извршете го и од клиент што работи и споредете ги двата одговори:
ip route get 10.20.5.7 from 10.20.0.14Поновите изданија на iproute2 прифаќаат и протокол и целна порта, што е важно кога хешот ги вклучува. Споредете го тој излез со истото пребарување од клиент што работи, и разликата е доказот што ви недостигаше.
| 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 |
Следете го текот што не успева, не табелата со рути
Табелата со рути ги наведува двата тунели и по дефиниција изгледа исправна. Прашањето е што прави секој тунел со пакетот откако ќе биде избран. Проверете дали двата носат исти заштитени префикси, исто дозвола за препраќање и повратна патека што стигнува до истиот клиент.
Обрнете внимание на уредите со состојба во средината. Ако барањето излезе низ еден тунел, а одговорот се врати низ другиот, заштитниот ѕид или NAT што никогаш не го видел оригиналниот тек ќе го отфрли. Двата тунели исправно препраќаат сообраќај, и врската сѐ уште не успева.
Проверете и MTU по патека. Патека со дополнителна инкапсулација ја намалува употребливата големина, а преносот што успева низ еден тунел застанува на другиот токму на големината каде што се крши помалиот.
Споредете една патека одеднаш
Каде што дизајнот дозволува одржување, извадете еден тунел од употреба и повторете ја задачата на корисникот. Ако дефектот исчезне, проблемот и припаѓа на отстранетата патека, а следниот чекор е да ја споредите нејзината конфигурација со соседната, наместо повторно да ја прегледувате табелата со рути.
Споредете ја вистинската апликација, а не повторени ping-ови. Запишете дали дефектот следи одреден следен скок, големина на пакет или премин по повторно поврзување, бидејќи тие три образци укажуваат на различни поправки.
На крајот запишете зошто патеките се сметаат за еквивалентни и како дефектот треба да извади една од нив од употреба. Повеќепатноста е безбедна само кога патеките се навистина заменливи, а тоа е проектна изјава што вреди да се провери, а не да се претпостави.