네트워크심화 · 18분 읽기

PPP·LCP·PAP/CHAP와 네트워크 계층 협상

Serial 링크의 캡슐화부터 LCP 옵션, PAP·CHAP 인증, IPCP 개방까지 원본 설정과 패킷을 연결하고, 각 단계의 실패 원인을 구분합니다.

개념부터 찾아보기

정의·역할·동작 원리를 독립 페이지에서 확인하세요. 본문의 밑줄 용어에도 설명이 있습니다.

L2TP PPP PPP의 PAP·CHAP 인증 PPTP

이 노트에서 설명할 수 있게 되는 것

PPP 프레임과 LCP 옵션 협상·인증·NCP의 순서를 설명한다.
PAP의 제출 계정과 CHAP의 Challenge·Response를 원본 캡처에서 구분한다.
LCP·인증·IPCP 중 어느 단계에서 연결이 멈췄는지 로그로 판단한다.

먼저 알면 좋은 개념OSI 계층·TCP/IP와 홉별 캡슐화 라우팅 테이블과 정적 경로의 선택·재귀 해석

01PPP 링크가 해결하는 문제

의 목적()는 두 피어 사이의 링크에서 여러 네트워크 계층 프로토콜을 실어 나르는 규격이다. 링크를 설정하는 , 필요한 경우의 인증, · 등 상위 프로토콜별 를 분리한다.
- 의 학습과 과정을 Serial 링크에 그대로 적용하는 방식이 아니다.
양끝 캡슐화수업에서는 Cisco Serial 인터페이스의 기본 HDLC 계열 캡슐화를 로 바꾸었다. 양쪽의 encapsulation이 다르면 물리 신호가 있어도 올바른 링크 계층 대화가 성립하지 않는다.
- 는 직렬번호를 IP 주소에 대응시키는 방식이 아니다.
- Point-to-Point에서는 연결 상대가 하나이고, Protocol 필드로 위에 실은 데이터 종류를 구분한다.

02기본 프레임의 필드와 역할

기본 필드일반적인 HDLC-like 프레이밍은 Flag, Address, Control, Protocol, Information, FCS로 설명한다. 기본 Address 0xff와 Control 0x03은 의 송수신 가 아니다.
- 양끝 피어 주소를 여기에 개별 할당하는 것으로 이해하지 않는다.
- Protocol 필드는 인지 인증인지 IP 데이터인지 결정한다.
투명 전송·압축Flag와 같은 비트·바이트 패턴이 데이터 속에 나타나도 프레임 경계로 오인하지 않도록 링크 방식에 맞는 투명화 처리를 한다. FCS는 전송 오류 검출이며 암호학적 무결성 인증이 아니다.
- 옵션 협상으로 일부 필드가 압축될 수 있고, 캡처 지점에 따라 물리 프레이밍 필드가 표시되지 않을 수 있다.

필드/값	기본 의미	해석
Flag 0x7e	프레임 경계	비트/바이트 stuffing과 연결
Address 0xff / Control 0x03	기본 HDLC-like 필드	개별 가 아님
Protocol 0xc021		링크 옵션 협상
0xc023 / 0xc223	/	인증 메시지
0x8021 / 0x8057	/	네트워크 계층 제어
0x0021 / 0x0057	/ 데이터	개방 후 사용자 패킷

원리 심화

03비동기 PPP의 바이트 이스케이프와 FCS 순서

프레임 구분비동기 HDLC형 는 Flag 0x7e로 프레임 경계를 표시한다. 데이터 안에도 같은 바이트가 나타날 수 있으므로 그대로 전송하면 경계와 구별할 수 없다.
Control Escape이스케이프가 필요한 바이트 앞에 0x7d를 붙이고 원래 바이트에 0x20을 XOR한다. 따라서 데이터 0x7e는 7d 5e, 데이터 0x7d는 7d 5d로 전송된다.
ACCM의 역할Async-Control-Character-Map은 추가로 처리할 제어 문자 집합과 관련된다. 모든 링크가 동일한 직렬 바이트 이스케이프를 쓰는 것은 아니므로 비동기·동기·다른 캡슐화를 구분한다.
송신 순서송신자는 원래 프레임 내용으로 FCS를 만든 다음 필요한 바이트를 이스케이프한다. Flag와 전송 중 삽입한 Escape를 원래 프레임 데이터처럼 FCS에 포함하지 않는다.
수신 순서수신자는 경계를 찾고 Escape 처리를 되돌린 뒤 FCS를 검증한다. 원시 시리얼 캡처 길이가 해석기의 복원된 프레임 길이보다 큰 것은 정상일 수 있다.

