UFW 규칙으로 OpenVPN 게이트웨이를 하나의 LAN에 한정하기

방화벽 파일을 열기 전에 허용 범위를 정하십시오. 인증된 클라이언트는 특정 서브넷 하나로만 연결을 열 수 있고, 게이트웨이는 클라이언트가 추가 경로를 설치하더라도 다른 모든 통과 경로를 거부해야 합니다. 그 문장이 설계이며, 아래의 모든 규칙은 그것을 강제하기 위해 존재합니다. 더 넓은 무언가, 예를 들어 사설 주소 공간 전체나 터널을 통한 인터넷 출구, 피어 간 통신은 별도의 결정이 필요한 다른 설계입니다. 규칙은 일부러 지루하게 만들었습니다. 영리한 방화벽이란 나중에 아무도 감사할 수 없는 방화벽이기 때문입니다.

먼저 토폴로지와 허용 범위를 적으십시오

예제는 사용자 공간의 TUN 장치를 라 부르는 Community OpenVPNtun0 서버와, 클라이언트 풀 10.77.0.0/24, 그리고 연결된 서브넷 하나 192.168.60.0/24 를 lan0 에 두고 씁니다. IPv4 전달은 이미 동작하고 LAN에는 풀로 돌아가는 경로가 이미 있으므로, 여기서 어떤 것도 둘 사이의 변환에 의존하지 않습니다.

이 호스트의 방화벽은 UFW가 소유하며, 어떤 컨테이너 규칙 집합이나 별도 nftables 표도 더 이른 허용 경로를 넣을 수 없습니다. 필터를 건너뛰는 흐름 오프로드 지름길이 있으면 보호 체인은 장식이 되므로, 어느 것도 활성화되어 있지 않은지 확인하십시오. OpenVPN 자체의 client-to-client 전달은 꺼 둡니다. 운영 체제 필터를 결코 지나지 않는 피어 간 통신 은 그것으로 한정할 수 없기 때문입니다. 외부 수신자와 관리 규칙은 그대로 둡니다. 이 변경은 방화벽을 교체하는 것이 아니라 복호화된 터널 통신을 다루기 때문입니다.

보호를 UFW의 초기 허용보다 앞에 두십시오

경로 허용 뒤에 거부를 두는 것만으로는 엄격한 경계가 되지 않습니다. 기본 before 규칙은 어떤 사용자 규칙을 보기도 전에 이미 성립한 통신과 일부 ICMP를 허용하므로, 지난주에 허용된 흐름은 단지 상태가 남아 있다는 이유만으로 새 목적지 제한 밖에 머물 수 있습니다. UFW 파일을 백업하고 편집 전에 대역 밖 콘솔을 열어 두십시오.

파일 *filter 의 /etc/ufw/before.rules 구역에서 기존 선언 옆에, 그리고 어떤 규칙 줄보다도 앞에 체인 두 개를 선언하십시오.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

선언 직후, 그리고 입력과 전달 허용보다 앞에서 그 안으로 뛰어들어 무엇을 통과시키는지 정의하십시오.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

구역의 나머지와 COMMIT 줄은 그대로 둡니다. 두 번째 필터 표를 붙여 넣거나 관계없는 규칙을 지우는 것이 방화벽 변경을 장애로 만드는 길이며, 그 파일은 재부팅 한 번이면 중요한 유일한 사본이 됩니다.

각 보호가 무엇을 통과시키고 거부하는지 읽으십시오

첫 번째 체인은 출발지가 풀 안에 있고, 목적지가 그 하나의 서브넷이며, 나가는 인터페이스가 LAN이고, 패킷이 흐름의 원래 방향으로 갈 때만 처리를 계속합니다. 터널에서 오는 나머지는 모두 버려집니다. 풀 밖의 출발지와 허용된 서브넷 너머의 목적지도 포함됩니다.

피어 간 패킷은 tun0 으로 들어와 나가므로, 목적지 검사에 이르기도 전에 LAN 인터페이스 시험에서 떨어집니다. LAN에서 클라이언트로 가는 새 연결도 응답 방향 시험에서 떨어지며, 이는 기본적으로 역방향 콜백 경로를 닫습니다.

RETURN 대상은 평소의 UFW 정책을 그대로 살려 둡니다. 이 체인들은 필터이고, 다음에 추가하는 경로 허용이 살아남은 패킷을 받을지 여전히 결정합니다. 그 분리가 있기에 나중에 허용 서브넷을 한 곳에서 바꿀 수 있습니다. 보호가 패킷을 곧바로 받아들였다면 앞으로의 모든 규칙을 두 번씩 추가해야 했을 것입니다.

서브넷을 허용하고 옆문을 닫으십시오

먼저 경로 허용을 미리 보고, 적용하려면 미리보기 표시를 떼십시오: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. 그다음 사용자 규칙의 순서를 검토하십시오. 앞선 거부는 여전히 뒤의 허용을 이깁니다. 서브넷 전체에 대한 허용도 한 호스트의 HTTPS 포트 만 닿아야 할 때에는 잘못된 형태입니다.

입력 버리기가 무엇을 하는지 보십시오. 터널 클라이언트는 게이트웨이 자체의 어떤 서비스에도 닿지 못합니다. LAN 주소에 묶인 DNS 수신자도 포함됩니다. 거기에 DNS를 두려면 버리기 전에 의도한 예외와 다시 검토한 허용 계약이 필요합니다. UFW가 IPv6를 관리한다면 tun0 에 대한 같은 버리기를 before6.rules 에도 더하십시오. IPv4 목적지 목록은 IPv6 패킷에 대해 아무 말도 하지 않기 때문입니다.

미리보기가 아니라 적재된 정책을 확인하십시오

다시 읽기를 미리 보고, 유지보수 창에서 적용하고, 실제 규칙 집합을 읽으십시오.

sudo ufw --dry-run reload
sudo ufw show raw

터널 보호가 기본 상태 허용과 ICMP 허용보다 앞에 나타나는지 확인하십시오. 순수한 ufw status 는 손으로 고친 before 규칙을 보여 주지 않으므로, 운영자는 규칙이 빠졌다고 결론을 내리지만 실제로는 적재되어 있습니다. 조각을 찾는 대신 생 목록을 위에서 아래로 읽으십시오. 보호가 상태 허용 뒤에 나타난다면 경계는 파일이 말하는 대로 동작하지 않습니다.

그다음에는 문구가 아니라 동작을 시험하십시오. 허용된 호스트로 새 연결을 열어 응답을 보십시오. 서브넷 밖 목적지로 무해한 요청을 보내 닿지 않는지 확인하십시오. 피어 간 연결을 시도하고, 게이트웨이 안의 서비스를 시도하고, 요청하지 않은 LAN에서 클라이언트로의 연결을 시도하십시오. 변경 전에 있던 범위 밖 흐름 하나를 포함시키고, 기계의 추적 표 전체를 비우는 대신 그 흐름만 지우십시오.

한계도 규칙 옆에 기록하십시오. 이것이 제한하는 것은 통과이며 그 밖의 것은 아닙니다. 클라이언트가 자기 인터넷 연결을 쓰는 것을 막지 않고, 허용된 LAN 호스트가 통신을 더 멀리 중계하는 것도 막지 않으며, 허용된 서비스 안의 인증을 대신하지도 않습니다.