프로토콜을 이해할 때, 정의만 외우는 것이 아니라 이미지화해서 이해하는 것이 좋다.
사용 예시의 과정을 따라가며 이해하라는 의미다. 대충 어떻게 동작하는지 알아야 한다.
이래서 이렇게 설정을 하는구나, 를 깨달아야 한다.
오늘은 Application Layer에서 사용하는 프로토콜 서비스들을 수업했다.
수업자료 5장에서 배우는 내용들은 모두 서버 쪽 프로토콜이라고 하는데.... 사실 아직 잘 모르겠다.
서버 쪽 프로토콜, 클라이언트 쪽 프로토콜의 정확한 차이를 모르겠다. 어차피 같이 쓰는 거 아닌가?
고민 좀 해봐야겠다.
오늘 수업 분량 전 수업(22일)에서 프로토콜 내용을 일부 나갔는데, 그 부분도 다시 공부해야 한다.
- FTP(File Transfer Protocol)
호스트 간 파일 전송용 프로토콜. 요즘은 잘 안 쓴다고 한다.
연결 제어용, 데이터 전송용이 따로 있다. 그래서 2개의 연결을 사용.
기본 동작은
1. 서버 쪽의 21 포트로 연결 요청 전송, 서버는 응답을 보낸다.
2. 연결이 성립되어 데이터를 주고받는다.
3. 끝나면 세션을 닫는다.
주의 : 사용하는 동안 연결을 위한 21 포트는 계속 열려있고, 데이터 전송의 20 포트는 사용이 끝나면 세션이 닫힌다.
이런 방식으로 굴러가는데, 클라이언트 쪽에서 지정하는 모드에 따라 작동 방식이 미세하게 다르다.
1. Active(능동) 모드 : 서버가 클라이언트에게 데이터를 갖다 준다.
-> 클라이언트의 랜덤 포트가 서버의 21 포트로 연결 : "연결해주세요!"
-> 서버가 자신의 20 포트를 통해 나와서 클라이언트 측의 랜덤 포트로 접근(연결 요청 때의 랜덤 포트와 다른 포트)
-> 주의 : 클라이언트 측에 방화벽이 있다면 클라이언트는 데이터를 받을 수 없다.
-> 즉, 서버 측이 보내주는, 랜덤 포트로 들어오는 데이터를 받으려면 방화벽(포트)을 싹 열어놔야 한다.
-> 보안 문제 발생.
-> 해결 방법 : 클라이언트 Application 설치 시 Active 모드라면 프로그램 측에서 포트 범위를 지정해놓고 서버에게 알려준다. 그럼 포트를 전부 열어놓을 필요가 없으니 보안 문제 해결!
예시) N, M은 서로 다른 포트 번호.
클(M) -> connect() -> 서버(21)
클(M) -> Port N -> 서버(21) : 클라이언트가 데이터를 받을 포트를 알려준다
클(M) <- OK <- 서버(21) : 서버가 연결 승인
클(N) <- connect N <- 서버(20) : 서버가 클라이언트의 N포트로 연결
클(N) <- 데이터 전송 <- 서버(20)
2. Passive(수동) 모드 : 클라이언트가 서버 쪽의 데이터 포트로 접속해 데이터를 받아오는 방식.
-> 클라이언트가 랜덤 포트로 서버의 21 포트로 연결 요청 날림
-> 연결되면 클라이언트의 랜덤 포트에서 서버의 랜덤 포트로 데이터 받으러 진입.
-> 서버가 수동적이라 데이터를 줄 포트를 지정하지 못함.
-> 즉, 클라이언트가 어디로 들어올지 모르기에 서버 측 포트를 싹 열어놔야 한다.
-> 보안 문제 발생.
-> 해결 방법 : 서버가 클라이언트에게 들어올 포트를 알려줌. 능동 방식의 해결책과 비슷하다.
예시) N, M은 서로 다른 포트 번호
클(M) -> connect() -> 서버(21)
클(M) -> PASV -> 서버(21) : 서버에게 수동 모드 공지
클(M) <- PASV.OK/N <- 서버(21) : N으로 들어와라
클(K) -> connect(N) -> 서버(N) : N으로 연결
클(K) <- 전송 <- 서버(N)
데이터 전송 시 연결 방향이
클라이언트 <- 서버 : 능동
클라이언트 -> 서버 : 수동
- FTP 실습 with 패킷 트레이서
초기 설정 no
Router> en : 관리자 모드로
Router# conf t : 전체 설정 모드로
Router(config)# hostname R1 : 기기명 R1으로 변경
R1(config)# int f0/0 : f0/0 인터페이스 설정으로
R1(config-if)# ip add 1.1.1.1 255.255.255.0 : f0/0의 ip주소, 서브넷 마스크 설정
R1(config-if)# no shut : 활성화
게이트웨이 주소는 네트워크 주소와 다르다.
22일 실습 때 에러가 났던 이유.
아무튼 기본 설정을 하고 서버에게 ping을 날려 보면 통신이 안된다.
컴퓨터가 있는 네트워크는 서버가 있는 네트워크를 모르기 때문. 정확히는 서로 모른다.
관리자 모드에서
Router# sh ip route : 통신 가능한 네트워크 주소 출력. 앞에 do를 붙이면 어느 모드에서나 사용 가능.
(관리자 모드에서 없는 명령어를 치면 찾아보느라 5분간 멈춘다. Ctrl+Shift+6으로 aborting)
라우팅 테이블 보는 방법은 나중에 수업한다고 한다.
전체 설정 모드에서
Router(config)# ip route [목적지 네트워크 주소] [목적지 서브넷 주소] [다음 hop의 IP 주소]
로 경로를 입력해준다.
이후 ping을 날려보면 timeout 2회 + 성공 2회가 뜬다.
첫 통신이라 ARP 때문이라고 한다. 게이트웨이에서 1번, 라우터 서브넷에서 1번.
* 다음 hop이란?
hop은 라우터를 건너는 단위를 말한다. 라우터를 한 번 건너면 Hop Count는 1인 것.hop 제한을 TTL이라고도 한다는데, 어디서 본 단어인가 하니 ping에서 나오는 TTL(Time To Live)이다. 그냥 IPv4에서는 홉 제한을 TTL이라 하고, IPv6에서는 Hop Limit이라고 한단다. 패킷이 폐기되기 전 허용되는 홉의 제한이다.
아무튼, PC4에서 Server1으로 ping을 날린다고 하면, PC4 입장에서 '다음 hop'은 어디일까?PC4에서 패킷을 날리면 Router1을 지나 Server1을 가기 위해 Router2를 지나야 하는데, Router1을 지난 시점에서 이미 한 hop은 지난 것이다. 그럼 다음 hop의 IP 주소는 Router2의 주소가 될 것이다. 라우터는 연결 부위마다 주소를 다르게 설정해 줬었으니, Router1 입장에서 보면 입구(그림에서 Router2의 왼쪽) 쪽 주소라고 보면 되겠다.
다음 hop이 Router2의 왼쪽 입구라는 것은 어찌 보면 당연한 소리다. PC4에서 패킷을 보냈는데, Router1이 막을 이유가 없기 때문이다. Router1에서 나가는 순간까지는 이상이 없을 것이다. 그런데 나가서 어디로 가야 할지 모르니 문제가 생긴 것이다.
아무튼 그렇게 ip route 설정을 Router2와 Router3에서 해주고(당연히 Router2 -> Router3 과정에서도 같은 일이 벌어질 테니), Server1에서 돌아올 패킷을 위해서도 또 ip route 설정을 해줘야 한다.
설정을 모두 마쳤으면 ping 테스트는 필수다.패킷 트레이서는 FTP 익명 접속 기능이 없으니 서버에서 계정 등록도 해야 하고.
FTP 접속 명령어는 ftp [ftp 서버 ip 주소]다.서버에서 편지 오고 -> 클라에서 응답 보내고 -> 서버에서 아이디 묻고 -> 클라는 아이디 답하고 -> 아이디가 맞으면 서버에서 비번 물어보고 -> 클라에서 비번 답하고 -> 서버에서 비번이 맞으면 연결 승인.
접속 후에는 폴더 리스트 출력하는 명령어 dir, 명령어를 보는 help 등이 있다.
꼭 FTP가 아니더라도 패킷 날아가는 방식은 대충 다 비슷하다.
요즘 FTP는 서버를 구성하기보다는 다른 App에 서브로 붙는다고 한다.
그래서인지 FTP 서버 구축이나 파일 전송은 하지 않는다고 한다.
뒤에서 NFS가 나오는데, FTP는 얘처럼 파일 시스템을 공유하는 것이 아니라 폴더를 제공하는 것이다.
- NFS(Network File Server)
얘는 좀 중요하다(= 따로 정리할 것이다).
위에서 말했듯 FTP가 파일을 주고받는 용도였다면, 얘는 네트워크 상에 파일 서버를 구현하는 것이다.
네트워크 상의 공간(원격지 공간)을 로컬처럼 연결되어 있는 느낌으로 쓰는 것.
디스크 자체나 파일 공간을 사용할 수 있다. 링크를 달아주는 기술이라고 한다.
장점은 대충 Google Drive의 장점을 생각해도 괜찮다. 하드디스크를 네트워크를 이용해서 내 컴퓨터의 하드디스크처럼 사용 가능하다는 것, 로컬 장치가 망가져도 보존이 가능하다는 것. AWS에서는 EFS라는 서비스로 제공하는 것이 이 기술을 사용한다고 한다.
서버 수업 때 실습할 예정이라고 한다.
- SMTP(Simple Mail Transfer Protocol)
대충 이름처럼 메일 보내는 프로토콜이라 생각하면 된다. 메일 서버를 구축할 일은 없으니 대충 이런 것이다~ 하고 끝냈다.
송신자 컴퓨터 -> SMTP 클라이언트 -> SMTP 서버
SMTP 서버 -> 수신자 컴퓨터
메일 받는 프로토콜은 POP3/IMAP(or IMAP4)인데, 받는 프로토콜이 왜 2개인가 하니...
과거엔 POP3(Post Office Protocol)로 많이 받았다고 한다. 그런데 '비동기화'라는 기능상의 제약이 있었다.
(비동기화 : 유저가 메일을 받으면 로컬에 저장하고 서버에서 삭제. 무조건 메일 전체를 다운로드한다.)
그래서 IMAP(Internet Mail Access Protocol)은 동기화라는 추가적 기능을 제공한다.
(동기화 : 로컬에서 지운 메일은 서버에서 삭제. 단계적으로 다운로드한다.)
(단계적 다운로드 : 제목만 미리 서버에서 받고, 열람 시 메일 내용을 다운로드)
SMTP는 원래 간단한 텍스트만 보냈는데, 여기서 확장을 위한 부가적 프로토콜이 MIME(Multipurpose Internet Mail Extensions)다. ASCII가 아닌 것을 ASCII로 바꿔서 송신한다. 이거에 보안 기능을 추가한 것이 S/MIME이고.
- SSL(Secure Socker Layer)/TLS(Transport Layer Security)
굉장히 중요하다! 하고 하신 것을 보니 나중에 다시 배울 것 같다. 실제로 세계에서 가장 많이 사용되는 암호 통신 방법이라고 한다.
SSL과 TLS의 차이는 무엇인가?
표준화의 차이다. SSL 3.0을 국제기구에서 표준화시킨 것이 TLS 1.0이다.
서비스에서 내려온 평문을 SSL/TLS 계층에서 암호화하고, 전달된 암호가 수신자의 SSL/TLS 계층을 지나며 평문으로 복호화된다.
보통 http에 보안 기능이 추가된 것이 https라고 아는데, 엄밀히 말하면 https라는 프로토콜은 없다고 한다.
그냥 http + SSL/TLS = https
7 계층 데이터는 SSL/TLS에 의해 암호로 변환된다.
- DHCP(Dynamic Host Configuration Protocol)
오늘의 하이라이트. IP 주소 자동 설정 프로토콜이다.
하나의 LAN 안에서 통신하려면 IP 주소와 서브넷 마스크가 필요하다. 다른 네트워크와 통신하려면 게이트웨이 주소(라우터 주소)가 추가로 필요하다.
이때 입력한 문자 주소를 IP 주소로 바꿔주는 서버(네임서버)가 있어야 하는데, 그 주소가 DNS 주소다.
이전에 쓰던 것이
- RARP : ARP 서버를 두고 IP 주소만 제공
- BOOTP : 정적 프로토콜. mapping 된 주소 제공
이제 설명할 DHCP는 아래 4가지 정보를 제공하는 임대 느낌이다.
어쨌거나 IP 주소, 서브넷 마스크, 게이트웨이 주소, DNS 주소. 이 4가지가 최소한 요구되는 정보다.
연결 시 어딘가에서 받아와야 한다.
-> 그걸 누가 주는데? : DHCP 서버에게 요청
-> 뭐여 그럼 DHCP 서버 주소는 어떻게 찾는데?
1. DHCP Discover
-> 주변에 있는지 찾는다. 출발지 MAC 주소 본인, 목적지 MAC 주소(브로드캐스트 MAC 주소)로 연결된 기기 중 찾는 서버가 있는지 확인한다.
-> 아직 IP 주소를 받지 못했으니 Source IP는 0.0.0.0이고, 목적지 IP는 DHCP 주소를 적어야 하는데 몰라서 브로드캐스트 주소 255.255.255.255 작성.
-> 해당 네트워크의 라우터는 이 브로드캐스트가 다른 서브넷으로 넘어가지 않게 차단
-> DHCP Relay로 지나가게 허용
-> 여하튼 이래저래 DHCP 서버가 요청을 받음
2. DHCP Offer
-> DHCP 서버가 자신의 IP 주소를 송신자에게 보내준다.
-> 동시에 이러이러한 IP 주소가 할당 가능함을 알려준다.
-> Offer도 브로드캐스트라 연결된 모든 기기에게 전송된다.
-> 당연히 본인 게 아님을 인지한 기기들은 패킷을 폐기할 테고, 라우터는 DHCP Relay에 의해 지나가게 할 것이다. 적용이 안되어 있으면 막힐 테고.
3. DHCP Request
-> 이제 송신자는 DHCP 서버의 IP 주소를 알고 있다. IP 주소를 받는다는 메시지를 보낸다.
(근데 이 메시지도 브로드캐스트다. 왜지? IP 주소 알았으면 그냥 보내면 되는 거 아닌가?)
4. DHCP ACK
-> DHCP 서버의 최종 확인. IP 주소를 포함해 필요한 네트워크 정보(IP 주소, 서브넷 마스크, 게이트웨이 주소, DNS)를 기간을 알려주며 임대해준다.
DHCP 서버는 할당할 IP 정보를 Pool이라는 단위로 관리한다.
만약 기기가 할당받은 IP 주소가 169.254.xx면 오류가 나서 받아오지 못한 것이다.
일반적으로 클라이언트 포트는 랜덤 포트고 서버 포트만 정해져 있지만, DHCP는 클라이언트 포트는 68번 포트, 서버는 67번 포트다.
- DHCP Relay
엥? 라우터에 브로드캐스트 전송이 막히면 다른 네트워크에 있는 서버에게 어떻게 주소를 요청하냐?
-> 시작하기 전에 DHCP 서버에 할당해줄 Pool이 있는지 확인하고...
-> 브로드캐스트 메시지가 막히는 지점은, 각 네트워크에서 라우터를 지나 나오는 것이 안되는 것이니까...
-> 네트워크와 라우터 연결 지점이 f0/0이라 하면
Router(config)# int f0/0 로 인터페이스 설정에 들어가서
Router(config-if)# ip helper-address [DHCP 서버 IP 주소] 를 입력한다.
이걸 지나가는 각 네트워크의 라우터에 해주면 된다.
송신자 -> 서버의 방향으로 해줬으니, 당연히 서버 -> 송신자 방향으로도 해줘야 한다.
잘 뜯어보면
-> 요청자가 보낸 패킷이 네트워크를 나가서 라우터를 지날 때, 송신지 주소가 라우터 주소로 바뀜.
-> 이래저래 DHCP 서버까지 도달. 서버는 응답을 보냄.
-> 송신자 네트워크의 라우터가 받아서 패킷의 목적지 주소를 송신자의 주소로 바꿔서 송신자에게 건네준다.
Route53 서비스 - DNS 서비스
DNSSEC : 도메인 정보를 암호화하는 기술
DNS란? : 오늘은 기초적인 내용만.
- Domain
예전에는 네트워크의 범위가 좁아 전 인터넷에서 각자를 유일하게 식별할 수 있었지만, 장비가 늘어남에 따라 그게 힘들어졌다. 그래서 숫자로 기억하기 어려우니 문자로 인지하기로 한 것.
www.naver.com 처럼 쓰는게 FQDN(Full Query DomaiN). 앞(www)는 장비명, 뒤(naver.com)은 도메인명.
168.126.63.1/168.126.63.2가 KT DNS인 것과 8.8.8.8이 Google DNS라는 것은 상식으로 알아두라고 한다.
DNS는 도메인 이름과 IP 주소를 변환/관리하는 프로토콜이다.
- 문자로 IP를 뱉어내는 정방향 조회(계층 거쳐가는 순서가 위에서 아래라는 뜻)
- IP로 문자를 뱉어내면 역방향 조회
* URL
/ / /
http://static.naver.com/www/u/2010/0611/nmms_2123124.gif
프로토콜 : http
정보 자원을 가진 컴퓨터의 위치 : static.naver.com
파일 디렉토리 : /www/u/2010/0611
자원 이름 : /nmms_2123124.gif
도메인 <=> IP
(리눅스 서버의)zone 파일에서 찾아준다.
zone 파일은 무엇인가?
레코드란 무엇인가?
찾아볼 것 : 일단 오늘 언급한 프로토콜들은 다 따로 정리하긴 해야 한다.
예습 차원에서는
- DNS 종류 : 로컬 DNS, 캐시 DNS. 루트 DNS
- 다양한 DNS 레코드 : SOA 레코드, NS 레코드, A 레코드, AAAA 레코드, PTR 레코드, MX 레코드, CNAME 레코드
의 역할, 내용 등
다음주에는
- DNS 구성, 필드 설명, 패킷트레이서 실습
- SNMP, Telnet, SSH(+ 대칭키/비대칭키 알고리즘, 전자서명) 등
을 배울 예정이라고 한다.
기초 수업은 월요일쯤 마무리를 예상하셨다. 기초가 끝나면 윈도우/리눅스 서버를 1달 정도 배우고, 아마존 서비스도 배운다고 한다. 대략 3개월차에 Ansible 교육에 들어갈 예정이라고 한다.
'교육' 카테고리의 다른 글
| [5일 차] 21.07.26 : 네트워크 기초 5 (0) | 2021.07.26 |
|---|---|
| [복습] 1주차 복습 (0) | 2021.07.25 |
| [3일 차] 21.07.22 : 네트워크 기초 3 (0) | 2021.07.22 |
| [2일 차] 21.07.21 : 네트워크 기초 2 (0) | 2021.07.21 |
| [1일 차] 21.07.20 : 네트워크 기초 (0) | 2021.07.20 |
댓글