OpenVPN AF_INET-varning: ofarlig återgång eller misslyckad socket?

Två OpenVPN-loggrader börjar med samma ord, och bara en av dem rapporterar ett problem. Could not determine IPv4/IPv6 protocol. Using AF_INET är ett återgångsmeddelande: profilen lät adressfamiljen vara öppen, så daemonen valde en och fortsatte. Felgrenen rapporterar att ingen socket skapades och begär en omstart. Allt efter det gemensamma prefixet skiljer dem, så läs förbi det innan du ändrar något.

Vad återgångsmeddelandet rapporterar

OpenVPN accepterar en explicit familj via proto udp4 eller proto udp6, och accepterar proto udp när familjen ska härledas vid start. I det andra fallet granskar daemonen den lokala bind-informationen och väljer.

När den härledningen fungerar anger varningen vilken väg det gick och processen fortsätter att skapa socketen. En server med proto udp på en värd med dubbla stackar hamnar ofta på IPv4 på detta sätt. Inget på den vägen är ett fel, och inget i den antyder en attack, en saknad webbserver eller ett avvisat konto. Raden är bara användbar eftersom senare kontroller bör jämföras med den familj den namnger.

Behandla det som ett svar på en fråga, inte som en diagnos. Den säger vilken familj den här processen valde, och ingenting om varför en klient inte kan ansluta.

Hur felgrenen ser ut

Senare i samma socket-kod finns en gren där ingen socket existerar alls. Den loggar det kortare adressfamiljmeddelandet och begär en omstart, eftersom det inte finns något kvar att fortsätta med. Inledningsorden stämmer med återgången; resultatet gör det inte.

Skilj dem efter vad som följer. Om daemonen fortsätter att köra och rapporterar sin lyssnare var raden information. Om den avslutas eller startar om i en loop handlar samtalet nu om bindningen.

En grep-träff är inte heller en identifiering av grenen. Frasen dyker upp i roterade sammanfattningar, i brutna rader och i loggutdrag som folk klistrar in från andra hand, så läs grannraderna och ordningen på tidsstämplarna i stället för den enda träffen.

Kontrollera lyssnaren i stället för varningen

En körande server svarar på familjefrågan direkt, utan slutsatser från loggtexten.

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

Matcha familj, adress och port mot profilen. En 0.0.0.0:1194-rad är bara IPv4, medan en [::]:1194-rad på en värd med dubbla stackar kan acceptera båda familjerna beroende på inställningen bindv6only. Om profilen säger udp och socketen är IPv4, kommer klienter vars resolver bara returnerar en AAAA-post misslyckas innan tunneln ens förhandlas.

Testa sedan från en klient som liknar dina användare: samma resolverväg, samma typ av nätverk. En lokal anslutning från servern bevisar väldigt lite om trafik som passerar en NAT-enhet eller en brandväggsregel skriven för den andra familjen.

När det är rätt att tvinga en familj

Att fästa proto udp4 passar en utrullning med bara IPv4: ett DNS-namn med bara A, brandväggsregler för en v4-adress, klienter bakom operatörer som bara delar ut v4-adresser. Det tar bort tvetydigheten och gör nästa uppsättning loggrader förutsägbar.

Samma argument gäller åt andra hållet för en miljö med IPv6 först, och udp6 framför en klientbas med bara A är ett självförvållat avbrott. Att tvinga en familj bara för att tysta en ofarlig varning är den klassiska versionen av detta fel, eftersom du har ändrat vem som kan ansluta i utbyte mot en lugnare logg.

Välj utifrån ändpunkterna och de klienter som måste nå dem. OpenVPN 2.6-handboken dokumenterar transportformerna, och meddelandet är resultatet av det valet, inte en indata till det.

Håll registreringen snäv

Skriv ned den exakta raden med dess tidsstämpel, den effektiva transportinställningen från den körande profilen, socketen så som kärnan rapporterar den, och nästa steg som misslyckades. De fyra punkterna avgör nästan varje fråga meddelandet väcker, och ingen av dem kräver gissningar om orelaterade tjänster. De överlever också en överlämning, vilket en skärmbild av en grep inte gör.

Paketförslag som kommer tillsammans med denna varning är orelaterade tills ett fel namnger en saknad körbar fil.

Om ifconfig verkligen saknas säger daemonen det vid namn när ett skript anropar det, och det förtjänar en egen undersökning. AF_INET-raden och ett saknat verktyg är olika fel, och att installera saker för att se om varningen ändras är vägen där en ren värd blir rörig.