또 다른 NAT를 추가하기 전에 사설 LAN 사이를 라우팅하십시오

내부 방화벽 두 대, 사설 전송 구간 하나, 그리고 각 LAN의 호스트 몇 대가 다른 쪽과 통신하도록 허용해 달라는 요청. 반사적으로 VPN을 세우거나 두 번째 NAT 계층을 추가하지만, 두 반사 모두 문제가 요구하는 것보다 비싸다. 세 조건이 성립하면 평범한 라우팅으로 충분하다. 주소 범위가 겹치지 않고, 양쪽이 상대 LAN으로 트래픽을 되돌려 보낼 수 있으며, 전송 구간이 그 데이터에 대해 이미 충분히 신뢰할 만하다는 것이다. 무엇이든 설계하기 전에 이 세 가지를 확인하라. 하나만 어긋나도 답이 달라진다.

설계를 결정하는 세 가지 조건

첫째 조건은 주소 공간이다. 두 LAN이 같은 RFC 1918 블록을 사용한다면 라우팅으로는 구분할 수 없고 변환은 선택이 아니라 불가피해진다. 둘째는 반환 경로다. A에서 B로 가는 경로는 B가 A의 LAN에 도달하는 방법을 모르면 쓸모가 없으며, 비대칭 지식은 라우팅 설계가 조용히 응답을 버리는 가장 흔한 이유다.

셋째는 신뢰다. 라우팅은 패킷을 옮길 뿐 보호하지 않는다. 한 건물 안의 사설 전송 구간은 사업자 인계나 공유 캠퍼스 백본을 지나는 링크와는 다르다. 구간을 신뢰할 수 없다면 답은 두 방화벽 사이의 터널이며, 아래 라우팅 계획은 그 안에서도 그대로 적용된다.

세 가지가 같은 방향을 가리킬 때만 단순한 설계가 이긴다. 하나가 깨지면 변환으로 덮는 대신 그 조건을 명시적으로 고쳐라. NAT는 실패를 숨길 뿐 해결하지 않는다.

전송 네트워크 위에 경로 계획을 세워라

각 방화벽에 공유 구간의 주소를 주고 원격 LAN마다 구체적인 경로를 하나씩 추가하라. 기존 구성에서 달리 움직여야 할 것은 없으며, 특히 인터넷 기본 경로는 지금 있는 자리에 정확히 남아야 한다. 기본 경로를 상대 방화벽으로 바꾸면 무관한 목적지까지 전송 구간으로 보내게 되는데, 이는 요청된 변경보다 훨씬 큰 변화다. pfSense의 정적 라우팅 문서도 해당 플랫폼에 대해 같은 경로-플러스-게이트웨이 모델을 설명하며, 실제로 운영하는 방화벽에는 동등한 설정이 존재한다.

방화벽 A는 10.30.0.0/24를, 방화벽 B는 10.40.0.0/24를 담당하고, 두 전송 주소는 192.0.2.0/24에 있다. 각 LAN 호스트는 로컬 방화벽을 게이트웨이로 유지하므로 새로운 상태는 양쪽에 하나씩의 경로뿐이다. Linux 기반 방화벽에서는 같은 계획이 이렇게 보이며, 포워딩이 켜져 있어야 한다. 그렇지 않으면 경로는 풀리지만 패킷은 버려진다.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

필터링과 변환을 분리하라

라우팅과 정책은 서로 다른 제어이며, 대부분의 라우팅 설계가 실제로 실패하는 지점은 후자다. 패킷이 실제로 지나는 인그레스 경계에서 구체적인 출발지, 목적지, 서비스를 허용하고, WAN 같은 인터페이스 레이블은 이름일 뿐 신뢰에 대한 선언이 아니라는 점을 기억하라. 사설 트래픽을 나르는 전송 포트에서도 사설 주소 차단이 기본으로 켜져 있을 수 있다.

그다음 NAT가 일어나지 않는다고 결론 내리기 전에 아웃바운드 변환을 보라. 자동 아웃바운드 규칙은 변환할 생각이 없던 트래픽까지 다시 쓸 수 있고, 그러면 상대편이 자체 정책과 로그에 필요한 출발지 주소가 파괴된다. 선택한 흐름이 원래 주소를 유지하는지 확인하고, 아직 필요한 트래픽을 위해 인터넷 변환 규칙은 그대로 두라.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

NAT가 정직한 답일 때

주소 범위가 정말로 겹쳐 재번호 부여가 불가능하거나, 정책상 한쪽이 서브넷이 아니라 단일 주소를 보아야 할 때 변환은 제자리를 얻는다. 그런 경우 의도적인 일대일 또는 포트 제한 매핑은 결과가 알려진 설계 결정이지 임시변통이 아니다.

소리 내어 말해야 할 결과는 상대편이 더 이상 개별 출발지를 보거나 필터링할 수 없다는 것이다. 로그는 변환 주소로 뭉개지고, 호스트별 정책은 작동을 멈추며, 문제 해결은 특정 순간에 어느 내부 호스트가 흐름을 가졌는지 찾는 일이 된다. 해당 트래픽에 그런 것이 중요하지 않다면 NAT로 충분하다.

전송 구간 자체가 잘못된 가정일 때

공유 구간이 사업자, 공유 스위치 패브릭, 또는 다른 쪽이 트래픽을 읽을 수 있는 경로를 지난다면 라우팅만으로는 완전한 답이 아니다. 두 방화벽 사이의 터널은 기밀성과 상대 인증을 주고, 그 안의 라우팅 테이블은 전송 구간에 썼을 바로 그 테이블이다.

이것은 첫 절의 신뢰 질문에서 결정할 일이지, VPN이 더 안전하다는 습관에서 결정할 일이 아니다. 이미 사설인 구간 위의 터널은 얻는 것 없이 운영 비용과 고장 모드를 하나 더한다. 반면 신뢰할 수 없는 구간 위의 라우팅은 기밀성을 감당할 수 없는 단순함과 맞바꾼다. 세 조건 중 무엇이 선택을 이끌었는지 적어 두면 다음 엔지니어가 다시 논쟁하지 않아도 된다.