두 OpenVPN 패킷 경로를 위한 Shorewall 존
암호화된 OpenVPN 전송을 복호화된 클라이언트 트래픽과 분리하고, 터널에 자체 존을 부여하며, 클라이언트가 필요로 하는 단 하나의 서비스만 허용합니다.
두 패킷 흐름이 OpenVPN을 종료하는 Shorewall 게이트웨이를 지나며, 그중 하나만 암호화되어 있습니다. 첫 번째는 인터넷 쪽 인터페이스의 VPN 리스너로 가는 클라이언트 전송입니다. 두 번째는 터널 인터페이스를 떠나는 복호화된 요청으로 사무실 서버나 게이트웨이의 서비스를 향합니다. 첫 번째를 만족하는 규칙은 두 번째에 아무것도 하지 않으므로 정책을 편집하기 전에 둘 다 그려 두십시오.
정책을 편집하기 전에 두 흐름을 그리십시오
흐름을 출발지, 목적지, 프로토콜, 포트가 있는 행으로 작성하십시오. 외부 경로에서 출발지는 클라이언트의 공인 주소이고 목적지는 게이트웨이의 수신 포트이며, Shorewall은 이를 인터넷에서 방화벽으로 가는 트래픽으로 취급합니다. 내부 경로에서 출발지는 터널 주소 범위이고 목적지는 승인된 서비스입니다. 한 관리자가 둘 다 유지하더라도 두 행의 소유자는 다릅니다.
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
요청이 게이트웨이 자체에서 끝날 때만, 예를 들어 리졸버나 관리 접근에 한해 행을 추가하십시오. 호스트의 서비스는 전달 경로가 아니라 호스트 입력 정책을 따릅니다. 이 둘을 섞는 것이 좁은 터널 규칙이 관리 인터페이스를 노출시키는 방식입니다.
터널 존과 인터페이스 범위를 지정하십시오
로드 워리어 존은 /etc/shorewall/zones에 선언하고, 터널 인터페이스는 /etc/shorewall/interfaces에 연결하며, 외부 연결은 /etc/shorewall/tunnels에 기술합니다. 열 순서와 옵션 이름이 주 버전 사이에서 바뀌었으므로 설치된 릴리스의 문법에 맞추십시오. 안내서의 예시 포트는 데몬이 실제로 수신하는 포트와 다른 포트를 허용할 이유가 아닙니다. 숫자가 같다는 이유만으로 TCP와 UDP가 서로 바뀔 수 있는 것은 아닙니다.
안내서는 tun+로 인터페이스를 묶습니다. 터널이 둘 이상인 호스트에서는 그 와일드카드가 다른 신뢰 수준의 두 번째 VPN을 같은 존에 둘 수 있습니다. 범위를 실제로 존재하는 인터페이스와 대조해 검토하고, 인터페이스 이름을 직접 편집하는 대신 명명을 연결 관리자의 수명 주기에 맡기십시오.
역사적인 안내서에는 훨씬 오래된 OpenVPN 구성 예시가 있으며, 그 암호화 조언을 현재 배포에 복사해서는 안 됩니다. 대신 존과 흐름 모델을 빌리십시오. 암호 기준은 게이트웨이에서 유지 관리되는 OpenVPN 정책에서 가져오십시오.
분류한 경로만 허용하십시오
VPN 존에서 LAN으로의 넓은 허용은 출발점 도식이며 완성된 정책이 아닙니다. 허용할 클라이언트 출발지, 실제 서비스 주소, 프로토콜과 포트를 작성하십시오. 좁은 추가는 이미 일치하는 넓은 허용을 취소하지 않으므로, 그 위의 규칙과 존 기본값도 읽으십시오. 게이트웨이 호스트로 가는 트래픽은 그것을 통해 전달되는 트래픽과 별개의 관계입니다.
클라이언트 간 트래픽에는 자체 결정이 필요합니다. OpenVPN의 client-to-client와 Shorewall의 routeback은 모두 클라이언트가 서로 도달할 수 있는지에 영향을 주며, LAN 응용 프로그램 하나를 동작시키기 위해서만 어느 것도 활성화해서는 안 됩니다. 격리가 어디에서 적용되는지 시험하기 전에 결정하십시오.
응답 경로를 같은 계획에 두십시오. 서비스나 그 라우터가 트래픽을 터널 범위로 되돌리는 방법을 알아야 하며, 그렇지 않으면 설계가 의도된 범위 안에서 출발지를 명시적으로 변환해야 합니다.
검증한 다음 두 경로를 모두 입증하십시오
무엇이든 다시 시작하기 전에 구성을 검증하고, 새 정책이 틀릴 경우를 대비해 독립적인 관리 세션을 열어 두십시오.
shorewall check깨끗한 검사 후 구성을 적용하고 Shorewall이 로드한 내용을 다시 읽으십시오. 이 읽기는 파일이 말하는 것처럼 보이는 것이 아니라 실행 중인 정책을 설명합니다.
shorewall show zones
ip route get 192.168.10.20같은 클라이언트에서 새로 허용된 요청 하나와 의도적으로 거부된 요청 하나를 시험하십시오. 성공한 OpenVPN 핸드셰이크는 외부 교환만 증명하고, 허용된 서비스와 거부된 리소스가 의도한 내부 정책을 증명합니다. 터널 인터페이스의 이름과 주소는 세션 사이에 바뀔 수 있으므로 그런 다음 클라이언트를 다시 연결해 반복하십시오. 결과가 다르면 규칙을 넓히지 말고 존 범위를 고치십시오.