04LCP 양방향 옵션 협상의 순서

자신이 수신할 수 있는 Information 필드의 크기를 알리는 옵션이다.
-Protocol상대에게 요구하는 인증 방법을 정한다. 로 방법을 합의한 뒤 실제 · 등의 인증을 수행한다.
Magic-Number루프된 링크를 탐지하는 데 사용하는 값이다. 비밀키나 장비 인증서가 아니다.
생존·종료는 필요하면 Echo로 생존을 확인하고 Terminate로 종료를 알린다. REQsent 출력은 요청했지만 협상이 아직 완료되지 않았다는 단서다.

각 피어의 요청링크가 준비되면 양쪽이 로 요구하는 옵션을 보낸다.
Ack·Nak·Reject 판정수용하면 , 값 변경을 요구하면 , 받아들이지 않는 옵션이면 로 답한다. Ack는 요청 내용과 대응해야 한다.
요청 수정·재교환Nak·Reject를 받은 피어는 필요한 옵션을 바꿔 다시 요청할 수 있다. 한 방향의 Ack만으로 전체 협상이 끝나지 않는다.
양방향 서로의 요구 조건을 처리하여 가 에 도달한다. 이후 합의한 인증 및 네트워크 계층 협상으로 진행한다.

LEARN THROUGH PRACTICE

PPP 링크에서 CHAP 인증과 IP 사용 준비를 구분하기

Serial 링크의 상태와 로그를 대조하여 회선 설정·인증·네트워크 계층 준비를 순서대로 확인한다.

실습 구성과 전제

R3와 R4의 Serial1/0을 연결하고 양쪽에 캡슐화를 설정하는 실습이다.
양쪽에 상대 이름을 인식할 인증 정보가 준비되어 있어야 한다. 예시에는 인증 비밀값을 넣지 않는다.

양단 캡슐화와 LCP부터 맞춘다
- 한쪽이 HDLC이고 다른 쪽이 이면 물리적으로 연결되어도 정상적인 협상이 성립하지 않는다. 양단에서 encapsulation 를 맞추고 인터페이스 상태를 확인한다.
- 화면에는 up/up, Encapsulation , Open이 보인다. 이 부분만으로 다른 네트워크까지 이 완성되었다고 판단할 수는 없다.
text
```
interface Serial1/0
 encapsulation ppp
 no shutdown
end
show interfaces Serial1/0
```
실습 흐름을 재구성한 명령 예시. 장치·인터페이스 이름은 구성에 맞춰 사용한다.
원본 크기로 보기 ↗
- Serial1/0 is up, line protocol is up으로 표시된다.
- Encapsulation PPP, LCP Open이 보이며 IPv4 주소와 MTU 1500도 함께 나온다.
확인 기준
먼저 양단의 · 상태가 맞는지 본다. 가 열리지 않았다면 IP 경로를 추가하기 전에 회선과 캡슐화를 확인한다.
Challenge·Response·Success를 방향별로 읽는다
- 양방향 인증에서는 각 장비가 독립적으로 를 보내므로 두 교환이 섞인다. 로그의 O는 송신, I는 수신이며 id로 같은 인증 교환을 연결한다.
- 화면은 송신 id 9와 수신 id 9, 수신 id 3과 송신 id 3을 보여 준다. 비밀값 자체가 전송되는 와 달리 은 에 대한 응답을 검증한다.
text
```
interface Serial1/0
 ppp authentication chap
end
show interfaces Serial1/0
show logging
```
상대 이름과 인증 정보가 먼저 구성되었다는 조건의 명령이다. 화면은 기존 실습 로그이며 추가 debug 실행을 요구하지 않는다.
원본 크기로 보기 ↗
- O CHALLENGE id 9와 I RESPONSE id 9가 보인다.
- I CHALLENGE id 3·O RESPONSE id 3·I SUCCESS id 3 및 O SUCCESS id 9가 함께 기록되어 있다.
확인 기준
한 방향의 Success만 보지 말고 요구한 양방향 인증이 모두 완료되는지 확인한다. 성공은 데이터 암호화 성공이라는 뜻이 아니다.
인증 뒤 NCP와 실제 IP 전달을 검증한다
- 의 링크 확립과 선택적 인증이 끝나면 는 같은 를 통해 준비된다. 로그의 AUTHOR 요청은 과정의 증거이지 Open 자체를 대신하는 표시는 아니다.
- 확장된 인터페이스 출력에서 상태를 확인하고 같은 링크의 상대 주소로 ping한 뒤 원격 경로를 확인한다. 실패 시 인증 실패와 경로·반환 경로 문제를 분리한다.
text
```
show interfaces Serial1/0
show ip interface brief
show ip route
```
실습 흐름을 재구성한 명령 예시. 장치·인터페이스 이름은 구성에 맞춰 사용한다.
확인 기준
현재 캡처에는 IP ping의 최종 성공 횟수가 없다. 와 성공 범위를 넘어서 종단 통신 성공을 주장하지 않는다.

