학교 서비스와 통신 요구

망을 만들기 전에 서비스 문장을 쪼갭니다

학교에서 “학생과 손님도 인터넷을 쓰게 해 주세요”라는 요청을 받으면 곧바로 주소를 붙이지 않습니다. 손님이 교직원용 자료실까지 들어가도 되는지, 학교 이름 조회 서버를 같이 써도 되는지가 빠져 있기 때문입니다. 연결을 만드는 사람은 통신이 된다는 증거와 통신을 허용해도 된다는 판단을 나누어야 합니다. 이 레슨의 산출물은 장비 설정이 아니라, 뒤에서 설정과 테스트를 대조할 수 있는 통신 요구 표입니다.

가상 학교에는 학생 단말 s1·s2, 교직원 단말 t1, 학교 서비스 서버 server1, 게스트 단말 guest1, 실습 라우터 r1이 있습니다. student·staff·server·guest는 사용자 또는 서비스 역할이고 router는 전달 장비 역할입니다. 단말 이름은 장비를 구별하는 고정 ID입니다. 사람이 읽기 좋은 별칭을 바꾸더라도 ID를 유지하면 주소표와 구성도에서 같은 장비를 찾을 수 있습니다. 실제 학생 이름이나 학교 내부 주소를 가져오지 않고 제공된 가상 식별자를 사용합니다.

학생이 자료 페이지를 여는 흐름에는 이름을 주소로 바꾸는 DNS와 페이지를 제공하는 웹이 구별됩니다. 이 단계에서는 패킷 구조를 외우기보다 “누가 어떤 서비스를 필요로 하는가”를 적습니다. DNS 성공만으로 웹 페이지 성공을 말할 수 없고, 웹 연결 실패만으로 이름 해석 실패를 단정할 수도 없습니다. 두 요구를 각각 한 행으로 기록해야 이후 이름 조회 시험과 서버 연결 시험을 따로 설계할 수 있습니다.

역할과 서비스를 교차해 확인 가능한 표를 만듭니다

요구사항 파일 requirements.csv의 열은 source_role, service, destination, protocol, port, decision, reason입니다. source_role에는 역할 이름을, destination에는 장비 ID를 씁니다. protocol과 port는 통신을 구별하는 조건이며 decision은 allow 또는 deny로 기록합니다. reason에는 승인하거나 제한한 이유를 남깁니다. “보안상”처럼 대상이 빠진 설명보다 “게스트 내부 웹 접근 제한”처럼 어느 경계를 지키는지 드러나는 문장이 검토하기 좋습니다.

이번 학교의 합의는 네 역할의 DNS 이용을 허용하고, 학생·교직원·서버의 내부 웹 이용을 허용하며, 게스트의 내부 웹 이용은 차단하는 것입니다. 서버 역할도 이름 조회와 내부 웹 점검 요구를 가진 것으로 모델링합니다. destination은 두 서비스 모두 server1입니다. 이는 한 서버가 두 서비스를 제공한다는 계획이며 지금 서버 프로세스를 실행했다는 뜻은 아닙니다. 네 역할과 두 서비스를 교차하면 요구사항은 여덟 행이 됩니다.

이 첫 표의 DNS는 UDP 53, 웹은 TCP 80으로 한정한 학습 계약입니다. 실제 DNS가 UDP만 사용한다는 뜻은 아닙니다. DNS의 TCP 사용과 HTTPS의 연결·인증은 뒤의 서비스 모듈에서 확장합니다. 이 표를 그대로 실제 학교망 방화벽에 적용하지 않습니다. 포트가 같아도 다른 서버라면 다른 요구일 수 있으므로 대상 장비를 지우고 포트 번호만 기록하는 방식은 피합니다.

허용되는 흐름만 쓰면 게스트 차단 요구는 검사할 수 없습니다. deny 행도 정상적인 요구입니다. 정책 모듈에서 학생 웹 요청은 성공해야 하고 게스트 웹 요청은 실패해야 합니다. 차단 시험에서는 어떤 요청을 보냈고 어떤 단계에서 막혔는지 함께 기록해야 합니다. 단지 화면이 열리지 않았다는 관찰에는 서버 중지나 이름 오류도 섞일 수 있어 정책 성공의 증거로는 부족합니다.

