VPN 클라이언트와 LAN: 별도 영역을 써야 할 때

터널 인터페이스를 LAN 영역에 넣는 것은 작동하는 VPN으로 가는 가장 짧은 길이며, 보통은 잘못된 기본값입니다. 그것은 원격 클라이언트에게 유선 LAN과 같은 신뢰를 주지만, 작업이 그런 것을 요구하는 경우는 드뭅니다. 별도 영역은 규칙 몇 개의 비용이 들고 경계를 눈에 보이게 합니다. 결정할 것은 영역이 더 좋은지가 아니라, 세 가지 조건 중 무엇이 당신의 네트워크에 해당하는가입니다.

영역 이름은 아무것도 암호화하지 않고 사용자를 인증하지도 않습니다. 방화벽의 정책 모델을 위해 인터페이스를 묶을 뿐입니다.

영역 소속이 실제로 제어하는 것

영역은 방화벽 모델 안에서 인터페이스나 트래픽을 묶습니다. 그다음 입력, 출력, 포워딩 설정이 서로 다른 역할을 관장합니다. 입력은 라우터 자체로 가는 트래픽이고, 포워딩은 그것을 지나 다른 호스트로 가는 트래픽입니다. OpenWrt의 영역 문서가 입력, 출력, 포워딩을 별도 설정으로 다루는 것은 바로 이 때문입니다.

VPN 영역에서 LAN 영역으로의 허용은 자동으로 반대 방향 허용이 되지 않습니다. 포워딩 규칙은 방향성을 가지며, 클라이언트에서 서버로의 트래픽을 허용하는 규칙이 서버에서 클라이언트로의 세션을 허용하지는 않습니다. 서버로 연결을 열 수 있는 클라이언트가, 서버가 거꾸로 연결을 열 수 있는 클라이언트는 아닙니다.

이 구분이 별도 영역을 유용하게 만드는 이유입니다: 방향과 역할을 각각 명시할 수 있기 때문입니다. 방향은 모든 규칙 옆에 적으십시오.

첫 번째 결정: 입력, 포워딩, 아니면 둘 다

원격 클라이언트가 라우터에서 DNS를 받아야 한다면 그 서비스에만 입력을 허용하십시오. 파일 서버에 도달해야 한다면 그 목적지로의 포워딩을 허용하십시오. 대부분의 VPN 설계는 둘 다 필요하지만, 서로 다른 서비스에 대해 그렇습니다.

모든 로컬 서비스에 대한 넓은 입력 접근은 거의 필요하지 않습니다. 라우터 관리를 응용 프로그램 접근과 별개의 결정으로 다루십시오. 라우터가 DNS에만 응답하면 된다면 그 하나의 허용만 적고 나머지는 닫아 두십시오.

두 번째 결정: 원격 클라이언트에 필요한 자원

규칙을 쓰기 전에 클라이언트 범위, 목적지, 그리고 VPN이 제공해야 할 서비스를 나열하십시오. 목적지 목록은 방화벽 이전을 견디기 때문에 신뢰 라벨보다 유용합니다.

관리 인터페이스는 일반 응용 프로그램 접근과 분리해 두십시오. 위키에 도달하는 원격 클라이언트가 그렇다고 해서 라우터의 관리 페이지나 하이퍼바이저 콘솔이 필요한 것은 아닙니다.

허용된 목적지가 더 앞으로 전달할 수 있다면, 영역 경계는 방화벽에서 멈추며 목적지가 그다음에 하는 일까지 미치지 않습니다.

세 번째 결정: 경계를 어떻게 증명할 것인가

변경할 때마다 허용된 흐름과 의도적으로 거부된 흐름을 시험하십시오. 웹사이트 하나가 열린다는 증명은 의도하지 않은 넓은 허용을 드러내지 않습니다. LAN이 아니라 VPN 클라이언트의 주소 범위에서 시험하고, 실패를 예상하는 방향도 포함하십시오. 두 결과를 규칙 옆에 기록하십시오.

원격 영역 정책을 바꾸기 전에 게이트웨이의 복구 접근을 보존하십시오. 실행 중 편집 대신 지속적인 관리 구성을 사용하지 않으면 다음 재부팅이 옛 신뢰를 되돌립니다. 이전 구성의 사본을 장치 밖에 보관하는 것이 가장 싼 되돌리기입니다.

네트워크가 커지면 소속과 규칙의 목적을 문서화하십시오. 새로 연결된 인터페이스가 누군가 편한 영역 이름을 주었다는 이유만으로 권한을 물려받아서는 안 됩니다.