Предупреждение OpenVPN AF_INET: безвредно връщане назад или неуспешен сокет?

Два реда в дневника на OpenVPN започват с едни и същи думи и само един от тях съобщава за проблем. Could not determine IPv4/IPv6 protocol. Using AF_INET е известие за връщане назад: профилът е оставил семейството адреси отворено, затова демонът е избрал едно и е продължил. Клонът за неуспех съобщава, че не е създаден сокет, и иска рестарт. Всичко след общия префикс ги разделя, затова четете след него, преди да променяте нещо.

Какво съобщава известието за връщане назад

OpenVPN приема явно семейство чрез proto udp4 или proto udp6 и приема proto udp, когато семейството трябва да бъде изведено при стартиране. Във втория случай демонът преглежда локалната информация за обвързване и избира.

Когато това извеждане работи, предупреждението посочва накъде е тръгнало и процесът продължава да създава сокета. Сървър с proto udp на хост с двоен стек често попада така на IPv4. Нищо в този път не е грешка и нищо в него не подсказва за атака, липсващ уеб сървър или отказан акаунт. Редът е полезен само защото следващите проверки трябва да се сравняват със семейството, което той назовава.

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

Как изглежда клонът за неуспех

По-късно в същия код за сокети има клон, в който няма никакъв сокет. Той записва по-краткото съобщение за семейство адреси и иска рестарт, защото няма с какво да продължи. Началните думи съвпадат с връщането назад, резултатът — не.

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

Намерен от grep ред също не е идентификация на клон. Фразата се появява в завъртени обобщения, в пренесени редове и в откъси от дневник, които хората поставят от втора ръка, затова четете съседните редове и реда на времевите марки, а не единственото съвпадение.

Проверете слушателя, а не предупреждението

Работещият сървър отговаря на въпроса за семейството директно, без изводи от текста на дневника.

ss -lunp | grep openvpn
ss -ltnp | grep openvpn

Съпоставете семейството, адреса и порта с профила. Редът 0.0.0.0:1194 е само IPv4, докато ред [::]:1194 на хост с двоен стек може да приема и двете семейства в зависимост от настройката bindv6only. Ако профилът казва udp, а сокетът е IPv4, клиентите, чийто резолвер връща само AAAA запис, се провалят, преди тунелът изобщо да бъде договорен.

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

Кога принудителното семейство е правилно

Заковаването на proto udp4 подхожда на внедряване само с IPv4: DNS име само с A, правила на защитна стена за един v4 адрес, клиенти зад оператори, които дават само v4 адреси. Това премахва двусмислието и прави следващия набор редове в дневника предвидим.

Същият аргумент работи в обратна посока за среда с приоритет на IPv6, а udp6 пред база клиенти само с A е самонанесено прекъсване. Принудително семейство само за да се заглуши безвредно предупреждение е класическата версия на тази грешка, защото сте сменили кой може да се свързва в замяна на по-спокоен дневник.

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

Дръжте записа тесен

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

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

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