요구·설계·관측을 서로 다른 산출물에 둡니다

inventory.json은 장비 ID·역할·네임스페이스 이름의 목록입니다. topology.json은 어떤 단말 포트가 어떤 라우터 포트에 연결되는지 기록합니다. requirements.csv는 그 망에서 이루어져야 하는 통신의 의도입니다. 예를 들어 s1이 목록에는 있는데 구성도의 링크에 나타나지 않는다면 요구가 아니라 설계 누락입니다. 없는 장비 ghost를 링크에 적으면 참조 오류입니다. 사람이 구성도를 읽기 전에 검사기가 이런 불일치를 거부하도록 만듭니다.

구성도 초안은 s1, s2, t1, server1, guest1을 각각 r1에 잇는 별 모양입니다. 아직 VLAN 분리나 단말 간 전달을 구현하지 않습니다. 첫 미션에서는 단말과 바로 연결된 r1 사이의 점검만 수행하며 라우터 전달은 꺼 둡니다. “웹 allow”는 최종 요구이고 “r1 직접 ping 확인”은 현재 구현된 시험입니다. 요구 표가 완성되었다고 최종 서비스가 완성됐다고 보고하지 않습니다.

제출 묶음의 루트에는 requirements.csv, inventory.json, topology.json을 놓고 이후 evidence 폴더에 실행 기록을 붙입니다. 기록에는 실행 대상·명령·관측 결과·판단·남은 확인을 구별합니다. 설정 전후를 비교할 때 파일을 덮어쓰지 않도록 시점을 제목이나 파일명에 넣습니다. 주소나 포트가 다음 모듈에서 바뀌면 문서와 구성 코드를 함께 고쳐 같은 ID가 같은 장비를 뜻하도록 유지합니다.

처음 한 번 준비할 실습 방식

브라우저 실습은 표준 입력을 읽는 Python 코드로 목록을 처리합니다. 실제 망에 패킷을 보내는 환경은 아닙니다. 로컬 실습은 starter.zip을 새 폴더에 풀고 제공 명령으로 검사합니다. 실패한 시작 코드를 고친 뒤 solution과 비교합니다. 망 구성은 전용 Linux VM에서만 수행하며 macOS 터미널에서 Linux ip 명령을 그대로 실행하지 않습니다. 관리자 권한이 필요한 이유와 격리 확인은 마지막 레슨에서 다룹니다.

출력 기록에는 실제 실행한 결과만 적습니다. 아직 실행하지 못한 단계는 예상값을 채우지 않고 “Linux VM에서 확인 대기”라고 남깁니다. 다운로드한 검사기의 성공 문구를 문서에 붙였다고 실제 실행한 증거가 되지는 않습니다. 단계별 결과가 다르면 먼저 입력 파일과 명령의 작업 위치를 확인하고, 오류 원문을 보존한 다음 원인을 좁힙니다. 학습 중인 상태를 정확히 표현하는 것도 네트워크 인계의 일부입니다.

모호한 요구를 질문과 수료 기준으로 바꿉니다

“게스트는 인터넷만”이라는 문장이 남았다면 내부 DNS 사용 여부와 외부망 대상을 확인해야 합니다. 이 프로젝트는 실제 인터넷 대신 뒤에서 별도 가상 외부 네임스페이스를 추가합니다. 지금 외부 웹 대상은 미정으로 적고 내부 server1 웹은 deny로 확정합니다. 미정 요구를 편의상 allow로 바꾸지 않습니다. 누가 승인해야 하는지와 어느 모듈에서 확인할지 적으면 다음 담당자가 질문을 이어갈 수 있습니다.

완료 판단은 네 역할이 모두 표에 있는지, 각 역할에 DNS와 웹 행이 있는지, allow와 deny에 근거가 있는지, 대상 ID가 장비 목록에 실제 존재하는지로 합니다. 첫 행만 눈으로 확인하고 끝내면 뒤쪽 행의 누락을 놓칠 수 있습니다. 따라하기에서는 여덟 조합과 역할별 누락을 코드로 확인합니다. 관련 면접에서는 설정 명령을 먼저 나열하기보다 통신 목적과 검증 조건을 먼저 설명해 보세요.