액세스 제어 목록 (ACL) 은 라우터 인터페이스의 명령 테이블로, 포트에 들어오고 나가는 패킷을 제어합니다. ACL 은 IP, IPX, AppleTalk 등과 같은 모든 라우팅 프로토콜에 적용됩니다. ACL 의 정의도 각 프로토콜을 기반으로 합니다. 라우터 인터페이스가 세 가지 프로토콜 (IP, AppleTalk 및 IPX) 을 지원하도록 구성된 경우 사용자는 세 가지 ACL 을 정의하여 세 가지 프로토콜의 패킷을 개별적으로 제어해야 합니다. ACL 의 역할 ACL 은 네트워크 트래픽을 제한하고 네트워크 성능을 향상시킬 수 있습니다. 예를 들어 ACL 은 패킷 프로토콜을 기반으로 패킷 우선 순위를 지정할 수 있습니다. ACL 은 통신 트래픽을 제어하는 ​​방법을 제공합니다. 예를 들어 ACL 은 라우팅 업데이트 정보의 길이를 제한하거나 단순화하여 라우터의 특정 네트워크 세그먼트를 통한 트래픽을 제한할 수 있습니다. ACL 은 네트워크 보안 액세스를 제공하는 기본 수단입니다. 그림 1 에서 볼 수 있듯이 ACL 은 호스트 A 가 HR 네트워크에 액세스할 수 있도록 허용하지만 호스트 B 액세스는 거부합니다. ACL 은 라우터 포트에서 전달되거나 차단되는 트래픽 유형을 결정할 수 있습니다. 예를 들어, 사용자는 이메일 트래픽 라우팅을 허용하고 모든 텔넷 트래픽을 거부할 수 있습니다. ACL 실행 프로시저 포트에서 수행하는 ACL 은 목록의 조건문이 실행되는 순서에 따라 달라집니다. 패킷의 헤더가 테이블의 조건 판단문과 일치하면 다음 문은 무시되고 검사되지 않습니다. ACL 의 구체적인 구현 프로세스는 그림 2 에 나와 있습니다. 그림 2 에서는 패킷이 첫 번째 판단 조건과 일치하지 않는 경우에만 ACL 의 다음 조건 판단 문에 비교되어 비교됩니다. 일치하는 경우 (전송이 허용된다고 가정) 첫 번째 또는 마지막 문에 관계없이 데이터가 즉시 대상 인터페이스로 전송됩니다. 모든 ACL 판단문이 감지되었지만 일치하는 명령문 출구가 없는 경우 패킷은 거부로 간주되고 폐기됩니다. ACL 은 라우터에서 생성된 패킷을 제어할 수 없습니다. ACL 분류에는 표준 ACL 과 확장 ACL 의 두 가지 주요 유형이 있습니다. 이 두 ACL 의 차이점은 표준 ACL 이 패킷의 소스 주소만 확인한다는 것입니다. 확장 ACL 은 패키지의 소스 주소뿐만 아니라 패키지의 대상 주소뿐만 아니라 패키지의 특정 프로토콜 유형 및 포트 번호도 검사합니다. 네트워크 관리자는 표준 ACL 을 사용하여 특정 네트워크의 모든 트래픽을 차단하거나, 특정 네트워크의 모든 트래픽을 허용하거나, IP 와 같은 특정 프로토콜 그룹의 모든 트래픽을 거부할 수 있습니다. 확장 ACL 은 표준 ACL 보다 더 광범위한 제어 범위를 제공합니다. 예를 들어, 네트워크 관리자는 "외부 웹 트래픽이 통과할 수 있도록 허용하고 FTP, 텔넷 등의 외부 통신 트래픽을 거부할 수 있습니다." 확장 ACL 을 사용하여 목표를 달성할 수 있습니다. 표준 ACL 은 이렇게 정확하게 제어할 수 없습니다. 라우터 구성에서 표준 ACL 과 확장 ACL 간의 차이는 ACL 의 표 번호로 반영됩니다. 위 표는 각 계약에 허용된 법적 표 번호 범위를 나타냅니다. ACL 의 올바른 배치 ACL 은 패킷을 필터링하고 대상에 도달하지 않으려는 패킷을 폐기하여 통신 트래픽을 제어합니다. 그러나 네트워크가 불필요한 트래픽을 효과적으로 줄일 수 있는지 여부는 네트워크 관리자가 ACL 을 어디에 두느냐에 따라 달라집니다. 그림 3 과 같이 TCP/IP 프로토콜을 실행하는 네트워크 환경에서 네트워크는 RouterA 의 T0 인터페이스 연결 네트워크에서 RouterD 의 E 1 인터페이스 연결 네트워크에 대한 액세스만 거부할 수 있다고 가정합니다. 즉, 네트워크 1 네트워크 2 에 대한 액세스는 금지됩니다. 불필요한 트래픽 흐름을 줄이는 일반적인 규칙에 따라 네트워크 관리자는 거부된 트래픽 소스, 즉 RouterA 에 최대한 가깝게 ACL 을 배치해야 합니다. 네트워크 관리자가 표준 ACL 을 사용하여 네트워크 트래픽을 제한하는 경우 표준 ACL 은 소스 IP 주소만 확인할 수 있으므로 실제 구현은 소스 IP 주소와 네트워크 1 을 일치시키는 모든 패킷이 삭제됩니다. 즉, 네트워크 1 네트워크 2, 네트워크 3, 네트워크 4 에 대한 액세스가 금지됩니다. 이 ACL 제어 방법은 네트워크 관리자의 목적을 달성하지 못한다는 것을 알 수 있습니다. 마찬가지로, RouterB 와 RouterC 에 ACL 을 올려놓는 것도 같은 문제가 있다. ACL 이 대상 네트워크에 연결된 RouterD (E0 인터페이스) 에 있어야 네트워크가 네트워크 관리자의 목표를 정확하게 달성할 수 있습니다. 표준 ACL 은 가능한 목적지에 가까워야 한다는 결론을 내릴 수 있다. 네트워크 관리자가 확장 ACL 을 사용하여 이러한 제어를 수행할 경우 확장 ACL 은 소스 주소 (네트워크 1) 또는 대상 주소 (네트워크 2) 를 제어하여 네트워크 1 에서 네트워크에 액세스할 수 있기 때문에 RouterA 에 ACL 을 배치할 수 있습니다 따라서 확장된 ACL 이 가능한 소스에 가까워야 한다는 또 다른 결론을 내릴 수 있습니다. ACL 구성 ACL 구성은 두 단계로 나뉩니다. 첫 번째 단계: 전역 구성 모드에서 다음 명령을 사용하여 ACL 을 만듭니다. router (config) # access-list access-list-number {permit | 일반적으로 사용되는 테이블 번호는 표준 IP ACL (1-99) 과 확장 IP ACL (100- 199) 입니다. 라우터에서 ACL 의 테이블 번호가 구성에 사용되는 경우 목록을 삽입하거나 삭제할 수 없습니다. 목록에서 행을 삽입하거나 삭제하려면 먼저 모든 ACL 을 삭제한 다음 다시 구성해야 합니다. 많은 ACL 엔트리가 있을 때 이러한 변경은 매우 번거롭습니다. 한 가지 효과적인 솔루션은 원격 호스트에서 TFTP 서버를 시작하고, 로컬에서 라우터 구성 파일을 다운로드하고, 텍스트 편집기를 사용하여 ACL 테이블을 수정한 다음 TFTP 를 통해 수정된 구성 파일을 라우터로 다시 보내는 것입니다. 특히 ACL 구성에서 항목을 삭제하면 모든 ACL 이 삭제되므로 구성 시 주의해야 합니다. Cisco IOS 1 1.2 이후 버전에서는 네트워크에서 명명된 ACL 테이블을 사용할 수 있습니다. 이렇게 하면 회로 ACL 을 삭제할 수 있지만 회로를 삽입하거나 재정리할 수는 없습니다. 따라서 작성자는 TFTP 서버를 사용하여 구성을 수정할 것을 권장합니다. 2 단계: 인터페이스 구성 모드에서 access-group 명령 ACL 을 사용하여 한 인터페이스인 router (config-if) # {protocol} access-groupaccess-lip 에 적용 ACL 은 하나의 인터페이스에서 양방향으로 제어할 수 있습니다. 즉, 두 개의 명령을 구성할 수 있습니다. 하나는 in, 하나는 out 이고, 두 명령은 동일한 ACL 테이블 번호를 실행하거나 다를 수 있습니다. 그러나 한 인터페이스의 한 방향에는 하나의 ACL 컨트롤만 있을 수 있습니다. 네트워크 관리자는 ACL 을 구성할 때 먼저 전역 상태에서 ACL 테이블을 구성한 다음 특정 인터페이스에서 구성해야 합니다. 그렇지 않으면 네트워크 보안 위험이 발생할 수 있습니다.

채택하기를 바라다