주소와 경로

주소를 바꾸기 전에 접속 위치를 그립니다

앞 모듈의 /items는 서버 안에서 127.0.0.1:18080로 조회했습니다. 이제 다른 VM에서 같은 데이터를 읽으려 합니다. 여기서 가장 흔한 실수는 클라이언트에서도 127.0.0.1을 쓰는 것입니다. loopback은 명령을 실행한 장비 자신을 가리킵니다. 서버와 클라이언트가 서로 다른 VM이면 같은 문자열이 서로 다른 장비를 뜻합니다. 접속 구성도에는 명령을 실행하는 장비와 요청을 받는 장비를 먼저 적습니다.

이 모듈의 시스템 명령은 앞에서 만든 Linux VM의 격리된 실습망에서 실행합니다. 맥에서는 Python 3로 판정 로직만 검증합니다. 실습 ZIP의 현재 디렉터리에서 bash check.sh를 실행하며 starter의 task.py만 완성합니다. 테스트는 실제 네트워크 관측을 대신하지 않습니다. VM 명령의 output은 비워 두었으므로 본인 환경의 원문을 기록합니다. 공통 주소 계획은 서버 192.168.56.10/24, 허용 클라이언트 192.168.56.20/24이며 기존 관리 NIC와 VM 콘솔을 유지합니다.

주소·접두어·인터페이스를 한 묶음으로 읽습니다

IP 주소는 통신 끝점의 위치를 나타내며 접두어 길이는 연결된 네트워크 범위를 계산할 기준입니다. /24를 떼고 숫자만 적으면 같은 망인지 판단할 근거가 사라집니다. 서버의 ip -br -4 addr에서 lo와 실습용 NIC를 구분합니다. 인터페이스 이름은 VM마다 다르므로 예제 이름을 그대로 대입하지 않습니다. 상태가 UP이고 주소가 있다고 원격 왕복까지 정상이라는 뜻은 아닙니다. 가상 스위치 연결과 상대 장비 상태는 별도의 관측입니다.

서버와 클라이언트 각각에서 주소를 읽고 구성도에 두 줄로 적습니다. 사설 주소라는 분류는 외부 접근을 막는 보안 장치가 아닙니다. 라우터·주소 변환·방화벽 구성에 따라 통신 범위가 달라집니다. 같은 사설 범위의 숫자가 비슷해 보이더라도 접두어가 다르면 직접 연결 여부를 다시 확인합니다. 실습에서는 기존 네트워크 관리 도구로 주소를 준비하고 관리자 접속에 쓰는 경로를 삭제하지 않습니다.

목적지별 경로 결정을 확인합니다

클라이언트의 ip -4 route get 192.168.56.10은 그 목적지에 사용할 경로를 조회합니다. dev는 나갈 인터페이스, src는 선택한 출발지, via는 표시된 경우 다음 게이트웨이를 읽는 단서입니다. 같은 네트워크의 직접 경로는 via가 없을 수 있습니다. 방화벽의 허용 목록과 비교할 값은 생각했던 주소가 아니라 실제 출발지입니다. VPN이나 여러 NIC가 있으면 기대와 다른 경로가 선택될 수 있으므로 클라이언트 위치도 함께 적습니다.

단순한 단일 IPv4 경로표에서는 목적지에 일치하는 후보 중 접두어가 더 긴 경로가 우선합니다. /0 기본 경로가 있어도 일치하는 /24가 있으면 그 후보를 먼저 봅니다. 로컬 실습은 이 모델만 구현하며 정책 라우팅의 모든 규칙을 흉내 내지 않습니다. 후보가 없으면 NO_ROUTE를 반환하고 리스너 검사는 하지 않습니다. 목적지와 같은 주소가 장비에 설정되어 있다는 사실만으로 올바른 출발지나 반환 경로가 선택된다고 가정하지 않습니다.

