LabHub

네트워크 기초 — 리눅스 VM 에서 손으로 · 라우팅과 DNS · 퀴즈

확인: 라우팅과 DNS

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. h1→라우터→h2 에서 h1 에만 기본 경로를 넣고 h2 에는 안 넣었다. h1 의 ping 결과는?

    1. Network is unreachable 이 즉시 난다
    2. 라우터가 ICMP redirect 로 h2 에게 경로를 알려 줘 된다
    3. 첫 패킷만 유실되고 두 번째부터 된다
    4. 요청은 h2 에 닿지만 응답이 돌아올 길이 없어 timeout 이 난다
  2. `net.ipv4.ip_forward=0` 인 리눅스에 남의 패킷이 들어오면?

    1. 자기 주소가 아니므로 조용히 버린다
    2. ICMP redirect 로 올바른 라우터를 알려 준다
    3. 라우팅 테이블에 경로가 있으면 넘겨 준다
    4. 기본 경로로만 넘기고 정적 경로는 무시한다
  3. 테이블에 `default via 10.20.1.1` 과 `10.99.0.0/24 via 10.20.2.10` 이 있을 때 `10.99.0.5` 는?

    1. 먼저 적힌 default 로 간다
    2. 더 긴 프리픽스인 /24 줄로 10.20.2.10 을 거친다
    3. 두 줄이 겹치므로 커널이 오류를 낸다
    4. 메트릭이 같으면 번갈아 보낸다
  4. `dig` 로는 새 주소가 나오는데 `curl` 은 옛 주소로 간다. 가장 유력한 원인은?

    1. curl 이 DNS 캐시를 따로 갖고 있어서
    2. dig 가 UDP 를 쓰고 curl 은 TCP 를 써서
    3. `/etc/hosts` 에 옛 항목이 있어 libc 가 DNS 보다 먼저 그것을 봐서
    4. resolved 의 상류 서버가 둘이라 번갈아 답해서
  5. 우분투에서 `dnsmasq` 를 깔았더니 `Address already in use` 로 서비스가 실패한다. 무엇을 잡고 있나?

    1. 앞서 깐 bind9 가 0.0.0.0:53 을 잡고 있다
    2. cloud-init 이 부팅 중 임시로 53 을 쓰고 있다
    3. dnsmasq 자신이 두 번 시작되어 두 번째가 실패한 것이다
    4. systemd-resolved 의 스텁이 127.0.0.53:53 을 듣고 있다
  6. `resolvectl domain dns0 '~lab.internal'` 에서 `~` 의 뜻은?

    1. lab.internal 로 끝나는 질의를 이 링크의 서버로 보내는 라우팅 규칙
    2. 짧은 이름 뒤에 lab.internal 을 붙여 보는 검색 도메인
    3. lab.internal 질의를 캐시하지 말라는 표시
    4. 이 도메인의 DNSSEC 검증을 끄라는 표시