실습에서 확인한 동작 원리

상태는 → 선택적 인증 → → 실제 패킷 전달로 나누어 확인한다.
은 인증이며 사용자 데이터의 기밀성을 자동 제공하지 않는다.

설정·출력 추가로 확인하기 29장

아래 화면을 펼쳐 위 실습의 설정값, 명령과 확인 기준을 비교해 보세요. 각 묶음은 별도 실습 기록입니다.

실습 화면 묶음 01 1장

5/28-raid · 실습·개념 참고 화면 5 — 「rocky 실습 (sata)」 문맥에 삽입된 원본 실습·개념 참고 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

실습 화면 묶음 02 3장

9/4 - bonding / vpn · 설정·관리 화면 7 — 「VPN Client (window)」 문맥에 삽입된 원본 설정·관리 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

9/4 - bonding / vpn · 설정·관리 화면 8 — 「VPN Client (window)」 문맥에 삽입된 원본 설정·관리 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

9/4 - bonding / vpn · 실습·개념 참고 화면 2 — 「VPN Server (R1)」 문맥에 삽입된 원본 실습·개념 참고 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

실습 화면 묶음 03 2장

PAP 인증 패킷의 평문 필드 — 수업 원본 자료 · PAP·CHAP의 인증 메시지 차이를 관찰하는 실습.

PPP 인증 · *HASH (2) — 수업 원본 자료 · PAP·CHAP의 인증 메시지 차이를 관찰하는 실습. 원문에서 「*HASH」에 배치된 그림 또는 화면이다.

실습 화면 묶음 04 14장

PAP, CHAP · 구성·동작 참고 화면 1 — 「실습 1 (PAP) → 문제 id/pw 가 패킷에 노출」 문맥에 삽입된 원본 구성·동작 참고 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

PAP, CHAP · 구성·동작 참고 화면 9 — 문서 문맥에 삽입된 원본 구성·동작 참고 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

PAP, CHAP · 명령·상태 출력 10 — 문서 문맥에 삽입된 원본 명령·상태 출력이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

PAP, CHAP · 명령·상태 출력 11 — 문서 문맥에 삽입된 원본 명령·상태 출력이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

PAP, CHAP · 명령·상태 출력 12 — 문서 문맥에 삽입된 원본 명령·상태 출력이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

PAP, CHAP · 명령·상태 출력 2 — 「실습 1 (PAP) → 문제 id/pw 가 패킷에 노출」 문맥에 삽입된 원본 명령·상태 출력이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

