OpenVPN TAP на macOS: проверете клиента, преди да отстранявате грешки
TAP пренася Ethernet кадри, а TUN — IP пакети, и повечето съвременни клиенти за macOS изоставиха първото. Потвърдете режима, след което мигрирайте заедно със собственика на сървъра.
Стар профил попада на актуален Mac, клиентът го импортира без оплакване и връзката пада или никога не пропуска трафик. Преди да изразходвате един следобед за сертификати, прочетете реда за устройството в профила. Ако там пише dev tap, вие искате от клиента интерфейс от тип Ethernet и на macOS именно тази заявка е мястото, където приключват повечето такива сесии.
Стъпка 1: потвърдете, че профилът наистина иска TAP
Профилите биват преименувани, обвивани и експортирани наново, затова проверете файла, който действително сте импортирали. Търсете директивата за устройството и всеки включен файл, който може да я отмени. Два реда изход решават въпроса в повечето случаи. Когато се появят и dev, и dev-type, печели по-късната директива и точно такъв детайл крие копиран профил.
grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null
Ако файлът съдържа dev tap или dev tap0, клиентът трябва да реализира TAP интерфейс. Ако съдържа dev tun, останалата част от тази статия не се отнася и проблемът е другаде.
Запишете името и версията на клиента, версията на macOS и откъде идва профилът. Тези три факта решават кой от двата пътя по-долу е изобщо възможен.
Стъпка 2: разберете какво всъщност променя режимът на устройството
TUN интерфейсът пренася IP пакети. Клиентът чете и записва пакети, адресирани до IP партньор, а операционната система ги маршрутизира като всеки друг интерфейс.
TAP интерфейсът пренася Ethernet кадри, включително широкомовни и ARP. Това позволява на мостов сървър да раздава адреси по DHCP и на клиент да открива устройства чрез викане, поради което някои стари схеми разчитат на него.
Цената е, че TAP се нуждае от драйвер, който представя Ethernet интерфейс на системата. Apple прекрати модела с разширение на ядрото, на който разчитаха по-старите TAP драйвери за Mac, а заместващият му API не се появява магически в клиенти, които никога не са били обновявани да го използват. Възможност на платформата и изпратен продукт са различни неща.
Стъпка 3: изберете между съвместим клиент и миграция
Има два честни пътя. Първият е клиент, чийто издател заявява за вашата версия на macOS и хардуер, че поддържа нужната ви TAP схема. Не форумен пост от преди четири години и не архивиран инсталатор: актуално изявление плюс тестова връзка.
Вторият е преместване на услугата към TUN, което е промяна на сървъра в същата степен, в която и на клиента. Нужни са маршрутизирана топология, пул от адреси, изпращани маршрути за отдалечените мрежи и обратен път от тези мрежи към пула.
Това, което не работи, е да смените tap с tun в локалното копие и да се надявате. Сървърът все още прави мост, клиентът вече говори IP и нищо не се съгласува.
Стъпка 4: съберете фактите, преди да променяте работеща услуга
Оставете оригиналния профил недокоснат и направете копие за експерименти. Файл, който можете да възстановите за минута, струва повече от подредена папка. След като замяната проработи, изтрийте копието нарочно, вместо да оставите два профила, които изглеждат еднакво в списък. Този един навик предотвратява повечето объркване след неуспешна миграция. Запишете текущото поведение, за да можете да докажете какво се е променило: вдига ли се тунелът, получава ли адрес, стигате ли до един известен хост и работи ли разрешаването на имена.
Задайте на собственика на шлюза три въпроса. Сървърът работи ли с мостова или маршрутизирана топология? Кои отдалечени префикси трябва да са достъпни? И има ли прозорец за поддръжка за промяна на конфигурацията, или се очаква да работи без докосване на сървъра?
Отговорите на тези въпроси определят дали решавате проблем на клиента този следобед, или планирате промяна на мрежата следващата седмица.
Стъпка 5: проверете миграцията от двата края
Щом сървърът има маршрутизирана конфигурация и имате подходящ профил, тествайте в този ред: тунелът се установява, клиентът получава адрес от новия пул, хост от отдалечената страна отговаря и име се разрешава чрез изпратената DNS настройка.
След това проверете какво е зависело от поведението на Ethernet. Ако приложение е откривало устройства чрез широкомовно предаване, то няма да ги намери през маршрутизиран тунел и никаква клиентска конфигурация не връща това. Такова приложение се нуждае от известен адрес, локален помощен хост или различен метод за откриване.
Завършете с едно повторно свързване и едно рестартиране, защото профил, който работи само от първия опит, обикновено означава, че изпращаните маршрути или DNS настройката не се прилагат при повторно свързване.
Когато все още се проваля, прочетете първата грешка
Клиент, който не може да създаде интерфейса, го казва в журнала си, обикновено в първите няколко реда. Клиент, който го създаде и след това не успее да се автентикира, е отдавна отвъд въпроса за устройството и продължаването на гонитбата на TAP прахосва сесията.
Пазете оригиналния профил и работещата конфигурация, докато замяната бъде доказана. Връщането на клиентска промяна е бързо; преизграждането на мостова мрежа, която някой е разглобил по догадка, не е.