Ostrzeżenie AF_INET OpenVPN: nieszkodliwe przejście awaryjne czy nieudany socket?

Dwie linie dziennika OpenVPN zaczynają się tymi samymi słowami i tylko jedna z nich zgłasza problem. Could not determine IPv4/IPv6 protocol. Using AF_INET to komunikat o przejściu awaryjnym: profil pozostawił rodzinę adresów otwartą, więc demon wybrał jedną i kontynuował. Gałąź błędu zgłasza, że nie utworzono socketu, i żąda restartu. Wszystko po wspólnym prefiksie je rozdziela, więc czytaj dalej, zanim cokolwiek zmienisz.

Co zgłasza komunikat o przejściu awaryjnym

OpenVPN akceptuje jawną rodzinę przez proto udp4 lub proto udp6, a akceptuje proto udp, gdy rodzina ma być wyprowadzona przy starcie. W drugim przypadku demon sprawdza lokalne informacje o powiązaniu i wybiera.

Gdy to wyprowadzenie działa, ostrzeżenie wskazuje kierunek, a proces kontynuuje tworzenie socketu. Serwer z proto udp na hoście z podwójnym stosem często trafia w ten sposób na IPv4. Nic na tej ścieżce nie jest błędem i nic w niej nie sugeruje ataku, brakującego serwera WWW ani odrzuconego konta. Linia jest przydatna tylko dlatego, że późniejsze kontrole należy porównywać z rodziną, którą wymienia.

Traktuj to jako odpowiedź na jedno pytanie, a nie diagnozę. Mówi, którą rodzinę wybrał ten proces, i nic o tym, dlaczego klient nie może się połączyć.

Jak wygląda gałąź błędu

Później w tym samym kodzie socketu istnieje gałąź, w której nie ma żadnego socketu. Zapisuje krótszy komunikat o rodzinie adresów i żąda restartu, bo nie zostało nic do kontynuowania. Początkowe słowa zgadzają się z przejściem awaryjnym; wynik nie.

Odróżnij je po tym, co następuje. Jeśli demon nadal działa i zgłasza swój nasłuch, linia była informacją. Jeśli kończy pracę lub restartuje się w pętli, rozmowa dotyczy teraz powiązania.

Trafienie w grep też nie identyfikuje gałęzi. Fraza pojawia się w rotowanych podsumowaniach, w zawiniętych liniach i w wycinkach dziennika, które ludzie wklejają z drugiej ręki, więc czytaj sąsiednie linie i kolejność znaczników czasu, a nie pojedyncze dopasowanie.

Sprawdź nasłuchującego, a nie ostrzeżenie

Działający serwer odpowiada na pytanie o rodzinę bezpośrednio, bez wnioskowania z tekstu dziennika.

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

Dopasuj rodzinę, adres i port do profilu. Linia 0.0.0.0:1194 to tylko IPv4, a linia [::]:1194 na hoście z podwójnym stosem może akceptować obie rodziny w zależności od ustawienia bindv6only. Jeśli profil mówi udp, a socket jest IPv4, klienci, których resolwer zwraca tylko rekord AAAA, zawiodą, zanim tunel zostanie w ogóle wynegocjowany.

Następnie przetestuj z klienta przypominającego twoich użytkowników: ta sama ścieżka resolwera, ten sam rodzaj sieci. Połączenie lokalne z serwera dowodzi bardzo niewiele o ruchu, który przechodzi przez urządzenie NAT albo regułę zapory napisaną dla drugiej rodziny.

Kiedy wymuszenie rodziny jest właściwe

Przypięcie proto udp4 pasuje do wdrożenia tylko IPv4: nazwa DNS tylko A, reguły zapory dla jednego adresu v4, klienci za operatorami, którzy dają tylko adresy v4. To usuwa niejednoznaczność i czyni następny zestaw linii dziennika przewidywalnym.

Ten sam argument działa odwrotnie w środowisku z IPv6 na pierwszym miejscu, a udp6 przed bazą klientów tylko A to samodzielnie spowodowana przerwa. Wymuszanie rodziny tylko po to, by uciszyć nieszkodliwe ostrzeżenie, jest klasyczną wersją tego błędu, ponieważ zmieniłeś to, kto może się połączyć, w zamian za spokojniejszy dziennik.

Wybieraj na podstawie punktów końcowych i klientów, którzy muszą do nich dotrzeć. Podręcznik OpenVPN 2.6 dokumentuje formy transportu, a komunikat jest wynikiem tego wyboru, nie jego wejściem.

Trzymaj zapis wąski

Zapisz dokładną linię z jej znacznikiem czasu, efektywne ustawienie transportu z działającego profilu, socket tak, jak go zgłasza jądro, oraz następny etap, który zawiódł. Te cztery elementy rozstrzygają prawie każde pytanie, które budzi komunikat, i żaden z nich nie wymaga zgadywania o niepowiązanych usługach. Przetrwają też przekazanie, czego zrzut ekranu z grepa nie robi.

Sugestie pakietów, które przychodzą razem z tym ostrzeżeniem, są niepowiązane, dopóki błąd nie wymieni brakującego pliku wykonywalnego.

Jeśli ifconfig naprawdę brakuje, demon mówi to po nazwie, gdy skrypt go wywoła, i to zasługuje na własne dochodzenie. Linia AF_INET i brakujące narzędzie to różne błędy, a instalowanie rzeczy, by zobaczyć, czy ostrzeżenie się zmieni, jest drogą, którą czysty host staje się nieuporządkowany.