경로 조회의 성공은 커널의 선택 결과이며 실제 패킷 전달 시험은 아닙니다. 서버에서 클라이언트 주소로 향하는 반환 경로도 조회합니다. 요청이 도착해도 응답이 다른 NIC로 나가거나 중간 라우터에서 버려지면 왕복 연결은 실패합니다. ping의 성공은 ICMP 교환의 근거이며 HTTP 포트 허용을 보장하지 않습니다. 반대로 ping 실패만으로 SSH 서버가 죽었다고 말할 수도 없습니다. 관측한 프로토콜과 목적지를 좁혀 결론을 씁니다.

리스닝 주소가 받는 범위를 결정합니다

ss -ltn은 현재 네트워크 공간의 TCP 리스너를 보여 줍니다. Local Address:Port가 127.0.0.1:18080이면 서버 내부 loopback으로만 받습니다. 실습망 주소로 들어온 연결을 받으려면 그 주소에 바인딩하거나 적절한 모든 주소 바인딩을 선택해야 합니다. 0.0.0.0은 IPv4의 모든 로컬 주소를 받는 와일드카드이며 클라이언트가 접속할 목적지 주소로 쓰지 않습니다. 이번 미션은 노출 범위를 설명하기 쉽도록 특정 실습망 주소를 선택합니다.

리스닝 주소를 넓히는 일과 허용 출발지를 정하는 일은 다른 설정입니다. 특정 실습망 주소로 바인딩해도 그 주소까지 라우팅되는 다른 망의 클라이언트가 연결을 시도할 수 있습니다. 따라서 바인딩만으로 출발지 제한을 완성했다고 적지 않습니다. IPv6 리스너의 동작을 IPv4와 동일하게 가정하지 말고 ss -4와 ss -6으로 나눠 관찰합니다. 이번 자동 판정 모델은 IPv4에 한정하며 실제 VM의 IPv6 노출은 방화벽 레슨에서 별도로 검토합니다.

이전 앱의 동작을 보존하며 확장합니다

앞 앱의 server(path, port=18080)에 host 기본 인자 127.0.0.1을 추가하고 서버 생성 부분에 전달합니다. HTTP 핸들러나 Store를 새 파일 서버로 교체하지 않습니다. 그러면 이전 회귀 검사가 기본 loopback 동작을 계속 확인하고 service.py만 BIND_ADDRESS를 사용해 실습망을 받습니다. 기존 data/items.json과 app.conf의 내용·권한도 유지합니다. 데이터 접근 오류와 네트워크 오류를 한 변경에서 섞으면 원인을 비교하기 어렵습니다.

서비스의 RUN_SECONDS=20은 이번에도 유지합니다. 환경 파일에 주소를 저장한 뒤 현재 실행이 자연 종료할 때까지 기다리고 다음 기동에서 적용합니다. 환경 파일만 저장했다고 실행 중 소켓 주소가 바뀌지 않습니다. ss로 새 바인딩과 기동 시각을 확인하고 클라이언트 요청을 비교합니다. Cannot assign requested address는 그 주소가 현재 VM에 있는지 볼 단서이며 Address already in use는 주소·포트의 기존 소유자를 조사할 단서입니다. 임의 프로세스 종료로 해결하지 않습니다.

구성도와 검사 범위를 함께 제출합니다

로컬 과제는 목적지, 경로 후보, 리스너 주소를 받아 선택 경로와 LISTENER_MATCH 또는 BIND_MISMATCH를 반환합니다. 일치 판정은 바인딩 조건만 충족했다는 뜻입니다. 방화벽·상대 서비스 상태까지 성공했다는 표시가 아닙니다. 경계 사례로 /24 바로 밖 주소와 경로 후보가 없는 입력을 검사합니다. 정상 사례만 통과하는 구현은 장애 때 가장 필요한 분기에서 오판하므로 미완료로 봅니다.

VM 기록에는 서버·클라이언트 주소와 접두어, 두 방향의 dev·src·via, 실제 리스너, 요청 시각을 적습니다. 실습망 연결 방식도 호스트 전용인지 격리 스위치인지 표시합니다. 다음 담당자는 이 구성도를 보고 어디에서 명령을 실행했는지 재현할 수 있어야 합니다. 명령의 다른 오브젝트와 옵션은 더 읽기로 보냅니다. 경로 조회의 의미는 ip-route 매뉴얼과 함께 확인합니다.