OpenVPN AF_INET 경고: 무해한 대체인가, 실패한 소켓인가?
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 전용 배포에 어울립니다. A만 있는 DNS 이름, 하나의 v4 주소용 방화벽 규칙, v4 주소만 주는 통신사 뒤의 클라이언트입니다. 모호함이 없어지고 다음 로그 줄들이 예측 가능해집니다.
같은 논리는 IPv6 우선 환경에서는 반대로 작동하며, A만 있는 클라이언트 기반 앞에 udp6을 두는 것은 스스로 만든 장애입니다. 무해한 경고를 조용히 시키려고 패밀리를 강제하는 것은 이 실수의 전형적인 형태입니다. 더 조용한 로그를 얻는 대가로 누가 연결할 수 있는지를 바꾼 것이기 때문입니다.
끝점과 거기에 도달해야 하는 클라이언트를 기준으로 고르십시오. OpenVPN 2.6 설명서는 전송 방식을 문서화하며, 메시지는 그 선택의 출력이지 입력이 아닙니다.
기록을 좁게 유지하십시오
정확한 줄과 타임스탬프, 실행 중인 프로필의 실제 전송 설정, 커널이 보고하는 소켓, 그리고 실패한 다음 단계를 적으십시오. 이 네 가지면 메시지가 제기하는 거의 모든 질문이 정리되며, 어느 것도 무관한 서비스에 대한 추측을 필요로 하지 않습니다. 인수인계에서도 살아남는데, grep 스크린샷은 그렇지 않습니다.
이 경고와 함께 오는 패키지 제안은 오류가 빠진 실행 파일을 지목하기 전까지는 무관합니다.
ifconfig이 정말 없다면 스크립트가 그것을 호출할 때 데몬이 이름을 대고 말합니다. 그것은 별도의 조사가 필요합니다. AF_INET 줄과 없는 유틸리티는 다른 실패이며, 경고가 바뀌는지 보려고 무언가를 설치하는 것은 깨끗한 호스트가 지저분해지는 길입니다.