Linux VPN 클라이언트를 구형 어플라이언스 프로토콜에 맞추기

네 가지 프로토콜 계열이 랙에 아직 남아 있는 거의 모든 장비를 덮고, 각각 Linux에서 서로 다르게 실패합니다. 어떤 패키지를 쓸지는 원격 쪽이 공개한 포트와 설정된 제안이 결정하며, 우연히 실행 중인 배포판이 아닙니다. 포럼 글이 언급한 것을 설치하고 뭔가 연결될 때까지 편집하는 것이 바로 오후를 날리는 방식입니다. 장비를 먼저 읽고, 두 번째로 설치하고, 세 번째로 검증하십시오.

원격 쪽이 공개하는 것을 기록하십시오

패키지 관리자를 열기 전에 장비가 기대하는 프로토콜과 포트, 인증을 적어 두십시오. 네 계열이 오래된 장비 대부분을 덮고, 아래 표가 그 결정 전체를 한 화면에 담고 있습니다.

설명서와 장비 자체의 방화벽 규칙은 로그인 페이지에 적힌 프로토콜 이름보다 믿을 만합니다. IPsec을 광고하는 장비가 IKEv1만 말할 수 있고, 아무도 적용하지 않은 펌웨어 릴리스가 나중에 IKEv2를 추가하는 것일 수도 있습니다. 데이터 경로와 설정 포트를 모두 확인하십시오. 오래된 장비와 현대 네트워크가 갈리는 곳이 바로 거기입니다. 이 단계를 틀리면 상대가 한 번도 가져본 적 없는 기능을 상대로 클라이언트를 디버깅하게 됩니다.

PPTP: pppd를 편집하기 전에 GRE를 증명하십시오

Linux에서 PPTP는 시작하는 데몬이 아니라 pppd 호출이며, 연결 매개변수는 호출될 때 pppd가 읽는 이름 있는 peer 파일에 있습니다. 배포판은 여전히 패키징하지만 이 프로토콜의 알려진 약점 때문에 민감한 용도에는 부적합하므로, 다른 것을 제공하지 않는 장비에만 엄격히 남겨 두십시오. 클라이언트가 협상하는 동안 GRE를 관찰하되, 추측이 아니라 짧은 캡처로 확인하십시오. 가장 많은 시간을 낭비하는 실패는 인증이 아니라 빠진 데이터 경로입니다.

pppd call branch-office
tcpdump -ni any proto gre -c 5

설정이 끝났는데 링크가 트래픽을 전혀 나르지 않는다면, 자격 증명을 건드리기 전에 GRE 경로를 의심하십시오. 클라우드 보안 그룹에는 프로토콜 47에 대한 명시적 규칙이 필요하고, 일부 네트워크는 보이는 오류도 없이 그것을 완전히 차단합니다. 실제로 사용할 네트워크에서 테스트하고, 모든 것을 허용하는 실험실에서 하지 마십시오.

L2TP/IPsec: 맞는 제안 하나가 열 번의 시도를 이깁니다

데스크톱 대화 상자 대신 데몬 로그를 읽으십시오. 대화 상자는 여러 다른 실패를 하나의 메시지로 합쳐 버립니다. NO_PROPOSAL_CHOSEN 오류는 첫 단계에 속합니다. 클라이언트가 서버가 받아들이지 않을 암호화, 해시 또는 Diffie-Hellman 그룹을 제안한 것입니다. 장비가 무엇을 지원하는지 나열하고 거기에 맞는 제안 하나를 쓰십시오. 무작위 조합은 대개 같은 오류를 더 느리게 낼 뿐입니다. 데스크톱에서는 strongSwan이나 Libreswan을 아래에 둔 NetworkManager L2TP 플러그인이 실용적인 클라이언트입니다.

데스크톱 플러그인에게 한 가지를 뜻하는 제안 문자열이 작업을 넘겨받는 데몬에게는 다른 뜻일 수 있으므로, 편집하는 계층에 맞는 문법을 유지하십시오. 장비가 터널 비밀도 요구한다면 그것은 IPsec 키와 별개의 단계입니다. 무엇이든 입력하기 전에 인터페이스가 둘 중 어느 것을 묻는지 확인하십시오.

XAuth를 쓰는 공격적 IKEv1, 그리고 포털의 경우

FortiGate 스타일 엔드포인트는 보통 XAuth와 구성 모드 주소를 쓰는 공격적 모드를 원하는데, 그래픽 플러그인은 이를 아예 노출하지 않을 수 있습니다. 네이티브 데몬은 이를 처리하며, 아래 블록은 완전한 파일이 아니라 그 구성의 형태입니다. 제안 값은 벤더의 최신 문서를 확인하십시오.

conn branch
    keyexchange=ikev1
    aggressive=yes
    leftauth=psk
    leftauth2=xauth
    leftsourceip=%config
    right=203.0.113.10

이전 strongSwan 릴리스는 버전 5가 leftauth2=xauth를 쓰는 자리에서 xauth=client를 썼으므로, 복사한 스니펫은 문법만으로도 실패할 수 있습니다. TLS 포털에서는 AnyConnect 프로토콜을 쓰는 openconnect가 Cisco와 대부분의 리브랜드 제품을 처리하며, TUN 장치와 그것을 구성할 권한이 필요합니다. 포털 주소는 브라우저가 보여 주는 그대로, 장비가 기대하는 경로까지 포함해 전달하고, 그 뒤의 무엇이든 테스트하기 전에 할당된 주소를 확인하십시오. 인터페이스를 미리 만들어 두면 설정 중의 놀라움 한 종류를 없앨 수 있습니다.

sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com

연결한 다음 정해진 순서로 검증하십시오

VPN 관리자는 한 번에 정확히 하나만 실행하십시오. NetworkManager 프로필과 손으로 시작한 데몬은 경로와 DNS를 두고 다툽니다. 수동 연결을 시험하기 전에 프로필을 내리고, 낡은 터널 인터페이스가 살아 있지 않은지 확인하십시오. 그다음 이 순서로 검증하십시오. 터널 주소, 필요한 유일한 내부 호스트로 가는 경로, 이름 해석, 마지막으로 실제 요청입니다. 초록 아이콘이 증명하는 것은 인증뿐입니다.

ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal

어떤 단계가 실패하면 다음을 시험하지 말고 거기서 멈추십시오. 끊긴 경로 아래의 DNS 실패는 아무것도 가르쳐 주지 않습니다. 실험하기 전에 동작하는 프로필의 사본을 저장하십시오. 지운 연결 파일은 잃기 쉽고 다시 만들기는 번거롭습니다. 제안 값은 장비 모델, 펌웨어 버전과 같은 메모에 남기십시오. 그 메모가 상자를 교체할 때 이전과 고고학 프로젝트를 가르는 차이입니다.