Два VPN скока на једном Pi: која рута носи којег партнера

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

Три дестинације којима требају различити носиоци

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

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

Адресе имају улоге, не број

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

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

ip -4 addr show
ip -4 route show table all
ip rule show

Брисање адресе зато што списак изгледа дуг може да уклони део путање, а брисање руте зато што изгледа сувишно чини исто тише. Ни једно не даје грешку; партнер једноставно престаје да одговара на путањи коју сте мислили, док остаје доступан другом. Апликација која извештава излазну адресу унутрашњег партнера не доказује да је саобраћај прешао спољни тунел, јер директан приступ даје исто запажање. Управо тај јаз између запажања и доказа је разлог зашто се носилац проверава на слоју рутирања.

Редослед активирања побеђује фиксно чекање

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

Језгро додељује имена као tun0 и tun1 по редоследу стварања, и тај редослед може да се промени између поновног покретања или поновног повезивања. Повежите конфигурацију са идентитетом који алат пружа, или са именом које свесно додељујете. Име које изаберете је уговор; име које изабере језгро је случајност.

Држите транспорт сваког клијента изван апликационе руте другог, и будите прецизни о томе шта опције рутирања OpenVPN 2.6 заиста обећавају. Документовани механизам подразумеваног преусмеравања одржава клијента способним да достигне свог удаљеног партнера преко пролаза који је већ постојао, што пресеца једну конкретну рекурзивну петљу. Он не претвара један клијент у носиоца другог, тако да остатак ланца остаје ваш дизајн. Тамо где ланцу треба политика уместо руте, напишите експлицитно правило извора или ознаке и тестирајте га са саобраћајем са којим треба да се поклопи.

Шта се дешава када спољни скок умре

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

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

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

Прихватите сваки слој по редоследу по ком сте га градили

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

Резултат резерве је овде највредније запажање, и оно што страница са јавном IP никада не показује. Сачувајте путање партнера, адресе које користе и тај исход поред конфигурације, јер срећна путања није део о ком се касније пита.