SNAT와 응답 복원

왜 출발지를 바꿉니까

앞 레슨에서 WAN은 학생 사설 주소로 돌아가는 경로를 갖지 않았습니다. 이제 r1의 학교 요청 출발지를 WAN과 같은 망의 .1로 바꿉니다. WAN은 직접 연결된 .1로 응답하고 r1은 해당 연결의 대응 상태를 이용해 원래 학생 목적지로 복원합니다. 이 과제는 SNAT를 실제 적용하고 학교 쪽과 WAN 쪽에서 같은 연결이 어떻게 다르게 보이는지 확인하는 것입니다.

정적 주소를 명시합니다

이 트랙의 wan0는 198.51.100.1로 고정되어 있으므로 snat to로 변환 주소를 명시합니다. masquerade는 송신 인터페이스의 주소를 이용하는 SNAT 형태이며 회선 주소가 바뀌는 환경에서 자주 사용합니다. 이번 과제에서 두 방식을 동시에 적용하지 않습니다. 선택 이유를 주소 설정과 연결하여 설명하고 규칙을 단순하게 유지합니다. 어느 방식이든 경로와 필터의 역할까지 대신하지 않습니다.

규칙이 적용될 위치를 고릅니다

nat.nft의 table ip school_nat에는 postrouting 체인이 있습니다. type nat hook postrouting priority srcnat 선언은 경로 선택 후 나가는 패킷에 대한 출발지 변환 위치를 지정합니다. 일반 filter 체인에 snat 문장을 붙이는 식으로 바꾸지 않습니다. nft --check --file은 커널이 문법과 조건을 받아들일 수 있는지 점검하지만 실제 웹 요청의 성공까지 검사하는 명령은 아닙니다.

일치 조건을 좁힙니다

규칙은 학생과 교직원의 두 /24 출발지, 출력 wan0, 목적지 198.51.100.2, TCP 목적지 포트 8080을 모두 요구합니다. 이 레슨의 가상 외부 웹 요청만 변환하기 위한 범위입니다. guest와 학교 서버를 포함하는 10.20.0.0/16으로 넓히면 요구사항보다 많은 대상이 변환됩니다. 다만 변환 대상에서 빠졌다는 사실을 방화벽 차단이라고 부르지는 않습니다.

첫 패킷과 연결 상태

상태 기반 NAT는 첫 패킷에서 대응 관계를 정하고 이후 같은 흐름은 그 관계를 이용합니다. 응답 방향에도 같은 상태가 사용됩니다. 따라서 NAT 규칙 카운터를 모든 HTTP 패킷 개수로 해석하지 않습니다. 규칙을 삭제해도 이미 만들어진 연결의 대응이 곧바로 사라진다고 가정하지 않습니다. 변경 시험은 새 연결로 수행하여 이전 상태를 결과에 섞지 않습니다.

starter의 잘못된 변환 주소

network-snat starter는 edge.json의 snat와 nat.nft의 변환 대상을 10.20.30.1로 적어 두었습니다. 두 곳을 198.51.100.1로 수정합니다. 주소 JSON만 고치고 실제 규칙을 남기면 test_edge.py는 통과해도 test_nat_rule.py가 실패합니다. 계약 검사 통과 후 Linux에서 커널 문법 검사와 요청 시험까지 확인합니다. 파일의 의도와 실행한 상태가 같다는 근거를 차례로 모읍니다.

내부 관측 위치

r1 v10에서 학생 요청을 보면 출발지가 10.20.10.111이며 v20의 교직원은 10.20.20.11입니다. 미션은 서로 다른 고정 출발지 포트 41001과 41002를 사용해 연결을 구분합니다. 이 숫자는 실습 조건입니다. 실제 업무의 임시 포트 배정 규칙을 설명하는 값이 아닙니다. 학생의 이전 정적 .11과 DHCP 예약 .111을 혼동하면 내부 캡처 조건부터 맞지 않습니다.

외부 관측 위치

