양쪽 끝이 같은 서브넷: 원격 LAN을 여유 대역으로 매핑하기

집과 사무실이 모두 192.168.1.0/24를 쓰므로 192.168.1.1로 가는 요청에는 답이 둘 있고 클라이언트는 묻지 않고 하나를 고른다. 운영 중인 사무실 네트워크를 다시 번호 매기는 일은 좀처럼 환영받지 못하며, 라우터 주소는 프린터와 카메라, 문서에 박혀 있는 경우가 많다. 클라이언트 측 주소 매핑을 쓰면 원격 네트워크를 대신 여유 대역 아래에 제시할 수 있고, 호스트 부분은 그대로 둘 수 있어 192.168.1.20이 10.203.41.20으로 보인다. 함정은 이를 구현한 클라이언트가 일부뿐이고, 반환 경로에는 아무것도 해 주지 않는다는 점이다.

같은 호스트의 두 가지 모습

매핑은 호스트 부분을 유지하고 네트워크 부분만 바꾼다. 그러면 같은 기기가 어디에 서 있느냐에 따라 두 주소로 응답한다. 무언가를 설정하기 전에 두 열을 모두 적어 두면 나중에 로그와 방화벽 규칙을 잘못 읽는 일을 막는다.

집의 로컬 기기는 자기 192.168.1.x 주소를 유지하며, 그것이 이 연습의 요점이다. 옆방의 프린터는 계속 접근 가능하고 사무실은 충돌하지 않는 대역 아래에 나타난다.

인자 순서가 이 모든 요령이다

이 옵션은 방향과 네트워크 및 마스크, 그리고 별칭을 받는데, 첫 번째 네트워크는 클라이언트가 보는 것이고 별칭은 서버가 보는 것이다. 원격 게이트웨이 뒤에 있는 자원에서는 방향이 목적지 형태다. 마지막 인자를 별칭이라고 부른다고 두 네트워크를 뒤집는 것이, 연결은 되지만 아무것도 매핑하지 않는 터널을 만드는 실수다.

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

경로는 새 대역에 대한 클라이언트 패킷을 터널로 보내는 것이고, 변환은 지나가는 길에 목적지를 다시 쓴다. 192.168.1.20에서 온 응답은 10.203.41.20으로 되돌려 쓰여 클라이언트의 소켓이 일관되게 유지된다. 단일 호스트도 전체 길이 마스크로 같은 방식으로 동작하며, 경로와 매핑이 같은 주소를 가리키기만 하면 된다.

이것은 주소 매핑이지 포트 매핑이 아니다. 한 호스트의 두 서비스를 이것으로 분리할 수 없고, IP 주소를 페이로드에 넣는 프로토콜은 여전히 실제 주소를 본다.

매핑은 반환 경로를 만들지 않는다

변환은 클라이언트에서 일어나므로 서버는 여전히 응답을 터널로 라우팅해야 하고 그 방화벽은 여전히 이를 허용해야 한다. 원격 게이트웨이가 터널 서브넷에 도달하는 방법을 모르면 요청은 도착하고 응답은 잘못된 문으로 나가며, 매핑은 실패를 클라이언트 문제처럼 보이게 할 뿐이다.

서버 측 규칙은 변환 후 서버에 존재하는 주소를 설명해야 하며, 클라이언트에 보이는 대역이 아니다. 별칭을 허용 규칙에 복사하는 것은 그쪽의 어떤 패킷도 별칭을 나르지 않기 때문에 오후를 낭비한다.

클라이언트가 라우팅하는 다른 무엇과도 충돌하지 않는 별칭 대역, 예컨대 다른 VPN, 컨테이너 네트워크, 두 번째 사무실을 고른다. 여기서 충돌하면 원래의 모호성이 다른 번호 아래 다시 생기고, 주소가 낯설어 보여 알아채기 어렵다.

이름과 페이로드는 변환을 견딘다

실제 192.168.1.20으로 해석되는 호스트 이름은 라우팅 테이블이 무엇이라 하든 브라우저를 원격이 아니라 로컬 기기로 보낸다. 사설 DNS 응답은 클라이언트에 보이는 대역을 가리켜야 하고, TLS 인증서는 여전히 애플리케이션이 기대하는 이름을 담는다. 주소는 동작해도 이름이 조용히 잘못된 방향으로 해석될 수 있으므로 주소가 아니라 이름으로 시험해야 한다. 원격 게이트웨이가 그 영역도 서비스한다면 그 자체의 레코드에도 클라이언트에 보이는 대역이 필요하다.

리디렉션, 포함된 URL, 자기 주소를 페이로드에 넘기는 애플리케이션은 어떤 패킷 매핑으로도 고칠 수 없는 방식으로 깨질 수 있다. 이것을 애플리케이션 문제로 다루고, 다시 번호 매기기가 불필요하다고 약속하기 전에 노력을 그에 맞게 산정한다.

확정하기 전 세 가지 확인

첫째, 클라이언트 구현을 확인한다. Community OpenVPN은 이 옵션을 지원하지만 OpenVPN 3 코드베이스는 이를 지원하지 않는 기능에 넣으므로 Connect 스타일 클라이언트에 밀어 넣은 프로필은 그냥 무시할 수 있다. 받아들여지고 한 번도 적용되지 않는 지시는 터널이 건강해 보이는 만큼 오류보다 나쁘다.

둘째, 높은 상세도의 짧은 진단 창으로 경로와 변환을 따로 확인한 다음 ping이 아니라 실제 서비스를 시험한다. 셋째, 그것이 원래 목표였으므로 로컬 라우터와 원격 자원이 클라이언트에서 구분되는지 확인한다.

클라이언트가 변환을 할 수 없다면 게이트웨이 쪽에 도움을 청하거나 다시 번호 매기기를 받아들인다. 같은 주소에 경로를 더 추가하는 것은 설계가 아니다.