FTP란 무엇일까

FTP는 File Transfer Protocol의 약자로 말그대로 파일을 전송하는 통신 규약입니다. FTP 서버에 파일들을 업로드, 다운로드할 수 있도록 해주는 프로토콜이며, 이는 FTP 서버와 FTP 클라이언트 간에 통신에서 이루어집니다.

FTP는 Active 모드와 Passive 모드라는 2개의 모드가 존재하며 각각의 모드에서는 2개 또는 2개 이상의 포트가 연결을 맺고 데이터를 전송하는데 사용됩니다. 사용되는 포트는 연결을 제어하는 Command 포트가 있으며 데이터를 전송하는 DATA 포트가 있습니다.

FTP는 TCP 기반으로 만들어져 있으며 기본으로 동작 모드로 Active 모드를 사용하며 20번 또는 1024번 이후의 데이터(Data) 포트는 데이터를 전송하는데 사용하게 되고, 21번 포트는 접속시에 사용되는 명령(Command )포트입니다.

Active 모드
FTP Active 모드의 동작 방식을 그림으로 보면 아래와 같습니다. 참고로 아래 사용된 명령(Command) 포트와 데이터(Data) 포트는 서버의 설정에서 임의로 수정하여 사용할 수 있습니다.

• 1) 클라이언트는 서버의 21번 포트로 접속한 후에 자신이 사용할 두 번째 포트를 서버에 미리 알려줍니다.
• 2) 서버는 클라이언트의 요청에 응답합니다. (acks)
• 3) 서버의 20번 데이터 포트는 클라이언트가 알려준 두 번째 포트로의 접속을 시도합니다.
• 4) 클라이언트가 서버의 요청에 응답합니다. (acks)

위 과정에서 액티브 모드는 “클라이언트가 서버에 접속을 하는 것이 아닌 서버가 클라이언트에 접속을 하는 것”을 확인할 수 있습니다. 만일 FTP 클라이언트에 방화벽이 설치되어 있는 등 외부에서의 접속을 허용하지 않는 상황이라면 FTP 접속이 정상적으로 이루어지지 않을 것입니다. 접소기 되더라도 데이터 목록을 받아오지 못하게 되는 경우도 있고요.

Passive 모드

위에서 살펴본 Active 모드의 단점을 해결하기 위한 Passive 모드를 살펴봅시다. 역시나 아래 그림에서 사용된 커맨드 포트와 데이터 포트는 서버 설정에서 변경할 수 있습니다. 특히 Passive 모드에서는 데이터 포트 번호를 특별하게 지정하지 않는 경우 1024 ~ 65535번 중에서 사용 가능한 임의 포트를 사용하게 됩니다. 포트 번호를 지정할 때는 10001 ~ 10005번과 같이 범위를 지정할 수도 있습니다.

• 1) 클라이언트가 커맨드 포트로 접속을 시도합니다. (Passive 모드 연결)
• 2) 서버에서는 사용할 두 번째 포트를 클라이언트에게 알려줍니다.
• 3) 클라이언트는 다른 포트를 열어 서버가 알려준 포트로 접속을 시도합니다.
• 4) 서버가 클라이언트의 요청에 응답합니다. (acks)

Passive 모드에서는 앞선 Active 모드에서 사용했던 20번 포트를 사용하지 않고 1024번 이후의 임의의 포트를 데이터 채널 포트로 사용하게 됩니다.

연결 방식에 따른 주의사항

Active Mode의 경우는 클라이언트 측의 방화벽에 20번 포트가 차단되어 있다면, 데이터 채널 연결이 불가능해집니다. 연결은 되더라도 데이터 조회부터 실패되는 경우가 발생할 수 있습니다. 따라서 서버측은 20번 포트는 아웃바운드(OUTBOUND, 내 서버에서 외부서버로 보내는 요청) 허용, 클라이언트는 인바운드(INBOUND, 외부에서 내 서버로 들어오는 요청) 허용이 방화벽 설정에 필요합니다.

Passive Mode의 경우는 서버 측의 데이터 채널 포트가 막혀있는 경우 데이터 채널 연결이 불가능하게 됩니다. 그리고 앞서 소개한 것처럼 데이터 채널 포트의 범위를 지정할 수 있는데, 별도로 지정하지 않는 경우는 1024 ~ 65535번의 포트를 사용하게 됩니다. 따라서 INBOUND 모두 허용이 필요하게 되는데, 서버 측에서 데이터 채널 포트 범위를 지정하여 특정 범위의 포트만 허용해주면 모든 포트 허용의 문제를 어느 정도 해결할 수 있습니다.

\

Version 필드 (4bit)

: TCP/IP 제품은 IP v4를 사용한다.

Header Length 필드(4bit)

