DNS·TCP·TLS·HTTP 구분
100분 안팎
학습 목표
제공된 실습 웹 서비스에서 이름 오류·연결 거부·인증서 오류·HTTP 오류를 구분하고 개발자 도구로 헤더·쿠키·세션 전달을 확인합니다.
개념
실패한 첫 단계를 찾습니다
학교 웹에 접속할 때 이름 조회, TCP 연결, TLS 인증, HTTP 응답을 순서대로 생각합니다. HTTPS가 아니라 HTTP라면 TLS 단계가 없습니다. 이번 과제는 제공 서비스에서 각 단계의 서로 다른 실패를 만들고 근거를 분리해 기록하는 작업입니다. HTTP 503을 받았다는 사실과 서버에 연결하지 못했다는 사실은 다릅니다. 앞 단계가 성공했다는 관측은 뒤 단계가 정상임을 보장하지 않으므로 성공 범위와 남은 확인 항목을 같이 씁니다.
동일한 이름을 유지하며 주소를 고정합니다
DNS를 분리해 연결을 시험할 때 URL을 숫자 IP로 바꾸면 HTTPS의 이름 검증 조건도 달라집니다. curl --resolve school.test:8443:10.20.30.11을 사용하면 연결 주소는 고정하고 URL의 school.test는 유지합니다. 이는 DNS 질의를 우회한 시험이며 DNS 성공은 앞서 별도 dig로 확인합니다. Host 헤더와 TLS에서 사용하는 이름을 생각하면서 같은 조건으로 비교해야 인증서 이름 문제를 경로 문제로 오진하지 않습니다.
연결 거부와 응답 대기를 나눕니다
수신자가 없는 8099에서는 curl 7을 기대하는 검사 계약을 둡니다. 제공 8081은 연결을 받아도 HTTP 응답을 보내지 않아 전체 제한 시간으로 curl 28을 유도합니다. 둘 다 화면이 열리지 않지만 첫 상황은 연결 단계, 둘째는 연결 뒤 응답 단계의 실패입니다. 실제 원인은 stderr와 연결 로그를 함께 확인합니다. 모든 timeout을 방화벽 차단이라고 쓰거나 Connection refused를 DNS 이름 부재라고 쓰면 서로 다른 수정 작업을 섞게 됩니다.
TLS는 암호화와 상대 확인을 함께 합니다
학교 HTTPS 서비스는 이름 school.test를 SAN에 포함한 하루 유효 자기서명 인증서를 제공합니다. 기본 신뢰 저장소에 없는 인증서이므로 처음 요청은 검증 실패를 재현합니다. curl 60은 인증서 검증에 실패한 단서이며 신뢰 경로·이름·기간·클라이언트 시간을 나누어 확인합니다. 인증서 파일이 있다는 사실만으로 정상 신뢰를 보고하지 않습니다. 이번에는 실습 파일 cert.pem을 해당 명령의 --cacert로 지정해 신뢰 조건을 명시합니다.
검증을 끄는 것과 신뢰를 추가하는 것은 다릅니다
-k로 확인을 끄면 실패가 사라져도 기대한 상대를 검증했다는 증거가 남지 않습니다. 실습에서는 -k를 쓰지 않습니다. --cacert cert.pem과 이름 기반 URL로 성공한 요청을 기본 신뢰로 실패한 요청과 비교합니다. 이 파일은 교육 환경에 한정한 신뢰 자료이며 시스템 전체 저장소에 설치하지 않습니다. 다른 이름이나 IP URL에 접속하면 인증서 식별자가 맞지 않을 수 있으므로 이름을 지키면서 연결 주소만 고정합니다.
HTTP 상태와 명령 종료 코드를 구분합니다
/unavailable은 HTTP 503을 보내는 제공 엔드포인트입니다. curl은 기본 설정에서 HTTP 오류 상태를 받아도 전송이 완료되면 종료 코드가 0일 수 있습니다. -w 옵션으로 http_code를 출력하고 응답 상태를 별도 검사합니다. --fail을 사용한 경우에는 HTTP 오류가 명령 실패로 표현되는 동작 차이를 함께 적습니다. 이번 검사는 기본 전송 코드와 503 상태를 모두 읽습니다. 종료 코드 0 하나로 학생이 정상 페이지를 받았다고 결론 내리지 않습니다.
헤더는 전송 조건의 증거입니다
/login은 응답 헤더에 Set-Cookie를 포함하고 본문에는 school ready를 보냅니다. curl -D headers.txt로 상태 줄과 응답 헤더를 저장합니다. Content-Type은 본문 해석의 단서이지 인증 성공 증명이 아닙니다. Set-Cookie가 있으면 클라이언트가 저장할 수 있는 쿠키 지시를 받았다는 뜻이며 실제 다음 요청에 보냈는지는 요청 헤더에서 따로 확인합니다. 응답과 요청을 같은 파일이나 방향으로 설명하지 않고 이름과 시점을 구분합니다.
쿠키와 서버 세션을 나눠 설명합니다
school_session=lab123은 제공 앱이 보내는 교육용 값입니다. 쿠키는 브라우저가 저장하고 요청 조건에 맞춰 전달하는 데이터이고 세션은 서버가 사용자의 상태를 유지하는 방식입니다. 이 앱은 실제 인증이나 세션 저장소를 구현하지 않습니다. 따라서 해당 값이 전송됐다고 로그인 권한이나 세션 만료를 시험했다고 보고하지 않습니다. 검사에서는 Set-Cookie를 받은 뒤 cookie jar를 이용해 Cookie 요청 헤더에 같은 값이 실리는 것까지만 확인합니다.
쿠키 속성의 의미를 확인합니다
Path=/는 적용 경로, HttpOnly는 스크립트의 쿠키 접근 제한, SameSite=Lax는 사이트 간 전송 조건과 관련한 속성입니다. HttpOnly라도 브라우저는 조건에 맞는 HTTP 요청에 쿠키를 보낼 수 있습니다. 제공 HTTP 예제에는 Secure 속성이 없으며 실서비스의 인증 쿠키 운영 지침으로 사용하지 않습니다. 개발자 도구에서 저장된 속성과 다음 요청 헤더를 확인하고 서로 다른 개념인 전송 암호화·스크립트 접근·사이트 간 정책을 하나로 설명하지 않습니다.
브라우저에서는 같은 요청을 따라갑니다
README의 선택 관측 절차는 Linux VM의 Chromium을 s1 네임스페이스에서 일반 사용자로 열고 school.test를 학교 서버로 매핑하는 방식입니다. http://school.test:8080/login에 접속해 Network의 응답 Set-Cookie와 다음 요청의 Cookie를 확인합니다. Application에서 HttpOnly와 Path를 보고 요청별 상태 코드를 비교합니다. GUI가 없는 환경에서는 이 관측을 대기로 남기고 curl 자동 결과만 제출합니다. 캡처에는 인증 비밀값 대신 제공 교육용 값만 포함합니다.
자동 시험과 화면 관측을 구분합니다
check.sh는 curl로 헤더 수신과 cookie jar 전송을 검사하지만 브라우저의 SameSite 적용을 전부 재현하지는 않습니다. 브라우저 관측은 별도 화면 증거로 제출합니다. 서비스가 35초 뒤 끝나므로 GUI 확인을 준비한 뒤 실행하며 종료 후 접속 실패를 서비스 장애로 보고하지 않습니다. 네임스페이스 정리 뒤에는 같은 IP가 더 이상 존재하지 않습니다. 시간 제약 안에 관측하지 못했다면 완료로 채우지 말고 재현 절차와 미확인 항목을 남깁니다.
오류를 적절한 열에 기록합니다
services.csv에는 DHCP ACK, DNS NOERROR와 NXDOMAIN, TCP 연결과 거부, TLS 검증 실패와 성공, HTTP 상태와 timeout·쿠키 행이 생깁니다. DNS NXDOMAIN은 없는 실습 이름의 예상 응답이지 전체 DNS 서버 장애가 아닙니다. 503 역시 제공 장애 엔드포인트의 예상 결과입니다. 정상 조건과 의도한 실패가 각각 맞았는지 판정해야 모든 로그를 실패로 보거나 모든 종료 코드 0을 성공으로 보는 잘못을 피할 수 있습니다.
주소 대신 이름을 쓰는 설정을 고칩니다
웹 흐름 starter의 web_name에는 숫자 주소가 들어 있습니다. services.json의 web_name을 school.test로 수정해 인증서 SAN과 URL 이름의 계약을 맞춥니다. 학교 서버의 IP는 record에, DNS 수신자의 IP는 dns에 둡니다. 이 작은 설정 검사는 이름과 주소의 역할을 분리하는 연습입니다. 실제 신뢰 검증은 cert.pem을 사용하는 Linux 요청으로 확인하며 설정 검사 PASS를 TLS 핸드셰이크 성공으로 대신 보고하지 않습니다.
미션 인계를 완성합니다
앞 모듈의 주소표와 경로표는 변경 전 이력으로 보존하고 임대 이후의 실제 주소는 lease.json에 남깁니다. services.csv의 각 행에는 단계·결과·근거가 들어갑니다. 학교망에서 실제 발생한 결과만 적고 미실행 명령의 output은 비워 둡니다. 동료가 한 실패 행을 골라 어디까지 성공했고 무엇을 추가로 볼지 설명할 수 있어야 합니다. 최종 보고서에는 GUI 쿠키 관측 여부와 Linux external 확인 여부를 함께 적어 자동 검사와 사람 확인의 범위를 명료하게 인계합니다.
기술 확인: curl의 주소 고정·신뢰 파일·종료 코드의 공식 명세를 참고했습니다. 설명과 학교망 예제는 이 레슨의 과제에 맞춰 작성했습니다.
따라하기
전송과 페이지 상태를 분리합니다
패킷 관측이 아닌 결정적인 계산 예제입니다. 이 출력의 범위만 판단합니다.
statuses=[(0,200),(0,503),(7,None),(60,None)]
for exit_code,status in statuses:
print('exit',exit_code,'http',status,'page_ok',exit_code==0 and status==200)실행 결과
exit 0 http 200 page_ok True exit 0 http 503 page_ok False exit 7 http None page_ok False exit 60 http None page_ok False
수정한 설정을 검사합니다
압축을 푼 루트에서 starter의 잘못된 필드를 수정합니다. 다음 출력은 solution 설정을 실제 실행한 결과입니다. 서비스 패킷 전송의 증거는 아닙니다.
python3 test_services.py실행 결과
PASS: transport PASS: web-name PASS: pool PASS: reservation PASS: gateway PASS: dns PASS: record PASS: timers
Linux에서 실제 서비스를 검증합니다
다음 명령은 Linux 외부 검증 대기입니다. check.sh가 실제 TLS 신뢰 실패·성공과 HTTP 상태·쿠키을 확인합니다. 상세 수치와 메시지는 실행 후 생성된 services.csv로 확인합니다. 서비스 관측 명령은 35초 실행 중에 사용하며 종료 뒤에는 망이 정리됩니다.
sudo bash check.sh
cat headers.txt
cat cookies.txt
cat services.csv판단 근거를 제출합니다
브라우저 Network와 Application에서 응답 Set-Cookie, 저장 속성, 다음 요청 Cookie를 확인합니다. 자동 curl 증거와 GUI 관측 여부를 나누고 실제 로그인 기능은 구현되지 않았다고 표시합니다.
확인 문제
실습
starter.zip을 푼 루트에서 services.json의 web_name을 본문의 학교망 계약에 맞춰 수정합니다. python3 test_services.py로 일부 실패를 확인한 뒤 수정 결과를 검사합니다. Linux VM에서 sudo bash check.sh로 실제 단계 증거를 services.csv에 생성합니다. README의 검사 범위와 앱 제약을 보고서에 적고 미확인은 대기로 표시합니다.
실행 명령
sudo bash check.sh
기대 결과
설정 검사 8건과 Linux의 DHCP·DNS·TCP·TLS·HTTP 검사가 통과하고 소유한 망을 정리합니다.
모범 답안
모범 답안 내려받기더 읽기
면접 질문
- DNS 오류와 서버 연결 오류를 구분하는 방법을 설명합니다.