분리와 태그 오류 검증

성공 하나로 분리까지 보고하지 않습니다

s1에서 s2로 ping이 성공하면 학생 단말 사이의 IPv4 ICMP 왕복이 관측된 것입니다. 이것만으로 교직원·서버·게스트가 분리됐는지 또는 trunk의 네 허용 VLAN이 맞는지 알 수 없습니다. 이 레슨에서는 정상 연결, 다른 VLAN 분리, 의도적인 결함, 복구를 하나의 실험 흐름으로 묶습니다. 설정을 읽은 증거와 실제 전송 결과를 함께 남겨 어떤 가정이 틀렸을 때 검사가 실패하는지 확인합니다.

기준 상태와 검사 기대를 먼저 씁니다

기준 상태는 s1 10.20.10.11/24와 s2 .12/24가 VLAN 10에 있고 p1·u1·u2·p2를 거쳐 왕복하는 것입니다. t1·server1·guest1은 각각 20·30·40에 있습니다. .1 게이트웨이는 아직 비활성입니다. 그래서 s1에서 다른 역할의 원래 주소로 보낸 ping은 실패해야 합니다. 이 실패를 장애 복구 대상으로 잡아 라우팅을 켜면 모듈의 승인 기준을 바꿔 버리므로 현재 단계의 기대를 먼저 고정합니다.

다른 /24 주소로 ping이 실패한 사실만으로 VLAN 격리가 증명되지는 않습니다. VLAN을 모두 하나로 합쳐도 게이트웨이가 없으면 그 시험은 실패할 수 있습니다. 검사기는 교직원·서버·게스트 단말에 잠시 10.20.10.21·.22·.23/24를 하나씩 추가합니다. 그러면 s1은 그 목적지를 같은 링크로 보고 직접 ARP합니다. 주소 선택이 아닌 VLAN 경계가 직접 프레임 전달을 막는지 확인하기 위한 실험입니다.

시험 주소를 추가한 단말에서 s1 방향 ping도 보내 양방향 분리를 봅니다. 임시 주소는 각 시험의 finally 절에서 삭제하며 승인된 주소표 자체는 바꾸지 않습니다. 이 시험은 별도 VM의 자기 실습 공간에서만 적용합니다. 외부 장비의 IP를 흉내 내거나 호스트 관리 인터페이스를 시험 브리지에 넣지 않습니다. 포트 설정과 주소 조건을 고정하고 달라지는 변수가 VLAN이라는 점을 보고서에 명확히 적습니다.

실패 코드를 읽어 도구 오류를 제외합니다

Linux iputils ping은 정상 응답 성공과 응답 없음 및 기타 실행 오류를 다른 종료 코드로 구분합니다. 제공 검사는 0을 연결 성공, 1을 제한된 시험의 응답 실패로 다루며 그 밖의 값은 도구 오류로 중단합니다. ping 명령을 못 찾거나 잘못된 인자를 넣은 결과까지 “차단 성공”으로 승인하지 않습니다. 표준 오류와 종료 상태를 함께 저장하면 시험 자체가 실행됐는지부터 판단할 수 있습니다.

ping에는 -c 1, -W 1, -w 2를 지정해 횟수와 기다리는 시간을 제한합니다. 정확한 RTT와 MAC 문자열은 환경마다 달라 고정 출력으로 쓰지 않습니다. 실제 관측 전에는 Linux steps의 output을 비워 둡니다. 본문에 적은 예상 성공·실패는 관측값과 구별합니다. 인터뷰에서 “실패해야 한다”라는 설계 기대와 “실패를 확인했다”라는 실행 사실을 같은 문장으로 섞지 않는 습관을 연습합니다.

주소 없는 게이트웨이 때문에 원래 다른 /24 시험이 실패하는 것은 이번 시점의 의도된 상태입니다. 직접 ARP를 유도한 임시 /24 시험까지 실패하고 실제 VLAN membership도 다르다는 두 증거를 함께 사용합니다. 반대로 timeout만 있으면 방화벽이나 링크 다운을 배제하지 못합니다. 검사기는 시작 전에 veth·주소·포트 UP·브리지 필터·forwarding을 확인해 알려진 구성 조건이 맞는지 먼저 좁힙니다.

access 오배정을 한 번에 하나만 주입합니다