: IP 헤드의 길이를 32비트 단위로 나타낸다. 대부분의 IP 헤더의 길이는 20바이트 입니다. 필드 값은 거의 항상5다

(5 * 32 = 160bit or 20Byte)

Type-of-Service Flags

; 서비스의 우선 순위를 제공한다.

Total Packet Length 필드 (16bit)

; 전체 IP 패킷의 길이를 바이트 단위로 나타낸다.

Fragment identifier 필드 (16bit)

; 분열이 발생한 경우, 조각을 다시 결합하기 원래의 데이터를 식별하기 위해서 사용한다.

Fragmentation Flags 필드 (3bit)

; 처음 1bit는은 항상 0으로 설정, 나머지 2비트의 용도는 다음과 같다.

- May Fragment : IP 라우터에 의해 분열되는 여부를 나타낸다. 플래그 0 - 분열 가능 1 - 분열 방지

- More Fragments : 원래 데이터의 분열된 조각이 더 있는지 여부 판단. 

   플래그 0 - 마지막 조각, 기본값 1- 조각이 더 있음

Fragmentation Offset 필드 (13bit)

; 8바이트 오프셋으로 조각에 저장된 원래 데이터의 바이트 범위를 나타낸다.

Time-to-live 필드(8bit)

; 데이터을 전달할 수 없는 것으로 판단되어 소멸되기 이전에 데이터가 이동할 수 있는 단계의 수를 나타낸다.

Time-to-Live 필드는 1에서 255사이의 값을 지정하며 라우터들은 패킷을 전달 할 때마다 이 값을 하나씩 감소시킨다.

Protocol Identifier 필드(8bit)

;상위 계층 프로토콜

1 - ICMP, 2 - IGMP, 6 - TCP, 17 - UDP

Header Checksum 필드(16bit)

; IP 헤더의 체크섬을 저장, 라우터를 지나갈때 마다 재 계산을 하기 때문에 속도가 떨어진다.

Source IP Address 필드(32bit)

; 출발지 IP 주소

Destiantion IP Address 필드(32bit)

; 목적지 IP 주소

Options(선택적) 필드(가변적)

; Type-of-Service 플래그 처럼 특별한 처리 옵션을 추가로 정의 할 수 있다.

감사합니다.

핑의 첫번째 패킷이 항상 실패하는 경우 | 첫번째 핑이 실패하는 이유

우리가 장비 설정 후 ping 통신을 통해 상대방의 장비와 연결 상태를 확인 하다보면

첫번째 ping 이 실패하는 경우가 있다. 그 이유에 대해서 설명하겠습니다.

Router#ping 10.0.0.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.100, timeout is 2 seconds:
.!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/13/24 ms



PC>ping 172.16.0.100

Pinging 172.16.0.100 with 32 bytes of data:

Request timed out.
Reply from 172.16.0.100: bytes=32 time=21ms TTL=125
Reply from 172.16.0.100: bytes=32 time=13ms TTL=125
Reply from 172.16.0.100: bytes=32 time=13ms TTL=125

Ping statistics for 172.16.0.100:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
    Minimum = 13ms, Maximum = 21ms, Average = 15ms



1. ARP 캐시가 비어 있는 경우

- 송신 시스템의 ARP 캐시에 목적지 시스템을 나타내는 엔트리가 없다면, 목적지 장비의 하드웨어 주소를 파악하는데 걸리는 시간이 핑 클라이언트에 정의된 시간 제한을 초과 할 수 있다. 또 ICMP Echo Request 메시지의 크기가 로컬 시스템의 MTU보다 크면, 핑은 첫번째 조각을 자신의 Call-Back 큐로부터 삭제하여 첫번째 데이터그램의 두번째 이후 조각만을 전송할 수도 있다. 이런 경우 IP 패킷이 완전하지 않으므로 목적지 시스템은 그 패킷을 무시한다.

2. 라우팅 캐시가 피어 있는 경우

- 오늘날 인터넷은 수백만 개의 네트웍크로 구성되어 있으며, 라우터 대부분이 다른 모든 라우터를 추적할 수 없다. 실제로 대부분의 라우터는 항상 자신의 캐시에 몇 개의 라우팅 경로만을 지정한다. 이런 경우에 패킷이 최근에 전송된 적이 없는 네트웍크로 보내진다면, 라우터가 패킷을 따라야할 올바른 네트웍크 경로를 정하는 데에 다소 시간이 걸릴 수 있다. 따라서, ICMP Echo Request질의 메시지가 성공적으로 응답되기 이전에 핑 클라이언트의 제한 시간이 초과될 수도 있다. 이런 경우, 핑은 처음 몇 개의 메시지를 분실된 것으로 표시할 수도 있다.

3. DNS네임 캐시가 비어 있을 경우