PAP, CHAP · 명령·상태 출력 4 — 「실습 1 (PAP) → 문제 id/pw 가 패킷에 노출」 문맥에 삽입된 원본 명령·상태 출력이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

PAP, CHAP · 명령·상태 출력 5 — 「실습 1 (PAP) → 문제 id/pw 가 패킷에 노출」 문맥에 삽입된 원본 명령·상태 출력이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

PAP, CHAP · 명령·상태 출력 6 — 「실습 1 (PAP) → 문제 id/pw 가 패킷에 노출」 문맥에 삽입된 원본 명령·상태 출력이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

PAP, CHAP · 실습·개념 참고 화면 13 — 문서 문맥에 삽입된 원본 실습·개념 참고 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

PAP, CHAP · 실습·개념 참고 화면 15 — 문서 문맥에 삽입된 원본 실습·개념 참고 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

PAP, CHAP · 실습·개념 참고 화면 3 — 「실습 1 (PAP) → 문제 id/pw 가 패킷에 노출」 문맥에 삽입된 원본 실습·개념 참고 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

PAP, CHAP · 실습·개념 참고 화면 7 — 「실습 1 (PAP) → 문제 id/pw 가 패킷에 노출」 문맥에 삽입된 원본 실습·개념 참고 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

PAP, CHAP · 실습·개념 참고 화면 8 — 「실습 1 (PAP) → 문제 id/pw 가 패킷에 노출」 문맥에 삽입된 원본 실습·개념 참고 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

실습 화면 묶음 05 1장

학습 원본 · PPP 링크와 인증 패킷의 해당 절에 수록된 화면·도식이다.

실습 화면 묶음 06 1장

실습 화면 묶음 07 4장

frame relay · 명령·상태 출력 5 — 「그냥 serial line 연결」 문맥에 삽입된 원본 명령·상태 출력이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

frame relay · 명령·상태 출력 8 — 「그냥 serial line 연결」 문맥에 삽입된 원본 명령·상태 출력이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

frame relay · 실습·개념 참고 화면 6 — 「그냥 serial line 연결」 문맥에 삽입된 원본 실습·개념 참고 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

frame relay · 실습·개념 참고 화면 7 — 「그냥 serial line 연결」 문맥에 삽입된 원본 실습·개념 참고 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

실습 화면 묶음 08 1장

frame relay · 실습·개념 참고 화면 1 — 「그냥 serial line 연결」 문맥에 삽입된 원본 실습·개념 참고 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

실습 화면 묶음 09 1장

배경지식 · 실습·개념 참고 화면 1 — 문서 문맥에 삽입된 원본 실습·개념 참고 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

실습 화면 묶음 10 1장

보고서 · 실습·개념 참고 화면 3 — 「팀 실습」 문맥에 삽입된 원본 실습·개념 참고 화면이다. PPP·LCP·PAP/CHAP와 네트워크 계층 협상 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

동작·명령 참고 문서

RFC 1661 — PPP 링크 단계 ↗RFC 1994 — CHAP 교환 ↗

예제로 추적

05LCP Configure-Request의 옵션 길이와 Ack 판독

가상 협상 요청Code=1, Identifier=7이며 =1500과 -MD5 인증을 요청하는 역사적 형식 해석 예다. 인증 알고리즘 선택을 운영 환경에 권장하는 예시는 아니다.
옵션 인코딩 옵션은 Type=1, Length=4, 값 1500=0x05dc이므로 01 04 05 dc다. Length는 값만의 2바이트가 아니라 Type·Length를 포함한 옵션 전체 크기다.
인증 옵션 인코딩인증 옵션은 Type=3, Length=5, Protocol=0xc223, Algorithm=5이므로 03 05 c2 23 05다. 앞의 와 합친 옵션은 9바이트다.
전체 길이Code·ID·Length의 4바이트를 더하면 Length=13=0x000d다. 내용은 01 07 00 0d 01 04 05 dc 03 05 c2 23 05이며 Protocol·FCS·Flag는 이 13에 포함하지 않는다.
Ack와 Nak 구분Ack는 Code만 2로 바꾸고 Identifier와 옵션 내용을 정확히 일치시켜야 한다. 를 1492로 바꿔 제안한다면 원래 요청의 Ack가 아니라 Nak이며 송신자가 새 Request로 협상을 이어간다.

