모든 것을 한 호스트로 전달할 것인가, 포트도 다시 쓸 것인가

모든 것을 VPN 서버로 전달한다는 말은 아주 다른 두 가지 규칙을 가리킬 수 있습니다. 하나는 목적지 주소를 바꾸고 들어오는 포트를 유지하며, 다른 하나는 포트도 단일 리스너로 다시 씁니다. 노출은 같지 않고, 결정은 라우터 화면이 쓰는 레이블이 아니라 세 가지 조건에 달려 있습니다.

첫 번째 조건: 규칙은 어떤 필드를 바꾸는가?

목적지 주소 변환과 목적지 포트 변환은 별개의 작업입니다. 규칙은 전자만 수행할 수도 있고 둘 다 함께 수행할 수도 있으며, 그 차이가 대상 호스트에서 어떤 서비스에 도달할 수 있는지를 결정합니다. 대부분의 벤더 화면은 그 선택을 하나의 레이블 뒤에 숨깁니다. 기반 규칙을 읽는 것만이 어느 쪽을 얻었는지 아는 유일한 방법입니다.

메뉴 레이블이 아니라 실제 규칙을 읽으십시오. DMZ 또는 모든 포트라고 표시하는 화면은 의도를 설명할 뿐 패킷 경로가 아닙니다. Netfilter NAT 문서는 두 변환을 구분하며, 앞에 있는 라우터가 소비자용 기기라 해도 이것이 올바른 사고 모델입니다.

두 필드, 두 가지 질문.

두 번째 조건: 유지된 포트에서는 무엇이 수신 대기하는가?

규칙이 들어오는 포트를 유지하면, 도착하는 모든 포트는 해당 호스트의 입력 정책에 따라 VPN 호스트의 같은 번호로 전달됩니다. 여기에는 수신 대기 중이라는 사실을 잊었을 수 있는 서비스도 포함됩니다. 규칙이 그 서비스를 만든 것은 아니며, 이제 규칙이 그 서비스로 가는 경로입니다.

규칙이 포트를 다시 쓰면 반대가 됩니다: 많은 외부 포트가 하나의 리스너로 모이고, 그 규칙을 통해 호스트의 다른 무엇에도 도달할 수 없습니다. 고정 포트로의 재작성은 넓은 외부 포트 범위가 일치했다는 이유만으로 모든 로컬 서비스에 대한 접근이 되지 않습니다. 두 설계는 서로 다른 방향으로 실패하며, 여러분이 고르는 것은 실패 방식입니다. 그 실패를 감당할 수 있는 쪽을 고르십시오.

고르기 전에 리스너를 목록화하십시오.

세 번째 조건: 외부 진입점은 얼마나 넓은가?

선택한 포트 하나를 게시하는 것은 범위를 게시하는 것보다 좁고, 둘 다 모든 것을 받아들이는 것보다 좁습니다. 외부 폭과 내부 변환은 독립적인 선택이며, 대부분의 혼란은 하나를 바꾸면서 다른 하나를 설명할 때 생깁니다.

일반적인 VPN 진입점이라면 설계가 실제로 필요로 하는 전송과 리스너를 게시하십시오. 그런 다음 세 가지를 더 검토하십시오: 라우터의 실제 매핑, 대상 호스트 자체의 입력 규칙, 그리고 IPv6 리스너가 같은 서비스를 게시하는지 여부입니다. 한 주소 체계에서 좁아 보이는 규칙이 다른 쪽에서는 넓을 수 있습니다.

변환된 엔드포인트를 완전히 적으십시오: 프로토콜, 외부 포트, 내부 주소, 내부 포트.

어느 규칙도 주지 않는 것

두 설계 모두 서비스에 취약점이 없다는 것을 증명하지 못하며, 어느 쪽도 가용성을 보호하지 않습니다. 인증, 업데이트, 복구는 포트 매핑이 아무리 좁아도 범위에 남습니다. 좁은 매핑은 도달 가능한 표면을 줄이지만 리스너를 안전하게 만들지는 않습니다.

이미 다른 정당한 서비스를 지원하는 넓은 규칙은 단순한 실수가 아니라 의존성이므로, 제거하기 전에 목록을 만들고 소유자를 통해 교체하십시오. 그렇지 않으면 변경이 보안 수정으로 인한 장애처럼 보일 것입니다. 같은 주의가 다른 무언가가 조용히 의존하는 고정 포트 재작성에도 적용됩니다.

노출 분석은 무엇이 무엇에 도달할 수 있는지에 관한 것이지 화면의 레이블에 관한 것이 아닙니다.

변환된 엔드포인트를 손에 들고 결정하십시오

규칙의 결과를 문장으로 적으십시오: 공용 UDP 포트 X가 주소 Y의 포트 Z에 도달합니다. 그런 다음 Y에서 어떤 서비스가 Z에 응답할 수 있고 누가 그것을 소유하는지 물으십시오.

nft list ruleset

답이 의도한 하나의 리스너라면 규칙은 제 역할을 하고 있습니다.

답이 여러 개라면 화면이 그렇게 불렀든 아니든 여러분은 호스트 전체 전달을 선택한 것입니다.