- 핑의 인자로 호스트명을 사용한다면 DNS 탐색 작업으로 인하여 일부 메시지가 지연될 수 있으며, 처리 도중 큐에서 사라지거나 "시간 초과"로 잘못 보고될 수도 있다. 따라서 네트웍크를 조사할 때, 항상 IP주소를 사용하여 이름 변환작업이 시스템 검사에 방해되지 않도록 해야 한다.

# ICMP 트래픽을 차단하는  방화벽
- 웹 서버에 핑을 한다고 하자, Http를 사용하여 웹 서버에 접속할 수는 있어도 핑을 사용하면 아무런 응답도 얻지 못할 수 있다. 이런 경우 ICMP Echo Request메시지가 원격 네트웍크로 보내지지만 원격 네트웍크의 방화벽이 모든 ICMP 메시지를 차단하는 것일 수 있다. 이런 경우 ICMP 메시지는 방화벽에 의해 소멸되며 아무런 ICMP메시지도 응답되지 않는다.
원격 방화벽에서 Destination Unreachable에러 메시지를 전송한다면 문제의 원인을 쉽게 파악할 수 있다. 그러나 이런 메시지를 전송하는 것이 보안에 위배된다고 생각하여 방화벽에서 메시지를 전송하지 않도록 설정하는 경우가 많다. 이런 경우 송신 시스템은 아무런 메시지도 수신하지 못하게 된다.

# 설정이 잘못된 라우팅 테이블
- 송신 시스템의 데이터그램이 원격 목적지에 전송되고, 이에 응답하는 데이터그램이 다시 송신 시스템으로 전송된다. 하지만 잘못된 경로를 통해 송신 시스템의 네트웍크로 보내지는 경우도 있다. 이런 문제는 송신 시스템의 네트웍크가 잘못된 경로를 가리키는 경로로 통지되는 경우에 발생한다.
이런 문제는 새로운 또는 최근에 변경된 네트웍크에서 흔하게 찾아 볼 수 있다. 새로운 네트웍크에 이르는 경로를 정의하는 것을 잊어 버릴 수도 있다. 데이터그램이 돌아 올 때, 반드시 전송되었던 경로와 같은 경로로 되돌아 오는 것은 아니다.

# 많은 양의 Redirect 에러 메시지
- 일부 네트웍크는 많은 양의 ICMP Redirect 에러 메시지를 생성하는 것으로 알려져 있다.
일반적으로 이것은 호스트와 라우터의 서브넷 마스크가 잘못 설정된 경우 또는 호스트를 설정하기 위해 Router Discovery에 심하게 의존하는 경우 발생한다

1. Router Discovery
- 네트웍 장비는 Router Solicitation 질의 메시지에 응답한 라우터 가운데 가장 가중치가 높은 오직 하나의 라우터를 기본 라우터로 사용한다. 이런 모델에서 호스트는 특정 목적지 시스템을 위해 더 적합한 라우터를 통보 받지 않는 한 로컬이 아닌 모든 데이터그램을 전송하는 데 기본 라우터를 사용한다. 그러므로 네트웍크에 여러 개의 라우터가 있다면, 호스트가 여러 라우터와 그 라우터에서 지원하는 경로를 알게됨에 따라 여러개의 ICMP Redirect에러 메시지를 수신하게 된다.
만약 잘못된 라우터에 가장 높은 가중치 값을 부여했다면, 다른 라우터에 더 높은 우선 순위를 부여함으로써 네트웍크의 ICMP Redirect에러 메시지의 수를 줄일 수 있다. 또 다른 방법은 라우터를 집중시켜 하나의 라우터에서만 로컬 세그먼트를 취급하도록 하는 것이다. 이런 경우 모든 트래픽은 남겨진 한 라우터만을 통과하며, 로컬 세그먼트의 모든 ICMP Redirect 트래픽은 없어진다.

2. 잘못 설정된 서브네 마스크

- 네트워크에 잘못 설정된 서브네 마스크를 가진 호스트가 존재하면, ICMP Redirect에러 메시지가 대량으로 생성된다. 이런 로컬 네트웍크의 다른 시스템과 연결을 시도하는 경우 호스트는 목적지 시스템이 다른 네트웍크에 존재하는 것으로 오인하여 데이터그램을 로컬 라우터에 보내게 돈다. 그런 경우, 라우터는 송신 시스템에게 목적지 시스템이 로컬에 존재한다는 것을 Redirect에러 메지지를 통해 알린다.
이 문제를 해결하는 최선의 방법은 네트웍크 장비에 올바른 서브넷 마스크를 부여하여 장비들이 라우터를 거치지 않고 직접 통신 할 수 있게 하는 것이다.

[첫번째 핑이 실패하는 경우, Request timed out.]