Два VPN скока на един Pi: кой маршрут носи кой партньор

Два тунелни адреса на една малка платка изглеждат като грешка и рефлексът е да изтриете единия. Този рефлекс чупи нещото, което е трябвало да подреди. Хост с два скока държи по един адрес за всяко прикачване и всеки адрес се избира от различен маршрут. Въпросът, който си струва да се зададе, е кой маршрут избира кой носител за коя дестинация, а не колко адреса съществуват.

Три дестинации, които се нуждаят от различни носители

Веригата от два скока е три класа дестинации, подредени един върху друг, и всеки се носи от различно прикачване. Външният партньор трябва да бъде достигнат през физическата връзка. Вътрешният партньор трябва да бъде достигнат през външния тунел. Дестинацията на покритото приложение трябва да бъде достигната през вътрешния тунел, чийто собствен транспорт се носи от външния.

Попълнете редовете с реалните адреси на читателя, преди да пипате маршрут, защото таблицата е полезна само когато е конкретна. Работещата верига удовлетворява и четирите реда едновременно, а полуработещата обикновено удовлетворява един от тях с грешния носител. Именно четенето на грешния ред като повреда превръща проблема с маршрутизацията в цяла вечер редакции.

Адресите имат роли, не брой

Linux позволява няколко адреса на един интерфейс и няколко тунела на един хост, така че броят не казва нищо за коректността. Важно е кой адрес принадлежи на кое прикачване и дали маршрутът за даден партньор избира прикачването, което сте имали предвид. Три изгледа отговарят на това от три посоки и си струва да се четат в един и същ ред всеки път.

Инвентарът на адресите показва какво съществува и кое прикачване го притежава. Таблицата с маршрути отговаря на въпроса за носителя при обикновен трафик към дестинации. Изгледът на политиките отговаря отново за трафик, избран по източник или маркер, което е нормалната подредба, когато два клиента споделят един хост.

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

Изтриването на адрес, защото списъкът изглежда дълъг, може да премахне част от пътя, а изтриването на маршрут, защото изглежда излишен, прави същото по-тихо. Нито едно не дава грешка; партньорът просто спира да отговаря по пътя, който сте искали, докато остава достъпен по друг. Приложение, което съобщава изходния адрес на вътрешния партньор, не доказва, че трафикът е преминал през външния тунел, защото директният достъп дава същото наблюдение. Тази разлика между наблюдение и доказателство е причината носителят да се проверява на слоя на маршрутизацията.

Редът на активиране побеждава фиксираното изчакване

Ако вътрешният клиент зависи от адрес или маршрут, който външният клиент осигурява, активирането трябва да изчака този ресурс, а не забавяне. Изчакването работи до деня, в който външният тунел е бавен, и тогава се проваля периодично по начин, който никой не може да възпроизведе. Подредбата, основана на зависимости, премахва догадката и не струва нищо освен еднократно описание на зависимостта. Имената на интерфейсите също не са механизъм за подредба.

Ядрото раздава имена като tun0 и tun1 в ред на създаване и този ред може да се промени между рестарти или повторни свързвания. Обвържете конфигурацията с идентичност, която инструментите предоставят, или с име, което определяте умишлено. Името, което избирате, е договор; името, което избира ядрото, е случайност.

Дръжте транспорта на всеки клиент извън маршрута на приложението на другия и бъдете точни за това какво всъщност обещават опциите за маршрутизация на OpenVPN 2.6. Документираният механизъм за пренасочване по подразбиране запазва способността на клиента да достигне собствения си отдалечен партньор през шлюза, който вече е съществувал, и това прекъсва един конкретен цикъл на рекурсия. Той не превръща един клиент в носител на друг, така че останалата част от веригата остава ваш дизайн. Където веригата се нуждае от политика, а не от маршрут, напишете явно правило за източник или маркер и го тествайте с трафика, за който е предназначено.

Какво се случва, когато външният скок умре

Преди веригата да се брои за завършена, решете какво се случва, когато външният скок изчезне. Транспортът на вътрешния клиент умира с него и следващият ход е въпрос на политика, а не на техника: провал, повторен опит или директно свързване през физическата връзка. Именно третият изход заслужава размисъл. Той тихо превръща дизайна с два скока в дизайн с един скок в момента, в който потребителят вярва, че покритието все още е непокътнато.

Ако двата скока са задължителни, вътрешният клиент трябва да не може да установи директен път, когато външният е изчезнал, и начинът да го разберете е да счупите външния скок и да наблюдавате какво прави вътрешният. Одобреният резервен вариант е законен отговор, но трябва да бъде записан, тестван и съобщен. Резервен вариант, който никой не е документирал, е неразличим от изтичане при преглед на инцидент.

DNS и другото семейство адреси принадлежат към същото решение. Локално генерираното търсене следва собствената политика на хоста, а не тази на препратения клиент, така че резолверът, който работи за препратен трафик, може да не е този, който самият хост използва.

Приемайте всеки слой в реда, в който сте го изградили

Тествайте в реда, в който е изградена веригата: първо външният тунел сам, после транспортът на вътрешния клиент през външния тунел, после приложението през вътрешния тунел. Всяко приемане трябва да е свежа връзка, а не страница, която вече е била отворена. След това счупете и възстановете всеки слой поотделно и наблюдавайте какво прави следващият.

Резултатът от резервния вариант е най-ценното наблюдение тук и това, което страницата с публичен IP никога не показва. Запазете пътищата на партньорите, адресите, които използват, и този резултат до конфигурацията, защото щастливият път не е частта, която по-късно се поставя под въпрос.