06PAP: 전송하는 이름과 검증하는 계정을 맞추기

요청·응답에서는 인증받는 피어가 Peer-ID와 Password를 포함한 를 보내고, 검증자가 Ack 또는 Nak로 결과를 돌려준다. 요청과 응답의 두 메시지가 자동으로 상호 인증을 뜻하지는 않는다.
- 양쪽 인증이 필요하면 각각 상대를 검증하도록 구성한다.
Sent username sent-username은 자신이 상대에게 제출할 이름이다. 검증자 쪽의 로컬 사용자 데이터베이스에 그 이름과 대응하는 비밀이 있어야 한다.
- 라우터 호스트명과 제출 이름이 반드시 같아야 하는 것은 아니지만, 이름을 바꾸면 반대편의 조회 기준도 맞춰야 한다.
- 는 자격 증명을 숨겨 주지 않으며 인증 성공이 이후 데이터 암호화를 의미하지 않는다.

! R1: 교육용 이름 R1로 자신을 제출
interface Serial1/0
 encapsulation ppp
 ppp pap sent-username R1 password <LAB_SECRET>

! R2: 상대 R1의 제출 정보를 검증
username R1 password <LAB_SECRET>
interface Serial1/0
 encapsulation ppp
 ppp authentication pap

단방향 인증 관계를 이해하는 구성 조각이다. 실제 비밀 대신 자리표시자를 사용했으며 주소·회선·반대 방향 인증은 별도 설정이다. 원문의 오기는 로 정정했다.

07CHAP: Challenge·Response·Success가 의미하는 것

MD5- 계산전통적인 MD5-는 Identifier·Secret·를 이 순서로 결합해 MD5를 적용한다. Password 자체를 보내는 와 구분한다.
Name과 계정인증받는 피어의 Name은 검증자의 계정 선택 단서다. hostname으로 제시 이름을 바꾸면 상대 username과 대응시켜야 한다.
재전송·암호화 한계가 바뀌면 같은 비밀이라도 응답이 달라진다. 약한 비밀의 오프라인 추측까지 막지 않으며 사용자 데이터를 암호화하지도 않는다.
양방향 인증양방향으로 요구하면 각 검증자의 와 상대 를 별도의 인증 흐름으로 추적한다.

검증자가 Identifier와 를 피어에게 보낸다.
피어가 공유 비밀과 받은 값으로 응답을 계산해 돌려준다.
비교와 결과검증자가 저장한 비밀로 같은 계산을 하여 비교한다. 결과에 따라 Success 또는 Failure를 알려 인증의 성공 여부를 결정한다.

위쪽 PAP Authenticate-Request와 Ack, 아래쪽 CHAP Challenge·Response·Success가 각각 두 번 보이는 수업 캡처 — 9월 30일의 격리된 가상 라우터 실습 기록이다. PAP 화면에는 당시 교육용 인증 문자열이 평문 바이트로 보인다. 운영 자격 증명으로 사용할 값이 아니다.

08IPCP·IPv6CP: 인증 뒤에도 필요한 단계

의 역할가 개방되고 요구한 인증이 성공하면 네트워크 프로토콜별 를 진행한다. 는 운용 매개변수를 협상하며 원격 접속 환경에서는 주소·관련 확장 옵션을 다룬다.
- 는 링크의 인터페이스 식별자 등 제어에 쓰며 전체 프리픽스 할당이나 을 모두 대신하지 않는다.
프로토콜별 하나의 링크에서 지원하는 의 상태는 서로 다를 수 있다. 와 / Success만 확인하고 ping까지 성공한다고 가정하면 안 된다.
- 가 개방되었는지, 부여한 주소와 상대 경로·이 맞는지까지 확인해야 실제 IP 패킷을 전달할 수 있다.

