Преглед на VPN интерфейс в Linux с ip link, слой по слой

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

Прочетете интерфейса, преди да прочетете иконата

Започнете с ip -details link show dev tun0 както е документирано в ръководството за ip-link, като вместо конвенционалното име поставите интерфейса, който вашият клиент действително притежава. Флаговете, типът, MTU и идентичността на интерфейса са полезни наблюдения. Формулировката на състоянието на виртуален интерфейс не е длъжна да се държи като индикатора за носеща на физически кабел, затова третирайте UP като твърдение за интерфейса, а не за тунела.

Това разграничение обяснява най-объркващия случай: интерфейс, който остава, докато отдалечената страна се свързва отново или е недостъпна.

Настройките за устойчивост могат да задържат връзката именно за да не я пресъздава повторното свързване, което значи, че наличието не е здраве.

Добавете броячи и заявка, която би трябвало да ги използва

Използвайте поддържания изглед на статистика ip -s link show dev tun0 и отбележете броя на пакетите и байтовете в двете посоки. След това генерирайте безвредна заявка, която би трябвало да премине през интерфейса, и сравнете съответната посока. Заявка, поела директния маршрут на друго приложение, няма да премести тези броячи, и точно това е смисълът на упражнението.

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

Вземете показанието два пъти, веднъж преди и веднъж след, вместо да се доверявате на един момент.

Адресите и маршрутите са отделни стъпки

Връзка може да съществува без префикса, конфигурацията на резолвера или маршрута, от който приложението се нуждае. Проверете адреса с ip address show dev tun0, после проверете кой маршрут би избрала дестинацията с ip route get за действителната цел. Тези три наблюдения отговарят на три различни въпроса и само последното е за препращането.

При IPsec значение могат да имат и политиката за сигурност, и състоянието на асоциацията, а не всеки дизайн на IPsec се появява като прост tun интерфейс. Търсенето на tun устройство, което никога не е трябвало да съществува, е бърз път към грешно заключение.

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

Не изтривайте това, което не сте идентифицирали

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

Ако интерфейсът принадлежи на контейнерна среда или на мрежово пространство от имена, което не сте създали, собственикът е на една команда разстояние и си струва да бъде намерен първи.

Тази предпазливост важи и за ip link set down, което изглежда обратимо и често не е.

Какво трябва да ви остави проверката

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

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

Пазете изхода заедно с тикета, защото по-късното сравнение е полезно само ако виждате какво се е променило.

След това затворете цикъла, като тествате приложението отново, защото интерфейсът никога не е бил това, което е интересувало потребителя.