r1 wan0에서 두 요청의 출발지 IP는 198.51.100.1이어야 합니다. 목적지는 .2:8080으로 유지됩니다. 이번 통제된 두 연결은 서로 다른 출발지 포트를 보존하는 조건으로 검사합니다. 일반적인 NAT에서는 충돌과 구현 선택에 따라 포트가 달라질 수 있으므로 보존을 보편 규칙으로 외우지 않습니다. nat.csv에는 내부 포트와 실제 외부 포트를 별도 열에 남깁니다.

응답 복원을 확인합니다

outside.pcap에는 .2:8080에서 .1의 대응 포트로 돌아오는 패킷이 있어야 합니다. inside-student.pcap에는 같은 서버 출발지에서 학생 .111의 원래 포트로 돌아오는 패킷이 있어야 합니다. 교직원도 별도로 확인합니다. 요청 한 줄만 보고 응답 성공을 적지 않습니다. curl의 본문 수신과 양쪽 응답 튜플을 함께 비교하면 변환 적용과 서비스 왕복을 구분해 설명할 수 있습니다.

정해진 시간 동안 캡처합니다

제공 capture.py는 해당 네임스페이스 인터페이스의 Ethernet 프레임을 PCAP 형식으로 8초 동안 저장하고 스스로 종료합니다. 이 방식은 종료 신호 없이 제한된 자료를 만들기 위한 교육 구현입니다. Linux 관리자 권한이 필요합니다. 호스트 any에서 캡처하지 않습니다. 캡처에는 동일 패킷의 관측 중복이 있을 수 있으므로 검사기는 튜플의 존재를 비교하며 프레임 개수를 연결 수로 해석하지 않습니다.

파일을 읽어 비교합니다

tcpdump -nn -r로 저장한 pcap을 읽으면 주소와 포트가 숫자로 표시됩니다. 학생 내부, 교직원 내부, 외부 파일을 각각 읽고 동일 서버 끝점과 연결 포트를 연결합니다. -r은 저장 파일 해석이며 현재 망에 다시 요청을 보내지 않습니다. 파일이 없다는 오류는 캡처 이전에 검사가 실패했거나 다른 실행 폴더를 보고 있다는 단서입니다. 빈 자료를 정상 패킷이 없었다는 증거로 바꾸지 않습니다.

NAT 제거 시험의 조건

실행기는 school_nat 테이블을 지운 뒤 41003이라는 새 학생 포트로 요청합니다. 이 연결은 앞 성공 연결의 상태를 재사용하지 않아야 합니다. WAN의 학교 응답 경로는 여전히 없으므로 시간 제한 안에 HTTP가 성공하지 않는지 확인합니다. 이 시험은 학교 사설망은 어떤 환경에서도 외부 통신을 못 한다는 증명이 아닙니다. 선택한 응답 경로 조건에서 SNAT가 맡은 역할을 보여 줍니다.

오류 메시지에서 단계 찾기

NAT rule scope/translation은 텍스트 규칙의 대상과 범위를 대조하라는 뜻입니다. 커널의 syntax error는 nat.nft에서 표시된 위치와 체인 선언을 먼저 살핍니다. expected retained unique source port는 외부 포트 대응이 통제된 시험 조건과 달랐다는 뜻입니다. private source leaked는 외부에 학교 출발지가 보였다는 검사입니다. 규칙 범위를 넓혀 일단 통과시키기보다 관측 지점과 실제 적용 규칙을 확인합니다.

변환의 근거를 인계합니다

nat.csv의 두 행과 세 pcap, negative.txt 및 wan-routes.txt를 같은 실행 결과로 묶습니다. 어떤 요청이 변환됐고 어떤 응답이 복원됐는지 열 이름으로 설명합니다. m05의 DHCP·DNS·TLS 검사 결과도 남겨 경계 추가가 기존 서비스를 깨뜨리지 않았음을 확인합니다. 커널 실행 전이라면 설정 검사 통과와 Linux 확인 대기를 분리합니다. 이번 미션에서 포트 전달은 만들지 않습니다.

구현 확인: nftables NAT 공식 문서에서 체인 위치와 상태 기반 동작을 확인했습니다.