우리가 헷갈려 하는 부분이 inbound와 outbound와 inside interface와 outside interface입니다.
interface에도 inbound와 outbound가 존재 합니다.
우리는 헷갈리니까 패킷의 방향을 inbound와 outbound라고 하고...
인터페이스를 inside interface와 outside interface라고 하는게 편리할듯 싶습니다...
좋습니다! 이번에는 **실무에서 ACL을 어디에, 왜 inbound/outbound로 적용해야 하는지**를
하나의 그림과 함께 정확하게 정리해드리겠습니다.
---
# 🛡️ **1. 실무 보안 원칙: 가장 강력한 원칙 1개**
### ⭐ **ACL은 “가능하면 들어오는 방향(inbound)”에 적용한다.**
이유는 간단합니다:
> **들어오는 시점에서 막아야 라우터의 CPU와 대역폭을 아낄 수 있고,
> 공격·불필요한 트래픽을 애초에 받지 않게 된다.**
---
# 🖼️ **2. inbound/outbound ACL 실무 적용 구조**
```
[인터넷]
│
(inbound ACL 적용 권장)
▼
┌──────────┐
│ G0/1 │ ← Outside (인터넷 연결)
└──────────┘
│
라우터 내부 처리
│
┌──────────┐
│ G0/0 │ ← Inside (LAN 연결)
└──────────┘
▲
(inbound ACL 적용 가능)
│
[LAN]
```
---
# 🔥 **3. 어디에 ACL을 inbound로 걸어야 하나?**
## ✔ **외부(인터넷) → 내부로 들어오는 방향**
인터넷에서 들어오는 트래픽은 **무조건 Outside 인터페이스의 inbound로 차단**하는 것이 정석.
예)
```
interface G0/1
ip access-group BLOCK_INTERNET in
```
**왜?**
* 외부 공격·스캔·불필요한 포트를 가장 빠른 지점에서 차단
* 라우터가 패킷을 처리하기 전에 버려 CPU/메모리 절약
* 내부 네트워크 보호가 용이
---
## ✔ **내부 → 외부로 나가는 트래픽도 내부 인터페이스 inbound가 안전함**
예를 들어 내부 직원들이 특정 사이트로 나가는 것을 제한한다면:
```
interface G0/0
ip access-group ALLOW_LAN_TRAFFIC in
```
**왜 inbound로?**
* 내부 사용자의 트래픽을 “출발지”에서 가장 효율적으로 통제
* 내부가 잘못된 패킷을 라우터 내부까지 끌고 가지 않음
* 정책 관리가 명확함 (출발지 기준)
---
# ⚠️ 4. 왜 outbound는 실무에서 거의 사용하지 않을까?
### ✔ 이미 라우터가 패킷을 내부적으로 처리한 뒤 나가는 단계
→ **불필요한 CPU 사용**
→ **정책이 복잡해짐**
### ✔ 트래픽이 이미 내부 인터페이스를 통과한 뒤라
→ **막아도 늦음**
### ✔ 관리가 훨씬 어렵고 오용되기 쉬움
---
# 🧭 5. 실무에서 outbound를 쓰는 특별한 경우(드묾)
### ▪ NAT 이후 특정 변환된 패킷을 통제할 때
### ▪ ISP와 협상된 특정 정책이 있을 때
### ▪ 라우팅 결과를 본 뒤 제어해야 할 때
하지만 이런 경우는 네트워크 엔지니어 중 **상위 레벨(CCNP/CCIE 작업)**에서나 쓰는 특수 상황입니다.
---
# ⭐ **실무 최종 결론 (핵심 요약)**
### ✔ **ACL은 가능한 inbound에 적용**
* 외부 → 내부 : Outside 인터페이스 inbound
* 내부 → 외부 : Inside 인터페이스 inbound
### ✔ **Outbound는 특별한 상황 외에는 잘 안 씀**
---
# 📌 원하시면 예제로
* 내부는 192.168.0.0/24
* 외부는 공인 IP
상황에서 **실제 ACL 설정을 시뮬레이션**해서 보여드릴까요?