Додајте другу WAN везу и тунели се подигну, али копирање датотеке се и даље заглављује када једна путања затрепери. Веза су здраве и ВПН процеси раде; недостаје уговор између оператера и тунела. Неколико сокета се не понаша аутоматски као једна конекција, а апликација изнад њих не види разлику док се испорука не прекине. Сваки део уговора одговара квару који можете тестирати, и то га чини корисним.

Напишите тај уговор пре избора производа. Има четири дела: ток који ВПН прима, како оператер опоравља податке који недостају, који идентитет крајње тачке преживљава промену путање и како се целина понаша када путања откаже.

Симптом: везе су активне, сесија се ипак прекида

Графикон надзора који приказује обе везе активне доказује само да свака путања може преносити саобраћај. Не доказује да ВПН види један уређен ток, да се пакет изгубљен на једној путањи опоравља на другој, ни да партнер још зна с којом сесијом разговара. Остатак уговора покрива оно што графикон не може да прикаже.

Када се пренос заглави, откријте да ли је оператер наставио испоруку на преживелој путањи. Ако сесија умре док друга веза мирује, оператер је никада није употребио. Ако сесија преживи, али подаци стижу ван реда или дуплирани, оператер премешта пакете без уговора на нивоу конекције. Временске ознаке на обе стране то обично разјасне.

Та разлика одлучује поправку. Проблем рутирања или политике захтева промену избора путање; недостајући слој редања и опоравка захтева други транспорт, а не већи бафер.

Прва гаранција: ток бајтова на нивоу конекције

Ако ВПН-у треба поуздан уређен ток, оператер мора идентификовати распоне бајтова изнад појединачне путање. Свака основна TCP конекција нумерише само своје сегменте, па прималац не може пресложити између путања користећи само те бројеве.

Multipath TCP је стандардизовани пример. Представља један поуздан ток бајтова док усклађује неколико TCP подтокова, са пресликавањем секвенце и потврдом на нивоу података. Апликација чита ток, а не подток који је случајно први испоручио део.

На Linux-у је MPTCP opt-in по сокету преко IPPROTO_MPTCP. Када преговарање не може да користи понашање више путања, документовани повратак је обичан TCP, што значи да апликација може наставити преко једне путање без икаквог коришћења друге. Проверите какво је понашање имплементирани сокет стварно договорио уместо да претпостављате да је кернелска поставка примењена.

Друга гаранција: редање, дуплирање и опоравак

Путање са различитим кашњењима и стопама губитка присиљавају оператера на баферовање, преслагање и поновно слање. Уговор мора навести колико је баферовања дозвољено, какав противпритисак апликација види и која путања носи поновно слање.

Путања која остане повезана, али престане да испоручује, тежа је од чистог затварања. Оператер је мора открити, преместити податке на чекању и избећи вечно чекање сегмента који никада неће стићи. Једноставна провера да су обе везе активне не покрива ово стање.

Дуплирање треба сопствено правило. Слање истог терета обе путање може побољшати латенцију, али прималац мора потиснути копију пре него што стигне до ВПН-а. IPsec anti-replay је опционалан по сигурносној асоцијацији и проверава редне бројеве; слој дуплирања који преслаже или понавља пакете може га активирати или сакрити проблем док тунел не падне.

Трећа гаранција: идентитет крајње тачке и прикључење путање

Партнеру треба стабилан начин препознавања сесије када се појави нова путања. Ако се свака путања аутентификује као засебан тунел, ВПН може видети две сесије уместо једне. Ако оператер спаја путање под једном сесијом, мора дефинисати како се нова путања аутентификује и шта се дешава са старом.

Забележите које адресе и идентификатори остају стабилни: крајња тачка тунела, идентификатор сесије оператера и било који посредник између. Посредник додаје још једну границу доступности и поверења чак и када никада не види заштићени терет.

Овде живи и политика. Путања која се прикључи из неочекиване мреже може бити технички ваљана и ипак кршити предвиђени модел поверења. Одлучите да ли се нове путање аутоматски прихватају, захтевају аутентификацију или се одбијају.

Четврта гаранција: ограничено понашање при квару

Тестирајте потпуни квар путање, не само спору путању. Путања која преживи треба да носи сесију без неограниченог раста меморије, а опоравак не сме да зависи од тајмера дужег него што апликација толерише. Када се неисправна путања врати, оператер мора одлучити да ли ће ребалансирати или оставити ток где јесте.

Поставите ограничења баферовања, поновног слања и броја путања, па их проверите под губитком, преслагањем, дуплирањем и неравнотежом кашњења. Укупна пропусност је овде најмање занимљив број; континуитет испоруке и меморијске границе су уговор.

Држите стање опоравка оператера одвојено од криптографског стања ВПН-а. Сопствени слој поузданости који замењује успостављену аутентификацију или енкрипцију није пречица, а поновна употреба редних бројева између слојева чини заштиту од понављања и дијагностику непоузданима.

Прихватите оператера са планом тестирања

Напишите четири гаранције као провере прошао или није прошао: један уређен ток, дефинисан опоравак, стабилан идентитет сесије, ограничено понашање при квару. Покрените сваку проверу са једном путањом деградираном, а затим са једном уклоњеном.

Један успешан пренос датотеке кроз промену путање не доказује непрекидан рад. Поновите пренос док мењате преферирану путању и проверите и поглед оператера и сопствене бројаче ВПН-а. Ако се њих двоје не слажу која је путања носила податке, уговор још није видљив.

Чувајте одобрену матрицу уз имплементацију. Она следећем инжењеру говори које је понашање обећано, које су комбинације путања тестиране и који начин квара још није подржан, без новог круга нагађања на основу светала стања веза.

Повезани чланци