OpenVPN 클라이언트 뒤의 서브넷에 연결할 수 없는 이유는 무엇인가?

서버의 터널 주소로 보내는 ping은 성공하고, 클라이언트 자체의 라우팅 테이블도 올바르게 보이지만, 그 클라이언트 뒤의 LAN은 여전히 연결할 수 없습니다. 클라이언트의 라우팅 테이블은 올바르게 보이고, 서버에는 터널을 향하는 경로가 있으며, 패킷은 여전히 사라집니다. 이것은 클라이언트 중 하나가 게이트웨이이기도 하다는 사실을 모르는 layer-3 터널의 전형적인 증상입니다.

tun 인터페이스에는 클라이언트별 다음 홉이 없습니다. 커널은 많은 피어를 가진 단일 인터페이스를 보므로, 원격 LAN용 패킷을 어느 클라이언트가 받을지에 대한 결정은 OpenVPN 프로세스 내부에서 내려야 합니다. 그 결정은 iroute로 구성되며, 그것이 없으면 패킷이 갈 곳이 없습니다.

서버는 인터페이스가 아니라 클라이언트 단위로 라우팅한다

서버가 클라이언트의 터널 주소로 패킷을 보내야 할 때 답은 명확하며, 그 주소는 해당 클라이언트의 세션에 속합니다. 목적지가 그 클라이언트 뒤의 전체 서브넷이면 주소는 서버가 아는 누구의 것도 아니며, 커널의 터널 경로는 "이 인터페이스로"라고만 말하고 어느 피어인지는 말하지 않습니다.

OpenVPN은 목적지 프리픽스를 특정 클라이언트에 매핑하는 내부 라우팅 테이블로 이를 해결합니다. 그 테이블은 iroute 항목으로 만들어지므로 서버 호스트의 일반 경로로는 충분하지 않습니다. 커널 경로는 패킷을 터널 인터페이스까지 가져가고, 내부 매핑이 어느 세션이 그것을 받을지 결정합니다. 그래서 수정 사항이 커널의 경로 출력에 절대 나타나지 않습니다.

매핑이 없으면 패킷은 서버에 도착해 터널 경로와 일치하지만, 어떤 클라이언트도 목적지를 주장하지 않으므로 버려집니다. 아무것도 명확한 오류를 기록하지 않으므로, 실패는 라우팅 루프가 아니라 조용한 블랙홀처럼 보입니다.

클라이언트를 지정하는 iroute 항목 작성

iroute는 서버의 기본 구성이 아니라 클라이언트별 구성 파일에 있습니다. client-config-dir 옵션으로 서버를 디렉터리로 지정한 다음, 이름이 클라이언트 인증서의 공통 이름인 파일을 만들고 그 안에 프리픽스를 넣습니다.

LAN이 10.20.0.0/24이고 인증서 공통 이름이 branch-router인 지사의 경우, 그 경로의 파일에는 iroute 10.20.0.0 255.255.255.0 같은 줄이 들어 있습니다. 기본 구성에는 디렉터리 옵션만 필요하며, 프리픽스는 클라이언트 쪽에 있습니다.

공통 이름이 취약한 부분입니다. 다른 subject로 발급된 인증서나, 파일은 인증서 이름인데 사용자 이름으로 사용자를 인증하는 배포에서는 절대 읽히지 않는 파일이 생깁니다. 서버가 세션에 대해 실제로 보고하는 이름을 확인하고, 일치하지 않는 클라이언트가 경로 없이 조용히 연결되는 대신 실패하게 하는 옵션을 고려하십시오. 파일 이름을 인증서에 맞게 바꾸는 것은 매우 긴 저녁을 막는 오 분짜리 수정입니다.

한 클라이언트가 여러 프리픽스를 가질 수 있습니다. 네트워크마다 iroute 줄을 하나씩 추가하고, 매핑을 감사 가능하게 유지하려면 목록을 해당 클라이언트의 나머지 설정 옆에 두십시오.

양방향 반환 경로 구축

원격 LAN으로 패킷을 가져가는 것이 절반의 작업입니다. 클라이언트는 그 LAN의 트래픽도 터널로 보내야 하며, 보통 클라이언트에 경로를 푸시하여 수행하며, push "route 10.8.0.0 255.255.255.0" 같은 줄이 각 클라이언트에 서버 측 네트워크에 도달하는 방법을 알려 줍니다. 지사의 경우 동등한 경로가 서버 측에서 도달해야 할 모든 것에 터널을 가리킵니다.

반환 방향에는 먼 쪽의 소유자가 필요합니다. 그쪽에서는 누군가 돌아가는 길을 알아야 하며, 그것은 VPN 풀을 서버로 향하게 하는 LAN 라우터의 정적 경로, 또는 트래픽이 LAN으로 들어가기 전 서버의 주소 변환입니다. 정적 경로는 원래 주소를 로그와 액세스 규칙에서 볼 수 있게 유지하지만 LAN 소유자의 협력이 필요하고, 변환은 자급자족이지만 실제로 누가 연결했는지를 숨깁니다.

서버 호스트에서 포워딩이 활성화되어 있어야 합니다. 이것이 없으면 커널은 터널에서 패킷을 받아 LAN 인터페이스로 넘기기를 거부하며, 이는 클라이언트 관점에서 iroute 누락과 똑같이 보입니다.

올바른 프로브로 도달 가능성 확인

먼 쪽에 ping을 보내고 추측하는 대신 계층별로 테스트하십시오. 서버에서는 프리픽스에 대한 내부 매핑이 있고 커널 경로가 터널을 가리키는지 확인합니다. 클라이언트에서는 푸시된 경로가 설치되어 있고 LAN 주소에 대한 기본 경로가 터널인지 확인합니다.

그다음 패킷을 관찰합니다. 터널 인터페이스에서의 캡처는 서버가 클라이언트 쪽으로 전송하는지 보여 주고, LAN 인터페이스에서의 캡처는 포워딩하는지 보여 줍니다. 첫 번째가 패킷을 보여 주고 두 번째가 아무것도 보여 주지 않으면 문제는 포워딩이나 필터이고, 둘 다 아무것도 보여 주지 않으면 검색은 더 일찍 실패했습니다.

터널로 연결된 두 서버는 양쪽에서 같은 규칙을 반복하며, 각각 상대의 풀에 대한 iroute가 필요하고, 경로를 대칭으로 만드는 경로와 포워딩이 필요합니다. 여기서 라우팅과 정책은 별개의 문제입니다. 라우팅은 패킷이 어디로 갈 수 있는지 결정하고, FORWARD 규칙은 허용되는지 결정하므로, iroute 줄이 두 개인 클라이언트는 필터가 달리 말하지 않는 한 두 프리픽스 모두에 도달할 수 있습니다.