pfSense OpenVPN: 다른 라우터 뒤에 있는 네트워크에 도달하기

노트북은 VPN을 통해 pfSense LAN에 도달하지만 두 홉 더 안쪽에 있는 서비스에는 여전히 도달하지 못하며, 차이는 소유자마다 하나의 라우팅 결정입니다. 패킷이 왕복을 마치려면 클라이언트, 방화벽, 그리고 대상 네트워크를 실제로 소유한 라우터, 이 세 장치가 합의해야 합니다. 이 중 하나라도 빠지면 증상은 똑같아 보입니다.

규칙을 바꾸기 전에 소유자마다 제어 방식과 실패 방식이 다르므로 한 패킷을 이 세 가지 결정을 통해 따라가 보세요.

패킷 하나, 라우팅 결정 세 가지

클라이언트는 푸시된 경로, 로컬 경로, 또는 이미 모든 것을 포함하는 기본 경로라는 자기가 아는 것만으로 대상이 터널에 속하는지 결정합니다. pfSense는 패킷을 다음에 어디로 보낼지 결정하며, 다른 라우터 뒤의 네트워크에서는 올바른 인터페이스의 도달 가능한 게이트웨이를 통한 정적 경로를 뜻합니다. 하위 라우터는 VPN 풀로 돌아가는 경로를 아는지 결정하고, 모르면 응답은 버려지거나 쓸모없는 곳으로 보내집니다. 각 결정은 나머지 둘과 독립적입니다.

어느 하나가 실패해도 사용자 보고는 같습니다. 그래서 디버깅 순서가 도구보다 중요합니다.

클라이언트에 추측이 아니라 프리픽스를 주세요

IPv4 터널 네트워크가 /30보다 큰 pfSense SSL/TLS 서버에서 IPv4 Local network(s) 필드는 클라이언트가 연결할 때 경로를 배포합니다. 클라이언트가 알아서 만들리라 기대하지 말고 하위 프리픽스를 거기에 추가하세요. 그런 다음 연결 후에는 route-nopull이 있는 프로필이나 경로 필터가 서버가 보낸 것을 무시할 수 있으므로 클라이언트의 실제 테이블을 읽으세요. 서버가 완벽히 맞아도 클라이언트가 아무것도 설치하지 않을 수 있습니다.

다른 서버 모드와 토폴로지는 제한이 다르고, 클라이언트별 또는 연결별 정책이 특정 클라이언트가 받는 것을 바꿀 수 있습니다. 우연히 먼저 테스트한 클라이언트가 아니라 중요한 클라이언트에서 확인하세요.

pfSense를 내부 라우터로 향하게 하세요

pfSense의 정적 경로에는 정의되고 도달 가능한 게이트웨이가 필요하며, 그 게이트웨이에 선택한 인터페이스는 실제로 거기에 도달하는 인터페이스여야 합니다(Netgate의 정적 경로 안내서가 그렇게 설명합니다). 예시 배치에서 전송 링크는 방화벽 쪽 192.168.77.1, 내부 라우터 쪽 192.168.77.2이고, 서비스 네트워크는 그 뒤의 172.16.30.0/25입니다. 경로는 프리픽스와 다음 홉을 지정하지 서비스 주소를 지정하지 않습니다. 원격 네트워크의 주소를 게이트웨이로 쓰는 것은 올바르게 보이지만 아무 데도 전달하지 않는 경로를 만드는 흔한 방법입니다.

인터페이스에 이름을 붙인다고 그 뒤의 네트워크가 설명되지는 않습니다. 정적 경로가 그 설명입니다.

먼 쪽은 풀을 알아야 합니다

하위 라우터에는 기본 경로나 동적 프로토콜이 이미 제공하지 않는 경우, 풀에 대한 반환 경로(이 예에서는 192.168.77.1을 거치는 10.55.0.0/24)가 필요합니다. 서비스 호스트 자체의 게이트웨이는 그 라우터를 향해야 하며, 라우터가 기본 게이트웨이일 때는 보통 맞고 호스트를 수동으로 구성했을 때는 아닙니다. 방화벽의 정책 기반 라우팅도 특정 트래픽에 대해 테이블을 덮어쓸 수 있으므로, 경로가 틀렸다고 결론 내리기 전에 규칙이 다른 게이트웨이를 선택하는지 확인하세요.

이 설계에는 번역이 필요 없으며, 클라이언트의 소스 주소를 보이게 두면 하위 네트워크가 자체 정책을 적용할 수 있습니다.

승인을 위해 새 요청 하나를 터널 진입, 방화벽의 내부 송출, 대상에서 오는 응답까지 따라가세요. 대신 번역을 의도적으로 사용한다면 하위 네트워크가 보는 소스와 응답이 어떻게 돌아올 것으로 예상하는지 기록하세요.

세 소유자의 계획을 허용된 애플리케이션과 함께 저장하여, 다음 관리자가 경로를 다시 발견하는 대신 재구성할 수 있게 하세요.