인터넷은 되는데 사내 앱만 안 열릴 때, 방화벽부터 끄거나 포트를 넓게 열면 원인과 정책을 함께 잃을 수 있습니다. 접속해야 하는 주체·목적지·서비스를 하나로 정하고, 같은 요청이 어디까지 확인되는지 따라갑니다. 이 글의 결과물은 허용할 흐름, 차단할 흐름과 미확인 경계가 담긴 점검표입니다.

자신이 관리하거나 담당자가 승인한 단말·서비스만 시험합니다. 운영 정책 변경은 실제 구성 담당자가 영향 범위와 복구 방법을 확인한 뒤 수행합니다. VPN·ZTNA·포트 포워딩을 새로 도입하는 설계 안내가 아니라 기존 접근 문제를 구분하는 절차입니다.

1. 필요한 흐름과 차단할 흐름을 각각 적습니다.

출발 IP만 적으면 로그인 사용자나 VPN 접속 여부가 빠질 수 있습니다. 목적지도 제품명만 적지 말고 실제 접속 이름, 해석된 주소, 프로토콜과 포트를 대조합니다.

구분기록할 값얻는 곳
출발 주체사용자 역할·단말·접속 VLAN 또는 VPN승인 요청과 현재 단말 상태
목적지서비스 이름·DNS 결과·서버 주소앱 설정, DNS 응답, 서버 담당자
통신 종류TCP/UDP·목적지 포트·요청 시각서비스 설명서와 실제 세션 로그
기대 정책허용 또는 차단, 적용 시간정책 승인 문서와 규칙 ID
실제 결과연결·인증·앱 처리 중 어디서 실패브라우저·클라이언트·서버 로그

VLAN은 경계를 구성하는 한 요소이며 다른 VLAN 사이의 라우팅과 방화벽 허용 여부는 별도입니다. RFC 1918은 사설 IPv4 주소 범위를 정의할 뿐 사설 주소를 쓴다는 사실이 접근 차단을 입증하지는 않습니다. NIST SP 800-41 Rev. 1은 방화벽 정책의 설정·시험·관리를 함께 다룹니다.

2. 접속 실패를 세 층으로 나눕니다.

  1. 이름과 대상 확인. 입력한 이름이 의도한 서버로 해석되는지 확인합니다. 다른 서버나 프록시로 연결됐다면 방화벽 로그도 다른 대상에서 찾아야 합니다.
  2. 연결 경로 확인. 클라이언트 송신, 방화벽 세션·NAT 변환, 서버 수신과 응답을 같은 시각·흐름으로 연결합니다.
  3. 서비스 처리 확인. 연결이 만들어져도 TLS, 로그인 권한, 앱 오류로 실패할 수 있습니다. HTTP 오류나 인증 거절을 패킷 차단과 구분합니다.

서버가 응답하지 않는다고 바로 네트워크 차단으로 결론 내리지 않습니다. 해당 프로세스가 올바른 주소·포트에서 대기 중인지, 서버 자체 방화벽과 반환 경로가 맞는지 확인합니다. 캡처에 보이지 않으면 미러링·필터·수집 손실도 확인합니다.

3. 가상 예제로 허용과 차단의 증거를 비교합니다.

다음 주소·규칙·결과는 설명용 가상 예제이며 실제 망의 스캔이나 설정값이 아닙니다. 업무 단말 192.168.10.25는 내부 앱 192.168.30.40의 TCP 443에 접근해야 하고, 게스트 단말 192.168.50.25는 접근하면 안 된다고 둡니다.

시험설명용 관찰판정과 다음 행동
업무 단말 → 앱방화벽 규칙 APP-ALLOW에 허용 로그, 서버에 요청 도착, 앱이 HTTP 403 반환이 요청은 앱까지 도착. 사용자 역할·앱 권한 담당에게 같은 요청 ID 전달.
게스트 단말 → 앱규칙 GUEST-DENY에 같은 시각의 차단 로그시험한 흐름의 차단 근거 확보. 다른 주소·포트까지 검증한 것은 아님.
업무 단말 → 다른 앱 이름예상과 다른 주소로 해석DNS·앱 설정부터 확인. 기존 허용 규칙 확장 보류.
새 시험 요청방화벽 이후 자료를 받지 못함성공·차단으로 확정하지 않고 서버 수신과 반환 로그 요청.

게스트에서 접속이 실패해도 서버가 꺼져 있었다면 차단 정책이 작동했다는 증거가 아닙니다. 정상 서버를 대상으로 한 허용 시험과 규칙의 차단 기록을 대조합니다. HTTPS 상태 코드는 프록시나 중간 장비도 생성할 수 있으므로 위 예제는 서버 로그에서 같은 요청을 확인한 경우에만 적용합니다.

4. NAT가 있으면 바뀐 주소를 연결합니다.

외부 주소로 요청한 흐름과 내부 서버가 받은 흐름의 주소·포트가 다를 수 있습니다. 다음 변환표를 작성하면 서버 로그에서 원래 클라이언트 IP만 찾다가 놓치는 일을 줄일 수 있습니다.

위치출발 주소·포트목적지 주소·포트연결할 증거
변환 전________클라이언트 요청 시각·세션
변환 후________방화벽 NAT·세션 ID
서버 수신·응답________서버 로그와 반환 인터페이스

서버의 기본 게이트웨이나 정책 경로 때문에 응답이 다른 경계로 나갈 수 있습니다. 요청이 서버에 도착했다는 이유만으로 양방향 경로가 정상이라고 보지 않습니다. 내부에서 외부 공개 주소를 접속하는 시험과 실제 외부에서 접속하는 시험도 구분합니다.

5. 정책을 고쳐야 한다면 적용 전후를 남깁니다.

현재 정책과 업무 요구가 다르다는 근거가 확인된 경우에만 담당자가 변경 범위를 정합니다. 임시 허용에는 책임자와 만료 시점을 붙이고, 필요한 출발 주체·목적지·서비스만 한정합니다. NIST SP 800-207의 접근 원칙처럼 내부에 있다는 사실만으로 모든 자원을 신뢰하지 않습니다.

변경 기록적을 내용
요청·승인업무 사유 ____, 담당자 ____, 티켓 ____
규칙 범위주체 ____, 대상 ____, 프로토콜/포트 ____
적용 전후실패 로그 ____, 성공 로그 ____, 차단 유지 시험 ____
복구 조건불필요한 주체 허용·기존 업무 영향 등 ____
만료·회수예정 ____, 규칙과 잔여 세션 확인 ____

단순히 연결됐다는 이유로 완료 처리하지 않습니다. 의도한 업무가 되고, 허용하지 않은 시험 흐름은 계속 차단되며, 임시 규칙을 회수할 담당자가 정해졌는지 확인합니다.

원본 패킷에는 계정·내부 주소·업무 정보가 포함될 수 있습니다. 공개 게시 대신 필요한 흐름과 시간만 승인된 경로로 공유합니다. 전화의 신호는 되는데 음성이 한쪽만 들린다면 같은 통화의 SIP·RTP 기록으로, 주소부터 받지 못했다면 DHCP 경로 확인으로 이어갑니다.