SLIP과 마찬가지로, PPP는 시리얼 접속을 통해 데이타를 보내는 프로토콜이지만 전자의 부족함을 보충한다. 그것은 시작할때의 최대 datagram의 크기와 IP 주소와 같을 것들을 조절할 수 있도록 해주며 클라이언트의 확인을 해준다. 이런 각각의 능력때문에, PPP는 각각의 프로토콜을 가진다. 아래에서 우리는 간략하게 이와 같은 기초적인 PPP의 블록들을 알아볼 것이다. 이것은 거의 완벽하지는 않다. ; 만약 당신이 PPP에 관해 더 알고자 한다면 당신은 RFC-1548에 있는 내용들을 읽어야 하며 많은 RFC에 관한 내용들 또한 읽어보아야 할 것이다.
PPP의 아주 낮은 부분이 16-bit checksum에 의해 PP 프레임들의 경계를 결정하는 High-Level Data Link Control 프로토콜이다. 좀 더 원시적인 SLIP encapsylation과는 반대로, PPP 프레임은 IP가 아닌 Novell의 IPX나 Appletalk와 같은 프로토콜들 패킷들을 잡아둘 수 있다. 이는 PPP가 프레임에 의해 전달되는 패킷의 종류들을 확인하는 기본 HDLC 프레임에 프로토콜 영역을 추가함으로써 이루어진다. LCP, Link Control Protocol,은 한쪽에서 받아들일수 있는 최대 데이타의 크기인 datagram의 크기를 말해주는 Maximum Receive Unit(MRU)와 같은 데이타링크에 속해있는 교신옵션을 위해 HDLC의 맨 윗부분에 사용된다.
PPP 링크의 설정과정에서 중요한 단계는 클라이언트에의 허가이다. 비록 그것이 위임된 것이기는 아니기는 하지만 다이얼업 라인들에서는 반드시 필요하다. 일반적으로 호스트로 불리는 쪽에서는 어떤 특별한 암호를 아는가에 의해서 클라이언트 자신이 인증하도록 묻는다. 만일 전화를 건 쪽이 정확한 암호를 대는데 실패하면 접속은 끊어진다. PPP에서 인증의 방법은 두 가지이다 ; 즉, 전화를 건 쪽 또한 서버에 그 자신을 인증하도록 한다. 이 인증과정들은 서로서로에게 전혀 무관하다. 여기에는 두가지 서로 다른 인증 프로토콜이 있는데, 다음에 더 자세하게 다룰 것이다. 이것들은 Password Authentication Protocol, 혹은 PAP, 그리고 Challenge Handshake Authentication Protocol, 혹은 CHAP라 이름 붙여져 있다.
IP나 AppleTalk 등과 같이 데이타 링크를 거치는 각각의 네트워크 프로토콜들은 Network Control Protocol(NCP)를 사용하여 유동적으로 설정된다. 한 예로 링크를 거쳐 IP datagram을 보내기 위해, PPP는 IP-datagram들의 Van-jacobson 헤더 압축을 지원한다. 이것은 TCP패킷들의 헤더들을 3바이트 정도로 작게 하기 위한 기술이다. 이것은 CSLIP에서도 역시 사용되며 보다 더 쉽게 VJ-헤더압축에서 언급된 바 있다. 압축의 사용은 IPCP를 통해 start up 될 때 교신이 이루어진다.
PPP는 기능은 크게 두 부분으로 나뉜다. 첫번째는 커널 내에 위치하는 낮은 수준의 HDLC driver이고, 두번째는 여러가지 control protocol을 조정하는 사용자영역의 pppd deamon이다. 현재 release된 PPP는 linux-ppp-1.0.0이며 커널 PPP 모듈, pppd, 원격 시스템에 전화를 거는데 쓰이는 chat이란 프로그램을 포함하고 있다.
PPP 커널 드라이버는 Michael Callanhan에 의해 쓰여졌다. pppd는 Drew Perkins와 다른 사람들에 의해 쓰여진 SUN과 386BSD를 위한 자유로운 PPP implementation에서 derived 고 Paul Mackerras에 의해 유지되고 있다. 이것은 Al Longyear에 의해 포팅되었다. SLIP과 같이, PPP는 특별한 line discipline을 위해 implemented되었다. 어떤 serial line을 PPP link로 쓰기 위해서는, 당신은 먼저 일반적으로 당신의 모뎀을 통해 접속을 형성해야 하며, 그 다음 line을 PPP mode로 바꾸어야 한다. 이 모드에서, 모든 들어오는 data는 들어오는 validity(각각의 HDLC frame은 16-bit의 checksum을 운반한다)을 위한 HDLC frames들을 검사하고, 그것을 다시 풀고 diapatche하는 PPP 드라이버를 거쳐야 한다. 현재, 그것은 IP datagram들을 조정할 수 있고, 선택적으로 Van-Jacobson header compression을 사용할 수 있다. IPX가 지원하자 마자, PPP 드라이버는 IPX 패킷도 조정할 수 있을 것이다.
커널 드라이버는 링크를 통해 실제 네트워크 트래픽 이전에 필요한 전체적인 초기화와 authentication phase를 수행하는 PPP daemon, pppd에 의해 aid된다. pppd의 행동은 잘 조절된 많은 옵션들을 사용하는 것과 같을 것이다. PPP는 다소 복잡하기 때문에, 그것은 하나의 장에서 모든 것들을 설명하는 것은 불가능하다. 이 책은 pppd의 모든 것들을 수용해 낼수 없기 때문이다. 그러나 단지 당신에게 소개하는 정도는 할 수 있을 것이다. 더 많은 정보를 위해서는 매뉴얼 페이지와 pppd 소스판에 있는 README들을 참고하라. 그러면 이 장에서 다 논의되지 못했기 때문에 당신이 궁금해 할 수 있는 사항에 대해서 도움을 받을 수 있을 것이다. 만약 당신의 문제가 모든 문서를 읽었음에도 제기된다면, pppd의 발전에 관련된 많은 사람들이 속해있는 뉴스그룹 comp.protocols.ppp를 참고하라.
당신이 PPP link를 통해 인터넷에 접속하고 싶다면, loopback device나 resolve와 같은 것들을 이용해서 기본적인 네트워킹 capabillity들을 셋업해야 한다. 양쪽다 전장에서 설명되었었다. Serial link를 이용한 DNS의 사용에 관해서 이야기하여야 할 것들이 있다. ; 이것에 관해서는 SLIP에 관해 논의된 장을 참고하라. pppd를 이용한 PPP 접속에 관해 간략한 예를 들기 위해 다시 당신이 vlager에 있다고 하자. 당신은 이미 PPP 서버인 c3op에 접속했고 ppp 계정에 로그하였다. c3po는 벌써 그것의 PPP 드라이버를 구동하였다. 다이얼을 위한 통신프로그램을 빠져나온 후 당신은 다음 명령을 실행해야 한다.
# pppd /dev/cua3 38400 crtscts defaultroute
이것은 serial line cua3을 PPP모드로 flip하고 c3po로의 IP-link를 만든다. Serial port를 통한 전송속도는 38400bps가 될 것이다. Crtscts 옵션은 9600bps 이상의 속도에서 확실한 port의 하드웨어 handshake를 켠다. Pppd가 시작한 후 첫번째로 하는 일은 LCP를 사용하는 원격의 여러 개의 link 특성들과 교신하는 것이다. 일반적으로, 기본적인 옵션의 설정으로 잘 동작하므로 여기서는 더 논의하지 않는다. 나중의 섹션에 좀 더 자세한 LCP로 돌아갈 것이다. 이제 pppd는 IP control protocol인 IPCP를 사용하는 IP parameter와 교신할 것이다. 위에서 pppd에 특정한 IP-주소를 설정하지 않았기 때문에, 그것은 resolver를 사용하여 local hostname에서 얻어진 주소를 사용하려고 할 것이다. 양쪽다 그들의 주소를 서로에게 알려줄 것이다.
일반적으로 이러한 기본값에 대해서 잘못된 것은 없다. 심지어 당신의 컴퓨터에 이더넷에 있다하더라도 이더넷과 PPP interface 모두에 같은 IP-주소를 사용할 수 있다. 그럼에도 불구하고 pppd는 당신에게 다른 주소를 사용하도록 허락하거나, 다른 주소를 사용할 것인지를 물어온다. 이러한 옵션들은 다음 장에서 논의될 것이다.
IPCP 셋업으로 통과한 후에, pppd는 당신의 네트워킹층을 PPP 링크를 사용하기 위해 준비할 것이다. 첫번째로 PPP 네트워크 인터페이스를 point-to-point 링크로 조절하고, ppp0를 첫번째 PPP 링크로, ppp1을 두 번째로, 이런 식으로 계속해 나간다. 다음으로 링크의 다른 한 쪽 끝인 호스트를 가르키는 routing table entry를 셋업할 것이다. 위에서 보여진 예에서 pppd는 c3po로 기본 네트워크 라우트 포인트를 만들 것이다. 왜냐하면 그것이 defaultroute 옵션으로 주어졌기 때문이다. 이것은 당신의 local network에 있지 않는 호스트로 향한 모든 datagram들이 c3po로 가도록 한다. 또다른 많은 routing scheme들을 pppd는 제공하며, 그것은 다음 장에서 자세하게 설명될 것이다.
pppd의 command line argument들을 설명하기전에, pppd는 기본 옵션으로 되어 있는 몇몇 화일들을 찾아본다. 이 화일들은 모든 확실한 command line argument들을 포함하고 있고, 그 양이 몇 줄이 될런지 알 수 없다. 소개되는 comment들은 특정한 신호를 가지고 있다. 첫번째 옵션 파일은 pppd가 시작할 때 언제나 찾는 /etc/ppp/options이다. 이 화일이 당신에게 당신의 사용자들이 보안에 대한 타협을 하도록 해주기 때문에 이 화일에 전반적인 기본 설정을 맞추어 놓는 것이 좋다. 한 예로, pppd가 peer로 부터 어떤 종류의 인증(PAP나 CHAP)을 하도록 하기 위해 이 화일에 auth에 관한 옵션을 추가할 수 있다. 이 옵션은 사용자들에 의해 덮어쓰여지지 않기 때문에 database들에 인증되어 있지 않은 어떤 system에도 PPP접속을 하는 것은 불가능하다. /etc/ppp/options이 읽혀지고 난 후에 찾는 다른 옵션 화일은 사용자의 홈디렉토리에 있는 .ppprc화일이다. 그것은 각 사용자들에게 그들만의 기본옵션들을 설정할 수 있도록 해준다. /etc/ppp/options의 예제화일은 다음과 같이 보일것이다:
# Global options for pppd running on vlager.vbrew.com
auth # 인증을 요구함
usehostname # CHAP을 위한 local hostname을 사용함
lock # UUCP-style 디바이스를 잠그기 위해 사용함
domain.vbrew.com # 우리의 도메인 네임
이들 옵션의 첫번째에 있는 두가지 옵션들이 인증을 위해 사용되며 아래에서 설명되었다. lock 키워드는 pppd가 device를 잠그는 표준 UUCP의 방법을 사용하도록 한다. 이것에 의해 각각의 serial device를 이용하는 프로세스들은, /dev/cua3과 같은, LCK..cua3과 같은 lock 파일을 device가 사용중인 UUCP spool directory로 생성한다. 이것은 minicom이나 uucico와 같은 다른 프로그램들이 PPP가 사용되는 동안 serial device를 사용하는 것을 방지하는데 필요하다. 이러한 옵션들이 전체 설정 화일에 쓰여진 이유는 위에서 보여진 것과 같은 옵션들은 다시 덮어쓰여질 수 없기 때문이고, 그래서 적당한 수준의 보안을 유지할 수 있다. 그러나 이제 보여질 접속에 관한 문자열과 같은 어떤 옵션들은 나중에 다시 덮어씌어 질수 있다는 것에 주목하라.
위에서 보여진 예에서 당신을 불편하게 만들지도 모르는 것 중의 하나는 당신이 pppd를 시작하기 전에 일일이 연결을 해야한 다는 것이다. dip와는 다르게, pppd는 원격의 시스템에 전화를 걸고 접속하는 pppd 자신의 스크립트 언어를 갖고 있지않다. 그러나 이 일을 하기 위해 pppd는 외부 프로그램이나 shell 스크립트에 의존한다. 접속을 위해 실행되어야 할 명령은 command line 옵션으로 pppd에 주어질 수 있다. pppd는 명령의 표준 입력과 출력을 시리얼 라인으로 돌린다. 이를 위한 유용한 프로그램으로는 Don Libes에 의해 쓰여진 expect가 있다. expect는 바로 이런 종류의 프로그램을 위해 고안된 매우 강력한 언어인 Tcl에 기반을 두고 있다. Pppd 패키지는 당신에게 UUCP 스타일의 chat 스크립트를 열거할 수 있게 해주는 chat라는 유사한 프로그램과 함께 딸려온다. 기본적으로, chat 스크립트는 원격 시스템에서 날아오는 문자열과 우리가 그에 대답해야 하는 문자열이 교차되는 순서에 의해 구성되어있다. 우리는 상대적으로 이것들을 expect와 send 문자열이라고 한다. 다음은 chat스크립트의 전형적인 발췌이다.
ogin: b1ff ssword: s3kr3t
이것은 chat가 원격 시스템에서 로그인 프롬프트를 보내오기를 기다렸다가 로그인 네임인 b1ff를 답하는 것을 말해준다. 우리는 단지 ogin: 만을 기다리는데 이로 인해 로그인 프롬프트가 대문자 L인지 소문자 l인지 신경쓰지 않아도 되며, 혹 잘못 날아왔을 경우도 상관없다. 그 다음 문자열은 chat가 패스워드 프롬프트를 기다렸다가 우리의 응답을 보내는 문자열이다. 이것이 기본적으로 chat 스크립트가 하는 것이다. 물론 PPP 서버에 다이얼업에 의한 완전한 스크립트는 적당한 모뎀명령을 포함해야 한다. 당신의 모뎀이 Hayes command set을 이해한다고 하고, 서버의 전화번호가 318714라고 하자. 완전한 c3po에의 접속을 만들기 위한 완전한 chat 스크립트는 다음과 같을 것이다.
$ chat -v '' ATZ OK ATDT318714 CONNECT '' ogin: ppp word: GaGariN
정의에 의해, 처음 문자열은 expect 문자열이 되어야 할 것이지만 모뎀은 우리가 그것을 kick(?)하기전에 모뎀은 아무런 응답도 없을 것이므로 우리는 처음에 빈 문자열을 줌으로써 chat이 처음 expect 문자열을 건너뛰게 해야한다. 그 다음 우리는 ATZ를 보내, Hayes-compatible 모뎀을 위한 리셋 명령을 주고, (OK) 응답을 기다린다. 다음 chat을 통해 전화번호를 다이얼명령으로 보내고, CONNECT 메세지를 기다린다. 여기서 다시 빈 문자열을 받게 되는데, 우리가 아직 아무것도 보내지 않았기 때문이다. 그러나 다시 로그인 프롬프트를 기다리게 된다. Chat 스크립트는 위에서 기술한 그대로 동작한다는 것을 명심하라. -v 옵션은 syslog 대몬의 local2 facility에 의해 모든 활동에 대한 chat log를 만든다. (facility : 만일 당신이 이들 log 메세지를 리다이렉트하도록 syslog.conf를 수정했다면, 이 화일은 읽을 수 없기때문에 chat가 로그들의 암호와 모든 것을 포함한 전체 chat 스크립트를 디폴트로 만든다.)
사용자들이 ps 명령을 이용해 process command를 볼 수 있기 때문에 chat 스크립트를 command line에서 열거하는 것은 다소 위험하다. 그러므로 당신은 chat script를 dial-c3po라 불리는 하나의 화일에 넣음으로서 이런 문제를 피할 수 있다. 당신은 -f '화일명' 옵션을 줌으로 인해 command line에서 명령을 나열하는 대신 화일로부터 스크립트를 읽어들일 수 있다. 그래서 완전한 pppd '주문'은 다음과 같을 것이다.
# pppd connect "chat -f dial-c3po" /dev/cua3 38400 -detach \
crtscts modem defaultroute
다이얼 업 스크립트의 나열에 의한 연결 옵션 이외에도, 우리는 command line에 두 개의 옵션을 추가하였다: pppd에게 콘솔에 달라붙지 말고 백그라운드 프로세스가 되도록 말해주는 -detach이다. 또, modem 키워드는 모뎀에 어떤 동작-전화를 걸기전이나 건 후 선을 끊는 시리얼 장치의 특별한 동작-을 수행한다. 만약 당신이 이 키워드를 사용하지 않는다면, pppd는 포트의 DCD 라인을 모니터하지 않을 것이며 그러면 만일 원격 시스템이 갑자기 끊어졌다든가 하는 경우를 전혀 알아차리지 못한다. 위에서 보여진 예들은 다소 간단한 것이다; chat는 훨씬 더 복잡한 스크립트를 수행할 수 있다. 아주 유용한 한 가지 경우는 chat에 에러가 났을 경우 이를 취소하는 문자열을 보낼 수 있다. 전형적인 취소 문자열들은 당신이 건 전화가 통화중이거나, 전화기를 들지 않았을 경우에 보여지는 BUSY, NO CARIIER와 같은 메세지들이다. chat가 이를 바로 알아차리게 하기 위해서 time out을 기다리기보다는 당신은 chat 스크립트의 시작에 ABORT 키워드를 쓰는 것이 더 낫다.
$ chat -v ABORT BUSY ABORT 'NO CARRIER' '' ATZ OK ...
이와 유사한 경우인데, 당신은 TIMEOUT 옵션을 chat 스크립트에 추가함으로써 timeout 값을 수정할 수 있다. 더 자세한 내용은 chat(8) 매뉴얼 페이지를 읽어보아라. 때때로, 당신은 또한 어떤 종류의 조건적인 chat 스크립트의 실행을 필요로 할 것이다. 한 예로, 원격 시스템의 로긴 프롬프트를 받지 않았을 경우, BREAK를 보내거나 캐리지 리턴을 보내야 할 것이다. 당신은 expect 문자열에 sub-스크립트를 추가함으로써 이를 해결할 수 있다. 그것은 하이픈으로 구분되어 있는 스크립트 전체 그 자체와 같이 send-와 expect-문자열들의 순서로 구성되어있다. sub-스크립트는 기대했던 문자열이 제때에 받아지지 않았을 때에 실행된다. 위의 예에서 우리는 chat 스크립트를 다음과 같이 수정할 수 있다.
ogin:-BREAK-ogin: ppp ssword: GaGariN
이제, chat는 원격 시스템의 로그인 프롬프트가 보이지 않을때, sub-스크립트는 첫 BREAK를 보내고, 다시 로그인 프롬프트를 기다리게 된다. 프롬프트가 나타났을때, 스크립트는 평소와 같이 계속되고, 만일 그렇지 못하면 에러와 함께 끝이 난다.
기본적으로, pppd는 모든 경고들과 에러 메세지들을 syslog의 daemon facility에 로그한다. 콘솔에서도 syslog는 이러한 내용들을 그냥 버려버리기 때문에 당신은 syslog.conf의 첫머리에 이것을 파일로 리다이렉트하도록 하는 내용을 더해야한다.
daemon.* /var/log/ppp-log
만약 당신의 PPP 셋업이 한 번에 성공하지 않는다면 이 로그화일을 들야다봄으로써 무엇이 잘못되고 있는가를 알 수 있다. 이것이 별로 도움이 되지 않는다면 디버그 옵션을 이용해 외부 디버깅 output을 동작하게 할 수 있다. 이것은 syslog에 보내지거나 받은 모든 control packet의 내용을 pppd log를 만든다. 모든 메시지는 deamon facility로 간다.
마지막으로, 가장 과감한 수단은 kdebug 옵션에 의지하는 pppd에 의해 커널-레벨에 의한 디버깅을 가능하게 하는 것이다. 이것은 다음 값들의 bitwise OR 수적인 독립변수를 따른다.: 1은 일반적인 디버그 메세지, 2는 HDLC 프레임으로 들어오는 메세지의 프린팅, 그리고 4는 HDLC 프레임을 통해 나가는 드라이버의 프린트이다. 이러한 커널 디버깅 메세지들은 갈무리하기 위하여, 당신은 /proc/kmsg 화일을 읽도록 syslog 데몬을 실행시키거나 klogd데몬을 실행시켜야 한다. 모두 커널 디버깅을 syslog의 커널 facility로 가도록 지시한다.
IPCP가 링크 설정시간에 있는 두어개의 IP parameter와 교신하기 위하여 사용된다. 일반적으로 각각의 peer는 어떤 값들을 기본값으로부터 바꾸려고 하거나, 어떤 값을 가르키는 IPCP Configuration Request packet을 보낼지도 모른다. 이들의 수신에 의해, 원격 호스트 검사들은 어떤 값들이 설정되어 있는냐에 따라 그것은 인지하거나 거부하게 된다. pppd는 교신을 위한 많은 IPCP 옵션들을 당신에게 준다. 이들의 command line 옵션에 의한 조정에 의해 관해서는 다음에 논의한다.
위의 예에서 우리는 c3po에 전화를 걸고 IP 링크를 만들었었다. 링크의 어느 한쪽에서 특정한 IP-주소를 선택하도록 하는 준비가 없었다. 그 대신 local IP-주소로 우리는 vlager의 주소를 선택했고, c3po가 그 자신의 것을 주도록 했다. 그러나 때때로 링크의 한쪽이나 또다른 한쪽에 어떤 주소를 사용할 것인지 조절하는 것은 매우 유용하다. pppd는 이에 해당하는 여러가지 변화를 줄 수 있다. 특정한 주소들을 묻기위하여, 당신은 일반적으로 pppd의 다음 옵션을 줄 수 있다.
local addr:remote addr
여기서 local_addr과 remote_addr은 4부분으로 이루어진 주소 표기법이거나 호스트네임들로 주어져야한다. 이것은 pppd가 첫번째 주소를 자신의 IP-주소로, 두번째를 peer의 주소로 하도록 만든다. 만약 peer가 둘중 어느 것도 IPCP 교신 중 거부한다면 IP-링크는 성립되지 않을 것이다.
만일 당신이 peer 사용자들의 어떠한 주소도 받아들이지 않고 단지 local address만을 원한다면 remote_addr 부분은 비워두면 된다. 예로, 130.83.4.27이라는 IP주소를 ㅆJ서 vlager를 사용하고 싶다면 단지 command line에서 130.83.4.27:라고 하면 된다. 유사하게, remote_addr만을 사용하기 위해서는 local_addr 부분을 비워두면 된다. 기본값으로, pppd는 당신의 호스트네임과 연관된 주소를 사용한다.
어떤 PPP서버들은 많은 수의 클라이언트 사이틀들에의 주소를 유동적으로 관리한다: 주소들은 단지 전화가 걸려왔을때만 결정되고, 다시 로그오프할 때 해제한다. 그런 다이얼업 서버에서는, 당신은 서버가 당신에게 사용할 주소를 물어오기 보다는 pppd가 서버로부터 특정한 IP-주소를 요구하는 지 않는다는 것을 주의해야 한다. 이것은 당신이 local_addr 변수를 나열하지 말아야 한다는 것을 의미한다. 덧붙여, 당신은 local host의 주소를 사용하는 대신 peer가 제공하는 IP-주소를 사용하도록 하는 noipdefault 옵션을 사용해야 한다.
네트워크 인터페이스를 설정한 후에, pppd는 일반적으로 호스트 경로를 peer에게만 셋업할 것이다. 만약 그 원격호스트가 랜에 있다면, 당신은 '뒤'에 있는 peer 역시 호스트에 연결되기를 원할 것이다. ; 다시말해 네트워크 경로가 설정되어야 한다.
우리는 이미 기본옵션으로 사용할 때 기본 경로로 설정한다는 것을 살펴보았다. 이 옵션은 당신이 전화를 건 PPP 서버를 당신의 인터넷 게이트웨이로 사용할 때 매우 유용하다.
그 반대의 경우, 당신의 시스템이 하나의 호스트를 위한 게이트웨이로 사용될때, 역시 쉬운 방법으로 가능하다. 한 예로, loner라는 가정용 컴퓨터의 사용자인 가상 양조장의 일꾼의 경우를 생각해 볼 수 있다. PPP를 통해 vlager로 접속하는 경우, 그는 양조장 subnet의 주소를 사용할 수 있다. vlager에서는, pppd에 이제는 loner에 proxy ARP를 사용할 수 있는 옵션을 인스톨하는 proxyarp 옵션을 줄 수 있다. 이것은 자동적으로 loner가 양조장과 와인양조장에 있는 모든 호스트에 접근할 수 있도록 만든다.
그러나 모든 경우가 저것처럼 쉽지는 않다. 예로, 두 개의 로컬영역 네트워크를 링크하는 것과 같은 경우일 것이다. 이는 명확한 네트워크 경로를 추가해주어야만 한다. 왜냐하면 이들 네트워크들은 그들 자신만의 기본 경로들을 가지고 있기 때문이다. 그 외에도, PPP 링크를 기본 경로로 사용하여 loop를 형성하게 되는 경우에 양쪽의 peer를 가지게 되는 경우, peer들은 연결되어 있는 시간이 끝날 때까지 마치 탁구를 하는 것처럼 어디로 가야할 지를 모르게 된다.
그 예로, 가상 양조장이 그 연결을 어떤 도시에 열어 놓았다고 하자. 양조장의 B 클래스 네트워크 subnet3인 보조는 그들 자신의 IP 네트워크 넘버 191.72.3.0을 이용하여 이더넷을 운영한다. 그들은 고객의 데이타베이스 등등을 업데이트하기 위해 PPP를 통해 양조장의 주 이더넷에 접속하기를 원할 것이다. 다시, vlager는 게이트웨이처럼 행동하고, 그들의 peer는 sub-etha라 불리고 191.72.3.1..의 IP주소를 가지게 된다.
Sub-etha가 vlager에 접속할 때, 그것은 일반적으로 vlager로 향하는 기본 경로 포인트를 만들 것이다. vlager에서 우리는 sub-etha를 거치는 subnet-3를 위한 네트워크 경로를 설치해야 한다. 이를 위해, 우리는 그렇게까지 어렵지 않은 pppd의 형식-ip-up명령-을 사용할 수 있다. 이것은 간단한 쉘 스크립트이거나 PPP 인터페이스가 제대로 설정되고 난 후에 실행되는 /etc/ppp에 위치하는 프로그램이다. 그것이 있을때, 그것은 다음과 같은 파라미터에 의해 실행된다.
ip-up iface device speed local addr remote addr
여기서 ifcae는 사용되고 있는 네트워크 인터페이스를 명명하고, device는 사용되고 있는 시리얼 장치의 경로명(stdin/stdout이 사용된다면 /dev/tty)이며, speed는 장치의 속도이다. local_addr과 remote_addr는 링크의 양쪽 끝에 :로 나뉘어진 4개 부분으로 된 IP-주소들을 준다. 우리의 경우, ip-up 스크립트는 아마도 다음과 같은 내용을 포함하고 있을 것이다.
#!/bin/sh
case $5 in
191.72.3.1) # this is sub-etha
route add -net 191.72.3.0 gw 191.72.3.1;;
esac
exit 0
이와 비슷한 투로, /etc/ppp/ip-down은 PPP 링크가 죽고 난 후 ip-up가 한 모든 행동을 취소하기 위해 사용된다.
그러나 라우팅 계획은 아직 완벽한 것이 아니다. 우리는 양쪽 PPP 호스트들에 라우팅 테이블의 내용을 설정했지만, 아직 양쪽의 호스트들의 다른 모든 네트워크들은 PPP 링크에 관해서는 아무것도 알지 못한다. 그러나 만약 보조의 모든 호스트들이 sub-etha에 있는 그들의 기본 라우트 지점을 가지고 있고, 모든 양조장의 호스트들이 vlager로 향하는 기본 경로를 가진다하더라도 이것은 그다지 큰 문제는 아니다. 만약 이것이 바로 그런 경우가 아니라면 당신은 gated와 같은 라우팅 데몬만을 사용하면 된다. vlager를 향한 네트워크 경로를 생성하고 난 후에, 라우팅 데몬은 서브넷에 붙어있는 모든 호스트들에 새로운 경로를 알려줄 것이기 때문이다.
앞에서 우리는 이미 링크의 특성들을 교섭하기 위한 Link Control Protocol,LCP를 다루었었다.
LCP에 의해 조정되는 두개의 가장 중요한 옵션들은 maximun receive unit와 Asynchoronous Control Character Map이다. 많은 LCP옵션들이 있기는 하지만, 여기서 논의하기에는 너무 전문화가 되어 있는 것이 사실이다. 그것들을 더 자세히 알아보려면 RFC-1548을 참조하기 바란다.
흔히, async map으로 불리는 Asynchoronous Control Character Map는 반드시 빠져 있어야 하는 control character들을 구분해야 하는 전화선과 같은 비동시적인 링크들을 위해 사용된다. 예를 들어 어떤 잘못된 설정을 가진 모뎀은 XOFF를 받았을 때 죽을지도 모르기 때문에 소프트웨어 handshake를 위해 XON과 XOFF character들을 아마 당신이 원할 지도 모른다. 다른 후보자들은 Ctrl-](텔넷 escape character)를 포함한다. PPP는 ASCII 코드 0에서 31중 어느 값이라도 async map에 나열하면 빠져나오도록 해준다.
async map은 를 ASCII 널문자(ASCII 31)에 해당하는 최소한의 한 문자를 가진 32-비트 폭의 비트맵이다. 만약 비트가 설정되면, 링크를 통해 그것을 보내기 전에 반응하는 문자는 반드시 escape되었는지 신호를 보낸다. 시작하면서 async map은 모든 control character들이 escape되는 0xffffffff을 맞추어진다.
당신의 peer에게 어떤 것들 중 특별한 것을 제외하고는 모든 control character들을 escape할 필요가 없다고 말하기 위해, asyncmap 옵션을 사용하여 새로운 asyncmap을 pppd에 열거할 수 있다. 예로, 단지 ^s와 ^Q(ASCII 17과 19, 일반적으로 XON과 XOFF)만 escape 되어야 한다고 할 때, 다음과 같은 옵션을 사용할 수 있다.
asyncmap 0x000A0000
최대 수신 유닛(Maximum Receive Unit), 혹은 MRU는 peer에게 우리가 받고자 하는 최대HDLC 프레임들의 크기를 보낸다. 이 부분에서 MTU(Maximum Transfre Unit:최대 전송 유닛)을 떠올릴 수도 있겠으나, 이 둘은 거의 공통점이 없다. MTU는 커널 네트워킹 디바이스의 파라미터이고, 그 인터페이스가 조절할 수 있는 최대 프레임의 크기를 나타낸다. MRU는 MRU보다 더 큰 어떠한 프레임도 동작하지 않도록 원격의 말미에 주는 단순한 충고 정도이다.; 그럼에도 불구하고 인터페이스는 최소한 1500프레임까지는 수신할 수 있어야 한다.
그러므로 MRU는 선택하는 것은 어떤 링크가 전송을 할 수 있는지가 문제가 아니라 당신이 어떤 최대의 처리량을 주는 것인가 하는 것이다. 만일 링크를 통해 인터액티브한 프로그램을 사용하기를 원한다면, MRU를 제일 낮은 296으로 주는 것이 좋은데 이로 인해 이따금씩 큰 패킷(뭐, FTP 같은)이 당신의 커서를 "점프"하게 하지 않을 것이다. pppd에 MRU를 296으로 맞추라고 하기 위해, 당신은 mru 296이라는 옵션을 주면 된다. 그러나 작은 MRU들은 당신이 VJ 헤더 압축을 사용하지 않도록 하지 않았을 때 (일반적으로는 가능) 제대로 알아먹는다.
pppd는 링크가 종료되기 전에 교환되는 설정 요청들의 최대 숫자들과 같은 교섭 프로세스의 전체적인 동작을 조정하는 두어개의 LCP옵션을 이해한다. 만약 당신이 무엇을 하는지 정확하게 알고 있지 않다면, 그냥 놔두는 것이 더 낫다.
마지막으로, LCP 에코 메세지들에 적용되는 두 가지 옵션이 있다. PPP는 두가지 메세지들, Echo 요청과 Echo 응답, 을 정의한다. pppd는 이 모양을 어떤 링크가 계속 동작중인지 점검하기 위해 사용한다. 당신은 이것들을 초로 표시하는 시간과 함께 lcp-echo-interval 옵션을 통해 가능하게 할 수 있다. 이 시간 간격 동안 원격 호스트로부터 어떠란 수신도 없다면 pppd는 Echo 요청을 발생시키고, peer가 Echo 응답을 보내오기를 기다린다. 만약 peer가 응답을 해오지 않는다면, 링크는 몇 번의 요청을 보낸 후에 끊어진다. 이 숫자는 lcp-echo-failure 옵션을 사용하여 지정할 수 있다. 기본적으로 이 내용들은 두 가지 모두 동작하지 않도록 되어 있다.
잘못 설정된 PPP 데몬은 보안구멍으로 인해 큰 재앙을 초래한다. 이것은 아무 사용자나 당신의 이더넷으로 들어오도록 하는 최악의 경우이다. 이 장에서는 당신의 PPP 설정을 안전하게 하는 몇가지 측정을 해보도록 하겠다.
pppd의 문제점 중 하나는 네트워크 디바이스와 라우팅 테이블을 설정하는데 root권한을 요구하는 것이다. 일반적으로 당신은 이 문제를 root로 실행시켜서 풀 것이다. 그러나 pppd는 사용자들에게 여러가지 보안과 관련된 옵션들을 사용하도록 허락한다. 이러한 옵션들을 교묘하게 사용한 사용자들의 공격으로부터 보호하기 위해, 지난 장에서 설명한 전체적인 기본 옵션들을 /etc/ppp/options 화일에 적어주는 것을 제안한다. 그들중 authentification 옵션과 같은 것들은 사용자들에 의해 덮어 쓰여질 수 없기 때문에 교묘한 술책에 믿음직한 보호를 해 준다.
물론, 당신 자신도 역시 시스템으로부터 PPP를 말하는 것을 보호해야 한다. 다른 사람들처럼 모든 호스트들을 밀어내기 위하여, 항상 peer로 부터 어떤 종류의 인증을 갖고 있어야 한다. 추가적으로 당신은 외부의 호스트들이 그들이 선택하는 어떠한 IP-주소도 사용 못하도록 해야 하지만 최소한 몇 개는 제한해야 한다. 다음 장에서 이 내용을 다룬다.
PPP를 사용할 때 각각의 시스템은 아마 시스템의 peer에게 그 자신을 두가지 인증 프로토콜 중 하나에 의한 인증을 요구할 지도 모른다. 이 둘이 바로 Password Authentication Protocol(PAP), 그리고 Challenge Handshake Authentication Protocol(CHAP)이다. 접속이 되었을때, 링크의 각각 끝은 다른 한쪽에 그 자신의 인증을 전화를 건쪽이든 전화를 받는 쪽이든 요구하게 된다. 그러므로 이제 아래에서 인증하는 쪽과 인증받는 쪽을 구분하게 될 때 '클라이언트'와 '서버'의 개념을 다소 느슨하게 설명해도 될 것이다. PPP 데몬은 그 peer에게 바람직한 인증 프로토콜을 확인하는 또다른 LCP 설정 요청을 보냄으로써 인증을 물을 수 있다.
PAP는 일반적인 로그인 과정과 같은 간단한 방법으로 동작한다. 클라이언트는 사용자명과 (일반적으로는 암호화된)암호를 보내어 그 자신을 증명하고 서버는 그 자신의 비밀 데이타베이스와 그것을 비교해 본다. 이 기술은 시리얼 라인을 통해 암호를 알아내려 하는 엿듣는 사람과 반복되는 '시행착오' 공격에 취약하다.
CHAP는 이러한 약점을 가지고 있지 않다. CHAP는 인증자(즉, 서버)는 무작위로 만들어진 "challenge" 문자열을 그의 호스트명과 함께 클라이언트에 보낸다. 클라이언트는 호스트명을 적절한 암호, challenge와 조합해서,찾기위해 사용하고, 그 문자열을 단 하나의 hashing 함수를 이용해서 암호화한다. 그 결과는 클라이언트의 호스트명과 함께 서버로 되돌아간다. 그 서버는 이제 같은 계산을 수행하고, 같은 결과가 되돌아왔는 지를 확인하고 클라이언트를 인지한다.
CHAP의 다른 특징은, 단지 클라이언트가 접속을 시작할때의 인증만을 원하지 않고, 클라이언트가 다른 침입자에 의해 바뀌지는 않았는지, 예를 들면 전화선을 바꿔친다든지하는, 확인하기 위해 특정한 시간간격을 두고 challenge들을 클라이언트에 보낸다.
pppd는 상대적으로 /etc/ppp/chap-secrets와 ppp-secrets라는 다른 화일로 CHAP와 PAP를 위한 두개의 비밀 키를 유지한다. 이중 하나나 다른 화일을 통해 다른 원격 서버로 들어감에 의해, 당신은 CHAP나 PAP에 의해 아주 훌륭한 콘트롤을 받게 되고 인증을 받는다.
기본적으로, pppd는 원격서버로부터 인증을 요구하지 않지만 원격서버에서 인증요구가 왔을때는 거기에 동의하여 인증을 하게 된다. CHAP가 PAP보다는 훨씬 더 강력하기 때문에, pppd는 가능하면 CHAP를 사용하려한다. 만약 peer가 그것을 지원하지 않는다거나 만약 pppd가 원격 시스템의 chap-secret 화일로부터 CHAP secret를 찾지 못한다면, PAP로 바뀐다. 만약 PAP 또한 가지고 있지 않다면 인증을 거부하게 되고, 결론적으로 접속은 끊어지게 된다.
이러한 양식은 여러가지로 수정된다. 예로, 주어진 인증 키워드에 대해, pppd는 peer에peer 그 자신이 인증을 하도록 요구하게 된다. pppd는 CHAP나 PAP 데이타베이스에 peer를 위한 secret가 존재하는 하는 한 CHAP나 PAP를 사용하도록 동의할 것이다. 특정한 인증 프로토콜을 켜고 끄는 다른 옵션도 있다. 여기서는 그 내용은 다루지 않겠다. pppd(8) 메뉴얼을 참고하도록 하라.
만약 당신이 PPP를 통한 모든 시스템에 당신과 그들 자신이 인증하도록 하려면, 당신은반드시 auth 옵션을 전체적인 /etc/ppp/options 화일에 넣도록 하고, 각각의 시스템에 해당하는 비밀번호들을 chap-secret화일이 넣어야 한다. 만약 시스템이 CHAP를 지원하지 않는다면, 그를 위한 pap-secret 화일을 첨부하라. 이 방법으로 당신은 당신의 호스트에 증받지 않은 어떤 시스템도 접근하지 못하게 할 수 있다.
다음 두 섹션은 PPP의 두가지 secret 화일인 pap-secrets와 Chap-secrets화일에 관해서 다룰 것이다. 이들은 /etc/ppp에 위치하며 클라이언트들, 서버들, 비밀번호들, 세부분으로 이루어진 내용을 담고 있으며 선택적으로 딸린 IP-주소들의 리스트를 포함한다. 클라이언트와 서버 필드의 해석은 CHAP와 PAP는 서로 다르며, peer에게 어떤 방식으로 인증을 하느냐에 의존하거나 혹은 서버가 우리와 함께 인증을 요구하느냐에 달려있다.
CHAP를 사용한 서버와 그 자신이 인증을 하기 위해서, pppd는 pap-secrets화일에서 로컬 호스트명과 같은 클라이언트 필드를 찾고, CHAP Challenge에서 보내진 원격 호스트명과 같은 서버 필드를 찾는다. peer에게 그 자신을 인증하도록 다시 질의하였을때, 역할은 단순히 반대로 바뀐다:pppd는 원격 호스트명과 같은 클라이언트 필드를 찾고,(클라이언트의 CHAP 응답에서 보내진) 로컬 호스트명과 같은 서버필드를 찾는다.
아래는 vlager를 위한 간단한 chap-secrets 화일이다.
# CHAP secrets for vlager.vbrew.com
#
# client server secret addrs
#-------------------------------------------------------------------
vlager.vbrew.com c3po.lucas.com "Use The Source Luke" vlager.vbr
c3po.lucas.com vlager.vbrew.com "riverrun, pasteve" c3po.lucas
* vlager.vbrew.com "VeryStupidPassword" pub.vbrew.
c3po와의 PPP연결이 이루어 졌을때 c3po는 vlager에게 CHAP Challenge를 보내어 CHAP를 사용해 그 자신을 인증하도록 한다. pppd는 이제 vlager.vbrew.com과 같은 클라이언트 필드를 찾아 chap-secrets 화일을 검색하고 c3po.lucas.com과 같은 서버필드를 찾고, 위에서 보여진 첫번째 줄에서 찾아낸다. 이제 challenge 문자열과 secret(Use The Source Luke)로부터 CHAP 응답이 생겨나고, 그것을 c3po로 보낸다.
동시에 pppd는 특정한 challenge 문자열을 포함하고 있고 확실히 검증된 호스트명인 vlager.vbrew.com를 포함하고 있는 c3po를 위한 CHAP challenge를 작성한다. c3po는 방금 우리가 이야기했던 방식으로 CHAP 응답을 만들고, 그것을 vlager에 되돌려 준다. 이제 pppd는 CHAP 응답으로부터 클라이언트 호스트명(c3po.vbrew.com)을 뽑아내서, 클라이언트로서 c3po가 맞는 부분이 있는지를 chap-secret 화일로부터 찾고, 서버로서 vlager가 있는지를 찾는다. 두분째 줄이 이 역할을 하고, 그래서 pppd는 CHAP challenge와 secert riverrun, pasteve를 암호화 하고 그 결과를 c3po의 CHAP 응답과 비교한다.
네번째 선택적인 필드는 첫번째 필드에서 명명된 클라이언트들에 해당하는 IP-주소들을 나열한다. 그 주소들은 4개 부분을 이루어졌거나, resolver에 의해 인식되는 호스트명들일것이다. 예로 만약 c3po가 IPCP 교섭중에 리스트에 있지 않는 IP 주소를 사용하기를 원한다면, 그 요구는 거절되고, IPCP는 닫혀버릴 것이다. 위에서 보여진 예제화일에서, 그러므로 c3po는 그 자신의 IP-주소를 사용하는 것이 제한된다. 만약 주소 필드가 비어있다면 어떠한 주소들도 허용된다.; -값은 클라이언트 또한 사용하지 못하도록 방지해준다.
chap-secrets 화일의 세번째 줄은 어떠한 호스트명도 클라이언트, 서버필드의 *에 적합하기 때문에 어떤 호스트라도 vlager에 PPP 링크를 만들수 있도록 해준다. 유일한 요구사항은 그것이 secret를 알고, pub.vbrew.com을 사용해야 한다는 것이다. pppd는 항상 서버/클라이언트가 짝을 이루도록 값을 넣기 때문에 와일드카드 호스트명으로 시작하는 entry들은 아마 secrets 화일 어디에서도 보일지도 모른다.
이제 pppd가 어떻게 secrets 화일로부터 호스트명에 이르게 되는지 알아보자. 전에 설명했던 대로, 원격 호스트명은 항상 CHAP Challenge나 응답패킷속에 있는 peer에 의해서 제공된다. 로컬 호스트명은 기본적으로 gethostname(2) 함수에 의해서 전해진다. 만약 당신이 시스템명을 당신의 제한된 호스트명으로 준다면 다음과 같이 domain 옵션을 사용해서 pppd에 domain name을 주어야 한다.
# pppd ...domain vbrew.com
이것은 Brewery의 domain name을 모든 인증과 관련된 활동들과 함께 vlager에 덧붙인다. 로컬 호스트명을 위한 progpppd의 수정된 다른 옵션들은 usehostname과 name이다. 당신이 "local:varremote"라는 command line 명령을 통해 로컬 IP 주소를 주었을 때, local은 4개의 :로 구분된 숫자를 대신하는 name이고, pppd는 이를 로컬 호스트명으로 사용할 것이다. 더 자세한 예는 pppd(8) 매뉴얼 페이지를 참고하기 바란다.
PAP secerts 화일은 CHAP와 매우 비슷하다. 처음의 두 필드는 항상 사용자명과 서버명을 담고 있다; 세번째는 PAP secret를 담고 있다. 원격이 인증 요청을 보내올때, pppd는 로컬 호스트명과 서버필드가 같은지를 사용하며, 사용자 필드는 요청에서 보내진 사용자명과 같은 지를 검사한다. peer와 자신을 위한 인증이 이루어질때, pppd는 라인을 통해 로컬 사용자명과 같은 사용자 필드와 함께 온 온 secret를 선택하고 서버필드와 같은 원격 호스트명을 사용한다.
예제 PAP secrets 화일은 아마 다음과 같을 것이다.
# /etc/ppp/pap-secrets
#
# user server secret addrs
vlager-pap c3po cresspahl vlager.vbrew.com
c3po vlager DonaldGNUth c3po.lucas.com
첫번째 줄은 우리 자신이 c3po에 인증하기 위해 사용된다. 두번째 줄은 어떻게 c3po로 이름지어진 사용자가 그 자신이 우리와 함께 인증되는 가를 나타내 준다.
첫번째 컬럼에 있는 vlager-pap라는 이름은 우리가 c3po로 보내는 사용자명이다. 기본적으로 pppd는 로컬 호스트명을 사용자명으로 선택한다. 그러나 당신은 name 뒤에 따라오는 user 옵션을 사용하여 다른 이름을 열거할 수 있다.
peer와의 인증을 위해 pap-secrets 화일에서 entry를 가져 올 때, pppd는 원격 호스트의 이름을 알아야 한다. 그것을 알아낼 방법이 없기 때문에 당신은 반드시 peer의 호스트명뒤에 따라오는 remotename이라는 키워드를 사용해서 command line에서 열거해야한다. 예로 위에서 보여진 예에서 c3po로의 인증을 위해, 우리는 반드시 다음 옵션을 pppd의 command line에 적어주어야 한다.
# pppd ...domain vbrew.com
네번째 부분에(그리고 그 뒤에 오는 모든 부분은), CHAP에서 그랬던 것처럼 당신이 어떤 IP-주소들을 특정한 호스트에 허용할 것인지를 나열할 수 있다. peer는 이제 리스트에 있는 주소들만을 요청할 수 있다. 예제화일에서, 우리는 c3po에 그것의 실제 IP 주소를 사용하도록 하고 있다.
PAP는 인증방법으로는 다소 약하다는 것을 명심하라. 그리고 가능하다면 CHAP를 사용하기를 권장한다. 그래서 여기에서는 PAP에 관해 폭넓게 다루지는 않을 것이다. PAP를 사용하는데 관심이 있다면 pppd(8) 매뉴얼 페이지에서 더 많은 PAP의 특징이 관해서 찾아보도록 하라.
pppd를 서버로 쓰기 위해서는 단지 command line에서 적당한 옵션을 추가해 주기만 하면 된다. 가장 이상적으로는, 당신은 ppp라는 특별한 계정을 하나 만들어서 그 계정의 로그인 쉘을 pppd 옵션을 주는 스크립트로 주면 된다. 한 예로 당신은 /etc/passwd에 다음과 같이 추가하면 된다.
ppp:*:500:200:Public PPP Account:/tmp:/etc/ppp/ppplogin
물론, 당신은 위의 예에서 보여진 것과는 다른 uid와 gid를 원할지도 모른다. 또 passwd 명령을 이용해서 위의 계정의 비밀번호를 부여해야 한다.
ppp 로그인 스크립트는 아마 다음과 같을 것이다.
#!/bin/sh
# ppplogin - script to fire up pppd on login
mesg n
stty -echo
exec pppd -detach silent modem crtscts
mseg 명령은 다른 사용자들이 사용중인 tty에 쓰기를 불가능하게 한다. 예로, write 명령을 들 수 있다. stty 명령은 문자의 echo를 끈다. 이것은 peer가 보낸 내용이 ehco되어 되돌아 올수도 있기 때문에 필요하다. 위에서 주어진 가장 중요한 pppd 옵션은 -detach 명령이다. 이것은 control중인 tty에서 pppd가 detach하는 것을 막기 때문이다. 만약 우리가 이 옵션을 사용하지 않는다면 pppd는 백그라운드로 들어가게 되고, 어떤 쉘 스크립트는 끝나게 될지도 모른다. 이로 인해 시리얼 라인이 끊기고 접속이 해제된다. silent 옵션은 pppd가 시작하기 전에 전화거는 쪽 시스템이 패킷을 받을 때까지 기다리도록 하게 한다. 이것은 전화거는 쪽의 시스템이 PPP 클라이언트의 시작이 너무 늦을 때 timeout이 되어 끊기는 것을 방지해 준다. 모뎀은 만약 peer가 접속에서 끊기지 않았는지 감시하는 DTR 라인의 pppd watch를 만들고, crtscts는 하드웨어 handshake를 작동시킨다.
이러한 옵션들 이외에도, 당신은 이 외의 더 강력한 인증을 원할 수도 있다, 한 예로 pppd의 command line에서 사용자의 인증을 열거하거나, 전체적인 옵션에서 설정할 수 도 있다. man 페이지는 더 많은 개개의 인증 프로토콜에 관한 옵션을 켜고 끄는 것에 대한 논의를 하고 있다.