iptables: VPN 클라이언트가 한 호스트에만 도달하게 하기

무관해 보이는 두 지원 티켓이 사실은 같은 원인을 공유합니다. 첫 번째에서 관리자는 서버가 터널에서 오는 연결만 받아들이길 원하고, 두 번째에서는 VPN 사용자가 내부 호스트 하나에만 도달해야 하고 그 이상은 안 됩니다. 두 정책 모두 FORWARD에 속하지만, 둘 다 보통 INPUT에서 시도됩니다. 결과는 방화벽처럼 보이지만 실제로는 자리 표시자처럼 동작합니다.

어느 체인이 질문에 답하는가

VPN 클라이언트가 LAN 호스트로, 또는 더 나아가 인터넷으로 보내는 패킷은 커널이 전달하며 FORWARD에서 평가됩니다. INPUT과 OUTPUT은 서버 자체에서 끝나거나 서버에서 시작되는 트래픽만 봅니다. 따라서 tun0으로 오지 않는 모든 것을 거부하는 규칙은 서버 자신의 리스너를 보호할 뿐이며, 설정된 흐름을 먼저 허용하지 않으면 SSH 세션도 끊어 버립니다. 클라이언트가 어디로 갈 수 있는지는 전혀 바뀌지 않습니다.

먼저 질문을 이름 붙이십시오: 누가 서버에 도달할 수 있는가, 아니면 클라이언트가 어디로 갈 수 있는가. 대부분의 네트워크는 두 답이 모두 필요하며, 서로 다른 체인에 둡니다.

먼저 상태, 다음 허용, 마지막 거부

허용 목록은 구체적 허가가 일반적 거부보다 위에 있고 반환 트래픽이 둘 모두보다 위에서 허용될 때만 작동합니다. 규칙을 명시적 위치에 삽입한 다음 iptables -S FORWARD으로 체인을 덤프하여 순서를 추측이 아니라 눈으로 확인하십시오.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

실제 트래픽과 맞닥뜨렸을 때 버티는지는 두 가지 세부에 달려 있습니다. 상태 규칙이 없으면 방금 허용한 연결에 대한 응답이 그 자체로 거부 규칙에 걸려 버려집니다. 제한 없는 LOG 규칙은 스캔이 한 번 닿기만 해도 작은 파티션을 채울 수 있으므로, 기록을 계속하기 전에 -m limit --limit 10/min를 추가하십시오. REJECT는 즉시 오류를 돌려주므로 목록을 조정하는 동안 다루기 쉽고, DROP은 조용히 버리므로 모든 실수가 시간 초과로 보입니다. 하나를 의도적으로 고르고 그 선택을 변경 기록에 남기십시오.

전달과 NAT가 이미 동작해야 합니다

필터링은 경로가 존재함을 증명할 수 없습니다. 먼저 커널이 전달을 하는지 확인하고, 그 설정을 셸의 일회성 명령이 아니라 영구 설정으로 만드십시오. 필터는 마지막 계층이며 첫 계층이 아닙니다.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

매스커레이드가 어디에 속하는지는 클라이언트가 어디로 나가는지에 달려 있습니다. 터널을 통해 원격 네트워크로 나간다면 NAT 규칙은 WAN 인터페이스가 아니라 그 인터페이스에 놓입니다. 그다음 카운터를 보면, POSTROUTING 카운터가 전혀 움직이지 않는데 FORWARD 허용 수가 늘어난다면 반환 경로가 끊긴 것이고 필터는 정상입니다. 이 판독은 문제가 아니었던 규칙을 다시 쓰는 반나절을 아껴 줍니다.

메일 차단은 한 체인 옆의 문제

INPUT에서 포트 25를 막으면 VPN 서버로 주소 지정된 메일만 멈춥니다. 터널로 메일을 보내는 침해된 클라이언트는 전달되므로, 차단은 465와 587 옆 FORWARD에 있어야 합니다. 한 애플리케이션이 정당하게 메일을 중계한다면 그 목적지와 포트를 그 규칙 위에 두십시오.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

다른 무엇을 조이기 전에 거부 카운터를 일주일 돌리십시오. 오르기를 멈춘 숫자가 방금 끊어 버린 정당한 흐름입니다.

다시 읽고, 그다음 클라이언트에서 증명하십시오

규칙 집합은 스크립트가 쓴 대로가 아니라 커널이 보고하는 대로 읽으십시오. iptables -S FORWARD으로 시작하고, 다음으로 iptables -t nat -L POSTROUTING -n -v으로 NAT 테이블, 그다음 확인 중인 흐름의 conntrack 항목을 보십시오. 작업이 이어지는 동안 롤백 명령이나 예약된 플러시를 준비해 두십시오. 모든 호출에는 -w이 필요하며, 그렇지 않으면 두 관리자가 xtables 잠금에서 충돌합니다. 변경 창에서는 이 중 어느 것도 선택 사항이 아닙니다.

풀 안의 클라이언트와 그 밖의 클라이언트에서 시험하며 마무리하십시오. 입력한 기계에서만 동작하는 규칙은 정책이 아닙니다.