처음부터 IP주소가 충분했으면 애초에 발생하지도 않았을 문제였기 때문에 최초의 구상 단계에서 고려되지 않은 것이 사설 IP 및 NAT 개념이고 그래서 일반적인 네트워크 프로토콜 방법론에 안 맞음. 그래서 원래 사용해야 하려는 용도와 맞기 않게 사용해야 하고 특정 계층에 소속된 것도 아니기 때문에 기존에 배웠던 것과 잘 들어맞지 않아서 헷갈리는 것임


원래 포트라는 것은 트랜스포트 계층에서 사용되는 출발지/도착지 번호임. 라우팅에는 일절 관여하지 않고 물리적인 호스트까지 다 찾아가고 난 다음 그 호스트 안에서 어느 프로세스한테 가야할지를 정할 때 보는 건데 이걸 어느 호스트에게 찾아갈지 라우팅할 때 써먹겠다는 거니까 원래의 용도랑 달라지고 그것 때문에 원래 계획되지 않았던 별도의 저장공간이 필요해짐


그게 NAT 테이블이고 이게 공유기 안에 있는 것임. 원래 테이블이라고 있는 건 라우팅 테이블(네트워크 계층에서 쓰는 거. 라우터에 있고 ip 보고 라우팅), 맥 어드레스 테이블(데이터 링크 계층에서 쓰는 거. 스위치에 있고 맥 어드레스 보고 라우팅) 이거 두 개인데 당연히 여기에 들어갈 공간은 없고 공유기가 따로 NAT 테이블을 관리해야 함


공유기(12.12.12.12) 안 쪽의 A 호스트(192.168.0.1)가 구글(222.222.222.222:80)에 접속하면 출발지 ip 192.168.0.1(ip헤더), 출발지 포트 5453(tcp 헤더), 도착지 ip 222.222.222.222(ip 헤더) 도착지 포트 80(tcp 헤더) 으로 패킷이 나가고 공유기에서 출발지 ip 12.12.12.12(ip 헤더), 출발지 포트 4564(tcp 헤더) 도착지 ip 222.222.222.222(ip 헤더) 도착지 포트 80(tcp 헤더) 로 패킷을 갈아끼우고 구글에게 발송함


공유기(12.12.12.12) 안 쪽의 B 호스트(192.168.0.2)가 네이버(111.111.111.111:80)에 접속하면 출발지 ip 192.168.0.2(ip헤더), 출발지 포트 9876(tcp 헤더), 도착지 ip 111.111.111.111(ip 헤더) 도착지 포트 80(tcp 헤더) 으로 패킷이 나가고 공유기에서 출발지 ip 12.12.12.12(ip 헤더), 출발지 포트 7654(tcp 헤더) 도착지 ip 111.111.111.111(ip 헤더) 도착지 포트 80(tcp 헤더) 로 패킷을 갈아끼우고 네이버에게 발송함



그리고 그 헤더를 갈아낄 때 공유기의 NAT 테이블에

도착지 ip 12.12.12.12, port 4564로 오는 패킷이 있으면 A 호스트(192.168.0.1)의 5453 포트로 보내면 된다

도착지 ip 12.12.12.12, port 7654로 오는 패킷이 있으면 B 호스트(192.168.0.2)의 9876 포트로 보내면 된다

라고 기록해두는 거임


네이버나 구글은 공유기 통해서 온 건지 그냥 일반적인 호스트에서 온 건지 알 수도 없고 알 필요도 없이 그냥 12.12.12.12에게 응답을 해주는 거고 공유기는 도착지 포트를 보고 A한테 보낼 건지 B에게 보낼 건지를 결정함. 일반적인 호스트 였다면 포트를 보고 자기 내부의 프로세스 에게 보냈겠지만 공유기는 자기가 공유기라는 걸 아니까 자기 내부의 프로세스가 아니라 NAT 테이블을 보고 전달하는 거고


당연히 원래 써야 할 용도로 쓰는 게 아니니까 네트워크 프로토콜 원리주의자는 싫어함.