첫 결함은 brannex p2의 VLAN 10을 지우고 VLAN 20 pvid untagged를 추가하는 것입니다. s2의 IP 주소와 u1·u2 trunk는 유지합니다. s1에서 s2, s2에서 s1이 모두 실패하는지 확인합니다. 시험이 성공한다면 VLAN 필터가 꺼졌거나 다른 경로가 있는지 확인할 근거가 됩니다. 결함을 주입했다는 사실만으로 예상 영향이 실제로 나타났다고 쓰지 않습니다.

시험 뒤 p2의 VLAN 20을 제거하고 VLAN 10 pvid untagged를 복원합니다. 다시 양방향 ping 성공을 확인해야 복구 완료입니다. 수정 명령이 오류 없이 끝났다고 복구를 보고하지 않습니다. 제공 검사기는 실패 중에도 finally로 포트 설정을 원복하고 마지막 check.sh는 공간 전체를 정리합니다. 수동으로 실험할 때는 명령·설정 차이·전송 결과를 기록하고 모르는 상태에서 다른 설정을 연달아 바꾸지 않습니다.

trunk 누락은 단말 주소로 고치지 않습니다

두 번째 결함은 u1에서 VLAN 10 membership만 지우는 것입니다. u2는 네 VLAN을 유지하고 access 포트도 정상입니다. 학생 프레임은 양쪽 허용 목록을 통과해야 하므로 학생 두 단말 사이 왕복이 실패해야 합니다. 이는 한쪽 trunk 목록을 빠뜨린 상황을 재현합니다. s2 IP를 바꾸거나 p2를 다른 브리지로 옮겨 우회하면 어떤 결함을 확인했는지 실험의 의미가 사라집니다.

u1에 vid 10을 태그 유지 상태로 다시 추가한 뒤 학생 왕복을 확인합니다. 복구 명령에 pvid untagged를 붙이면 원래 trunk 계약과 다르므로 실제 VLAN 표까지 비교합니다. 지금 brannex에는 학생만 있어 교직원·서버·게스트의 실제 trunk 전송 시험은 없습니다. 네 VLAN 허용 목록은 구조 검사로 확인하고 VLAN 10의 운반은 왕복 실험으로 확인했다는 범위를 따로 적습니다. 없는 단말의 연결 성공을 만들어 쓰지 않습니다.

문서 결함과 망 결함을 구분합니다

이 레슨 starter의 ports.csv에서는 s2가 VLAN 20으로 오배정돼 있습니다. 먼저 문서 검사가 이 행을 거부하는지 보고 VLAN 10으로 수정합니다. 그 뒤 전체 검사기가 실제 망에서 다시 오배정과 복구를 실행합니다. 승인 파일 자체의 오류와 실행 중 의도적으로 넣는 오류는 목적이 다릅니다. 정상 설계 파일은 계속 올바르게 유지하고 실험에서 바뀐 커널 상태만 임시로 되돌립니다.

reachability mismatch에 출발 네임스페이스와 목적지가 나오면 기대한 성공·실패가 실제와 다르다는 뜻입니다. 오류 다음의 ping 원문과 그 시점의 bridge vlan show를 모읍니다. 실패한 목적지의 이웃 캐시에서 INCOMPLETE나 FAILED가 보이면 링크 해석 실패를 추가 관측한 것이지만 원인 하나를 확정한 것은 아닙니다. 포트가 다른 VLAN에 들어간 것과 물리적 연결이 없는 것을 설정 표로 구분합니다.

test_docs.py의 오류 주입은 검사의 판정 로직을 시험하고 verify_network.py의 결함 주입은 실제 전달 효과를 시험합니다. 둘 중 하나로 다른 하나를 대체할 수 없습니다. 문서에 올바른 값이 쓰여도 실행기가 무시하면 커널은 틀릴 수 있고 우연히 ping이 돼도 승인된 포트 표와 다를 수 있습니다. 제출할 때 문서 검사 결과와 Linux 실행 결과를 별도 로그로 남기며 external 확인 대기를 완료로 표시하지 않습니다.

최종 보고서는 정상 학생 왕복, 같은 /24 시험 주소의 다른 VLAN 실패, p2 오배정 실패와 복구 성공, u1 누락 실패와 복구 성공, 정리 후 호스트 비교를 포함합니다. 주소표와 VLAN 구성도는 다음 라우팅 담당자에게 넘깁니다. ICMP 결과는 DNS·TCP·HTTP 서비스를 검증하지 않았다는 한계를 적고, 어떤 VLAN을 어떤 서비스로 연결할지는 다음 모듈에서 확장합니다. 장애를 재현한 조건과 복구 증거를 남기는 것이 이번 완료 기준입니다.