> tracert -d 8.8.8.8
최대 30홉 이상의 8.8.8.8(으)로 가는 경로 추적
1 <1 ms <1 ms <1 ms 192.168.1.1
2 1 ms <1 ms <1 ms 211.178.203.129
3 3 ms 1 ms 1 ms 100.79.169.213
4 3 ms <1 ms <1 ms 100.79.126.113
5 3 ms <1 ms <1 ms 10.45.253.156
6 2 ms 1 ms 1 ms 10.222.36.0
7 2 ms 1 ms 1 ms 10.222.23.45
8 53 ms 57 ms 68 ms 142.250.163.48
9 32 ms 32 ms 30 ms 192.178.46.145
10 29 ms 29 ms 29 ms 142.250.239.221
11 31 ms 29 ms 29 ms 8.8.8.8
추적을 완료했습니다.
=> ping으로 8.8.8.8 까지 가는 경로 추적 내역
패킷 단편화
- IP 헤더의 플래그와 오프셋을 이용함
- 플래그 : 두 번째 비트가 0이면 단편화 가능, 1이면 불가능. 세 번째 비트가 0이면 마지막, 1이면 추가 조각이 있음
>ping -l 1600 168.126.63.1
Ping 168.126.63.1 1600바이트 데이터 사용:
168.126.63.1의 응답: 바이트=1600 시간=4ms TTL=55
168.126.63.1의 응답: 바이트=1600 시간=3ms TTL=55
168.126.63.1의 응답: 바이트=1600 시간=3ms TTL=55
168.126.63.1의 응답: 바이트=1600 시간=3ms TTL=55
168.126.63.1에 대한 Ping 통계:
패킷: 보냄 = 4, 받음 = 4, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 3ms, 최대 = 4ms, 평균 = 3ms
Total Length 1500
Flags 001
Data Length 1480
두 번째 패킷
Total Length 148
Flags 000
Fragment Offset 1480
아래쪽에 IPv4 Fagment 보면 단편화 패킷과 Fragment count 등이 표기되어 있음
단편화는 IP 기능이므로, ICMP 패킷에는 Data 1600으로 표기되고 IP 패킷에는 단편화가 기록됨
(첫 번째 패킷에는 ICMP 항목이 없고 IP 패킷만 있었다)
근데, 1600이면 20+1480 / 20+120 이어야 하지 않나? 왜 128바이트인걸까?
라고 생각했는데, ICMP 헤더 크기가 딱 8바이트라는 것을 알게 되어 속이 시원해짐
TCP 3-way HandShake : SYN -> SYN+ACK -> ACK
- 서비스 포트가 반드시 외부에서 접속 가능하도록 열려있어야 한다
TCP 4-way HandShake :
Seq와 Ack를 살펴보면
클) FIN+ACK (S 253, A 476)
-> 서) ACK (S 476, A 254) ← Ack가 Seq로, Seq가 Ack로 크로스 되었음
-> 서) FIN+ACK (S 476, A 254) ← 같은 요청에 대한 응답이므로 Ack, Seq 동일
-> 클) ACK (S 254, A 477) ← Seq가 Ack가 되면서 +1
(Seq가 Ack로 가면서 +1 되고, Ack가 Seq로 갈 때는 그대로 유지됨)
TCP 스트림으로 상세 정보를 순서에 따라 확인할 수 있다
DHCP 서버가 없을땐 169 ~ 주소를 받아온다
서버 1 : DNS
서버 2 : WEB
Services - HTTP, HTTPS On (기본값이 On이라 손댈 필요는 없다)
서버 3 : DHCP
요렇게 해서 save
DHCP 서버는
IP 주소 Pool을 가지고 있다가, 클라이언트가 ip 주소를 요청하면 ip 주소를 전송(임대)한다
실습) DHCP에서 IP를 받아오는 과정
시뮬레이션 - DHCP, HTTP만 필터 체크
IP를 STATIC으로 바꾸었다가 DHCP로 바꾸면 메시지 두 개가 생기는데
DHCP 패킷이다 신속성을 위해 UDP를 사용함
( * DHCP 포트 : 출발지68, 목적지67 )
DEST ADDR:FFFF.FFFF.FFFF & DST IP:255.255.255.255
=> 브로드캐스트
SRC IP : 0.0.0.0
=> DHCP에서 IP를 아직 받아오지 못함
DHCP 응답 패킷
YOUR CLIENT ADDRESS : 10.10.10.10
클라이언트는 IP 주소를 사용하겠다고 전송
PC2의 IP Address는 10.10.10.10가 되어 있다
실습) DNS 서버 사용
캐시가 없을 경우 무조건 처음엔 DNS서버에 요청된다
(* DNS 포트 : 53 (기본적으로 UDP, 데이터가 512 이상이면 TCP ))
요청패킷의 DNS Query
응답패킷의 DNS Answer
DNS 서버가 알려준 IP로 HTTP 통신
미리 설정해둔 10.10.10.2의 index.html 페이지가 출력된다.
콘솔케이블(하늘색)
- 스위치나 라우터와 노트북을 연결
노트북 : RS 232
스위치 : Console
노트북 Desktop > Terminal 에서 스위치 제어 가능
라우터 설정 리셋하는 법
스위치 명령어
sh privilege
현재 권한을 보여준다
(기본은 1, en 관리자는 15)
스위치 IP 잡아주기
SW1(config)#int vlan1
SW1(config-if)#ip add 10.10.10.2 255.255.255.0
SW1(config-if)#no sh
ARP와 이더넷
스위치 -> 라우터(게이트웨이)
라우터 -> 스위치 -> pc로 돌아오고
ARP 프로토콜이 끝났으면
이제 DNS 전송
인데 왜 X 뜨는거지 했으나 맞았다
PC는 10.10.10.~ 네트워크고 목적지인 DNS 서버는 10.10.20.3 이니까.
라우터가 새 메시지를 생성하여 스위치에 보내고 스위치는 다시 DNS로 보낸다
이 때 DNS에는 10.10.10.3 PC에 대한 정보가 없으므로 ARP 과정을 한 번 거치고
PC - 스위치- 라우터 - 스위치 - DNS - 스위치 - 라우터 - 스위치 - PC 이렇게 거쳐서 웹페이지 출력됨
스위치
- 연결하면 바로 사용 가능, 설정하지 않아도 됨
- 직접 연결하려면 콘솔 케이블을 사용해 시리얼 포트에 연결
- 사용자, 비밀번호와 설정이 없으면 기본값
- 비밀번호가 있다면 입력하고 로그인한다
VLAN : 가상의 랜
write memory 또는 copy running-config startup-config
=> 스위치 설정 영구 저장. reload 해도 유지된다
