핫스팟 방화벽이 임대 전에 DHCP를 차단합니다

새 휴대폰이 핫스팟에 연결되지만 주소가 표시되지 않고 끝내 받지 못합니다. 액세스 포인트는 정상이고 DHCP 데몬도 실행 중이며, 작성한 방화벽 규칙은 주소 계획과 일치하는 것처럼 보입니다. 그러나 그 규칙이 실제로 요구하는 것은 클라이언트가 이미 자기가 요청하는 주소를 가지고 있어야 한다는 점입니다. 첫 DHCP 패킷에는 주소가 전혀 없으므로 규칙은 결코 작동하지 않습니다.

클라이언트가 연결되는 과정을 보세요

클라이언트 쪽에서 연결 하나를 따라가 보세요. 무선이 연결되고, 클라이언트가 DHCP 검색을 보내고, 서버가 제안하고, 클라이언트가 요청하고, 서버가 확인하면, 그때서야 클라이언트는 다른 용도로 쓸 수 있는 주소를 갖습니다.

그 마지막 확인 이전의 모든 일은 클라이언트가 일반 트래픽에 게이트웨이를 쓸 수 없는 동안 일어납니다. 서브넷 규칙이 잊고 있는 창이 바로 그때입니다.

첫 패킷에 실제로 들어 있는 것

RFC 2131은 주소를 얻기 전 클라이언트의 DHCP 브로드캐스트가 출발지 주소가 영인 패킷을 사용한다고 규정합니다. 클라이언트에서 서버로 가는 메시지는 UDP 포트 67로, 서버에서 클라이언트로 가는 메시지는 UDP 포트 68로 갑니다. 따라서 검색은 0.0.0.0을 출발지로 해서 도착하며, 클라이언트 서브넷 안의 출발지를 요구하는 규칙은 그것과 단순히 일치하지 않습니다.

이것은 클라이언트 쪽의 잘못된 설정이 아닙니다. 프로토콜이 설계대로 동작하는 것이며, 그것이 가능한 유일한 창에서 그렇게 하는 것입니다.

실제로 이를 처리하는 경로

액세스 포인트 자체가 임대를 제공한다면 이것은 로컬 서비스 대화이고, IP로 필터링되는 로컬 경로에서는 입력과 출력 정책에 관한 일입니다. VPN을 통해 전달되는 클라이언트 트래픽은 다른 결정이고, 그 트래픽에 대한 NAT는 또 다른 문제입니다. 이 셋을 혼동하는 것이 좁은 예외를 넓은 예외로 만드는 길입니다.

패킷이 어디서 처리되는지는 데몬과 사용하는 방화벽 계열에 달려 있습니다. 원시 소켓 구현, 브리지 구성, 더 이른 필터링 훅은 패킷을 전혀 다른 곳으로 옮기거나 차단할 수 있습니다. 규칙을 추가하기 전에 데몬의 인터페이스 바인딩과 활성 훅을 확인하세요.

포럼에서 복사한 일반적인 입력·출력 조리법은 당신의 구현이 같은 방식으로 그 체인들을 지나간다는 증거가 아닙니다.

응답이 항상 브로드캐스트인 것은 아닙니다

브로드캐스트 응답만 허용하는 예외도 틀렸습니다. DHCP 응답의 목적지는 클라이언트 상태와 메시지 필드에 달려 있고, 프로토콜은 브로드캐스트와 유니캐스트 두 경우를 모두 규정합니다. 서버가 곧 할당할 주소로 유니캐스트 응답을 한다면, 브로드캐스트 전용 규칙은 작업을 끝내는 단계를 막습니다. 설정된 서버가 실제로 수행하는 교환에 맞춰 규칙을 작성하세요.

나중의 임대 갱신은 다른 상태에서 같은 교환을 반복하므로, 첫 연결만이 아니라 갱신을 위한 여유도 남겨 두세요.

좁게 고친 다음 나머지를 확인하세요

기존 정책은 그대로 두고 빠진 DHCP 허용을 찾아 클라이언트 쪽 인터페이스, 프로토콜, 두 포트로 범위를 한정하세요. 요청이 서비스에 도달함을 증명하고, 다음으로 서비스가 응답함을 증명하세요. 이는 두 가지 다른 관찰이며, 완벽한 필터링 뒤에서도 서비스나 주소 풀 설정이 틀려 있을 수 있습니다.

테이블을 비우는 것은 DHCP 설정 단계가 아닙니다. iptables에서 flush는 선택한 체인이나 테이블에서 규칙을 삭제하며, NAT 테이블을 비운다고 변환 규칙이 생기지 않습니다. 넓은 ACCEPT 정책을 설정하면 임대와 무관한 보호가 사라지므로, 둘 다 재사용 가능한 핫스팟 수정에 속하지 않습니다.

클라이언트가 임대를 받은 뒤에는 DNS, 포워딩, VPN 출구를 별개의 작업으로 확인하세요. 임대는 로컬 주소 지정만 확립하며 그 이상은 없습니다.