MULTI: 클라이언트의 잘못된 원본 주소: 누구의 주소였나?
내부 원본이 이를 전달한 클라이언트와 일치하지 않습니다. 터널 할당, 클라이언트 뒤의 LAN, 또는 중복된 ID 중 어느 것인지 맞춰 보세요.
서버 로그는 MULTI: bad source address from client 를 출력하고 패킷을 버리지만 세션은 연결된 상태로 남습니다. 이 조합은 메시지를 인증 실패로 읽는 사람을 혼란스럽게 합니다. 그렇지 않으며, 클라이언트는 인증을 마쳤고, 도착한 패킷은 서버가 해당 클라이언트 인스턴스와 연결할 수 없는 내부 원본 주소를 담고 있었습니다. 검사는 전달 전에 이루어지므로, 터널은 정상으로 보이지만 그 안을 유용한 것이 지나가지 않습니다.
서버가 전달 전에 비교하는 것
클라이언트에서 오는 각 패킷마다 사용자 공간 서버는 터널 내부의 원본 주소를 보고 내부 라우팅 상태에 그 주소가 어느 클라이언트의 것인지 묻습니다. 소유자가 다른 인스턴스이거나 소유자가 전혀 없으면 패킷은 폐기되고 경고가 출력됩니다.
터널 인터페이스를 통한 일반적인 전달은 결코 일어나지 않습니다.
이 순서는 사람들을 당혹하게 하는 세부, 즉 패킷이 방화벽에 도달하지 않았기 때문에 호스트 방화벽의 카운터가 움직이지 않는다는 점을 설명합니다. 거부가 데몬 자체의 연결 검사에서 일어났기 때문에 호스트의 역경로 필터링을 조정해도 여기서는 아무것도 바뀌지 않습니다. 메시지를 소유권에 관한 진술로 읽고, 세 가지 상황 중 무엇이 그것을 만들었는지 찾아내세요.
일치하지 않는 내부 주소의 세 가지 출처
클라이언트는 할당받지 않은 주소에서, 아무도 자기 것이라고 선언하지 않은 네트워크에서, 또는 이미 소유자가 있는 ID의 복제본에서 보내고 있을 수 있습니다. 셋 모두 같은 로그 줄을 만듭니다. 차이는 무엇을 바꿔야 하는지에 있습니다. 주소와 현재 할당 목록에서 시작해, 그 두 사실이 사례를 고르게 하세요.
이들을 구분하려면 로그의 거부된 주소와 서버가 현재라고 보는 할당, 이 두 가지 사실이 필요합니다. 두 번째는 실행 중인 인스턴스의 상태 또는 관리 보기에서 얻을 수 있고, 설정 파일은 의도를 기록할 뿐 현재 상태가 아니기 때문에 참고할 가치가 있는 유일한 권위입니다.
무엇이든 바꾸기 전에 둘 다 기록한 다음 분류하세요. 나중에 찍은 스크린샷은 경고를 만든 상태의 기록이 아닙니다. 할당이 세션 사이에 이동하므로 타임스탬프도 보관하세요.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
클라이언트 뒤의 LAN과 iroute
사이트 클라이언트가 자체 사설 네트워크를 라우팅하면 그 네트워크는 클라이언트 소유로 선언되어야 합니다. iroute 항목이 있는 클라이언트별 파일이 그 역할을 하며, 항목은 클라이언트가 운반할 수 있는 접두사를 지정합니다.
같은 접두사를 터널로 향하게 하는 커널 경로는 별도의 요구 사항이며, 이를 추가해도 데몬의 내부 소유권은 달라지지 않습니다.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0유효 ID가 파일 이름과 일치하는지 확인하세요(일치하지 않으면 파일이 전혀 로드되지 않고 증상은 항목 누락과 같습니다). 경고를 잠재우려고 넓은 iroute를 추가하는 것은 예상치 못한 출처를 허용된 출처로 바꿀 뿐 클라이언트가 왜 보냈는지에는 답하지 않으므로 피하세요. OpenVPN 2.6 설명서는 iroute, duplicate-cn, ID 매핑을 별개의 제어로 설명합니다.
두 컴퓨터의 같은 ID
두 번째 노트북으로 복사한 프로필은 같은 인증서와 같은 공통 이름을 지닙니다. 서버 설정에 따라 더 새로운 연결이 이전 연결을 대체할 수 있고, 소유권을 가진 인스턴스가 연결 검사에서 이깁니다.
그래서 결함이 간헐적으로 보이고 두 기기가 모두 깨어 있을 때만 나타납니다.
중복 공통 이름을 허용하면 둘 다 연결할 수 있지만, 독립적인 고정 주소나 독립적인 소유권을 주지는 않습니다. 두 기기가 공존해야 한다면 각자 고유한 ID와 고유한 할당을 갖도록 따로 등록하세요. 중복 설정을 이 경고의 수리로 보면 수수께끼는 그대로 남고 하나가 더 생깁니다.
연결이 바뀌었음을 증명하세요
설정 소유자를 통해 수정을 적용한 다음, 새 정책이 로드되도록 영향을 받은 클라이언트를 다시 연결하세요.
같은 흐름을 반복하고 패킷의 내부 출처, 서버가 연결하는 클라이언트 인스턴스, 그리고 그 뒤의 목적지 동작, 이 세 가지를 확인하세요.
경고가 멈췄는데 애플리케이션이 여전히 실패한다면, 문제는 사라진 것이 아니라 옮겨 간 것입니다. 포워딩, 방화벽 규칙, 반환 경로는 별개의 단계이며, 연결 검사를 통과했다는 것은 패킷이 터널을 떠나도록 허용되었다는 뜻일 뿐입니다.