09디버그 로그를 순서대로 읽기

실습 디버그9월 30일 실습 출력에는 O , I , I , O , 양방향 SUCCESS, 관련 처리와 line protocol up이 이어진다. I/O는 로그를 찍은 라우터 기준의 수신/송신이다.
- 양쪽 호스트명이 바뀌어 보이면 출력 장비와 hostname 설정을 함께 봐야 한다.
실패 단계 협상 실패와 인증 실패, 인증 뒤 실패를 구분하면 무관한 주소나 경로를 먼저 바꾸지 않아도 된다.
- 실습 사례에서 겪은 encapsulation 누락과 / 오타도 별도 원인이며, “회선을 한 번 껐다 켜면 해결”이라는 보편 규칙으로 일반화하지 않는다.

show interfaces Serial1/0
show running-config interface Serial1/0
show ip interface brief
show ppp all

관찰 명령 예시. 장비가 지원하는 명령을 확인한다. debug negotiation/은 많은 출력을 만들 수 있어 필요한 실습 구간에 한정해 읽는 도구이며 상시 수집 명령과 구분한다.

10VPDN·L2TP에서 PPP가 다시 나타나는 이유

·가상 인터페이스2월 2일 실습 예제에서는 원격 클라이언트의 세션을 로 운반하고, Virtual-Template 설정을 바탕으로 동적인 Virtual-Access 인터페이스를 만드는 실습을 포함한다.
- ip local pool은 주소 후보, peer default ip address pool은 피어 할당 정책, ip unnumbered는 다른 인터페이스 주소를 빌리는 설정이다.
- ·· 이후 내부 경로와 가 맞아야 서비스에 접근한다.
인증 계층 터널 인증, , 피어 인증은 서로 다른 계층이다. 하나를 설정했다고 나머지가 자동으로 완료되는 것이 아니다.
- 자체는 데이터 기밀성을 제공하지 않는다.
- no tunnel 은 터널 인증을 비활성화하는 선택이다.
- 터널 인증·· 보호를 각각 설계한다.

설명과 함께 보는 보조 도식

메시지 순서

PPP의 단계별 개방

인증을 사용하는 IPv4 링크의 기본 흐름.

전체 단계를 한 번에 읽기

01
물리 연결
PPP 교환을 운반할 매체가 준비된다.
02
LCP Request
링크 옵션을 제안한다.
03
LCP 응답
수용 또는 조정·거절로 조건을 맞춘다.
04
인증 교환
선택한 PAP·CHAP 등의 조건을 확인한다.
05
IPCP 교환
IPv4 사용 조건을 협상한다.
06
IP 데이터
링크·네트워크 계층이 열린 후 데이터를 보낸다.

학습용 메시지 흐름 모식도. 재전송과 구현별 선택 동작은 축약했다.

검증·예외

11PPP가 어느 협상 단계에서 멈췄는지 판독

를 보냈지만 유효한 Ack 교환이 완성되지 않은 상태다. 물리 링크, 상대 캡슐화, 옵션 거부·재협상 내용을 먼저 연결한다.
Ack-Sent상대 요청에는 Ack를 보냈지만 내 요청에 대한 Ack를 아직 받지 못한 상태다. 한 방향 설정만 수용된 상황과 양방향 를 구분한다.
인증 단계 실패가 여도 요구된 인증에 실패하면 네트워크 계층 설정으로 진행하지 못한다. 인증 요청 방향·계정 식별·지원 방식이 맞는지 분석하되 실제 비밀값을 로그 설명에 복제하지 않는다.
만 미완료인증 성공 이후 가 에 남으면 IP 주소 등 네트워크 계층 옵션 협상을 조사한다. 링크의 인증 성공이 주소·경로까지 완성했다는 뜻은 아니다.
프로토콜별 독립성용 와 용 는 별도 다. 하나가 라는 출력만으로 다른 IP 버전의 네트워크 계층 준비까지 완료됐다고 해석하지 않는다.

학습 확인

이해했는지 확인하기