연결이 올라오고 어댑터가 사무실 범위의 주소를 보여 주므로, VPN이 LAN 주소를 주고 따라서 당신을 LAN에 올려놓았다는 결론이 자연스럽습니다. 그 두 절반 중 어느 것도 완전히 맞지는 않습니다. L2TP PPP 세션을 실어 나르며, PPP는 IPCP로 내부 IPv4 주소를 협상합니다. 그 주소는 두 피어 사이에서 합의된 세션 매개변수이지 사무실 DHCP 서버가 내준 임대가 아니며, 그것을 가졌다고 해서 사무실 배선의 이웃이 되는 것도 아닙니다.

하나의 연결에 두 주소

L2TP 연결에는 독립적인 협상이 두 개 있습니다. 바깥 협상은 이미 가진 네트워크 위에서 장치와 VPN 엔드포인트 사이에 보호된 경로를 세웁니다. 안쪽 협상이 PPP 세션이며, 여기서 세션 주소와 상대 주소가 합의됩니다. 인터넷 트래픽은 전혀 세 번째 주소, 즉 엔드포인트의 공인 주소로 나갈 수 있어서 VPN 확인 페이지와 어댑터 주소가 좀처럼 일치하지 않습니다.

이 세 역할을 분리해 두면 사람들이 이 계층에 가져오는 질문 대부분에 답이 됩니다. VPN 인터페이스의 사설 번호는 정상이고 예상된 것입니다. 그것은 엔드포인트가 공인 출구를 바꿨는지에 대해 아무 말도 하지 않으며, 트래픽이 어느 목적지에 닿는지를 그것만으로 결정하지도 않습니다.

IPCP가 정확히 하는 일

IPCP는 PPP를 위한 IPv4 제어 프로토콜입니다. 양쪽은 원하는 옵션을 설명하는 Configure-Request 메시지를 보내고, 주소 옵션은 그중 하나입니다. 아직 주소가 없는 클라이언트는 보통 0.0.0.0으로 요청하고, 서버는 클라이언트가 쓰기를 원하는 주소를 담은 Configure-Nak으로 응답합니다. 그다음 클라이언트가 그 주소를 요청하고, 세션은 로컬 주소와 원격 주소를 가지고 올라옵니다.

그 교환은 PPP와 IPCP 명세에 문서화되어 있으며, 버그처럼 보이는 세부를 설명합니다: 주소는 서버가 자기 정책에 따라 고르며, 그것은 풀, 사용자별 설정, 또는 인증된 신원에 묶인 주소일 수 있습니다. 풀이 고갈되거나 정책이 요청과 충돌하면 인증은 성공하는데 주소 협상이 실패할 수 있고, 클라이언트는 결코 안정되지 않는 연결을 보고합니다.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

pppd 로그에서 로컬 주소와 원격 주소를 명시한 줄이 그 협상의 성공적인 끝입니다. 성공한 인증 옆에 그 줄이 없다는 것은 자격 증명이 아니라 주소 단계를 가리킵니다.

LAN이 당신에게 응답할 수 없는 이유

먼 쪽 범위의 주소는 그 LAN의 호스트가 당신에게 닿을 수 있다는 기대를 만들지만, 서버가 세션 주소를 터널로 되돌려 라우팅하지 않는 한 대개 닿지 못합니다. 풀 안에 있다는 것은 할당에 대한 진술이지 토폴로지에 대한 것이 아닙니다. 사무실 파일 서버는 VPN 서버가 전달하지 않는 한 세션 주소로 가는 경로가 없고, 전달하더라도 허용되지 않을 수 있습니다.

겹치는 범위가 겉보기 크기에 비례하지 않는 문제를 일으키는 것도 같은 이유입니다. 풀이 클라이언트가 이미 쓰는 LAN과 겹치면 클라이언트의 라우팅 테이블에는 이제 같은 프리픽스에 대한 두 주장이 생기고, 터널과 아무 관계 없는 이유로 잘못된 쪽이 이기는 일이 잦습니다.

세션을 확인하고, 그다음 경로를 확인하십시오

먼저 인터페이스, 다음으로 경로, 그다음 중요한 목적지 하나를 확인하십시오. 각 단계에는 저마다의 실패 방식이 있고, 셋을 한꺼번에 시험하면 나중에 변호할 수 없는 결론이 나옵니다.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

공인 확인이 엔드포인트 주소를 보여 주는데 사설 목적지가 시간 초과라면, 터널은 기본 경로를 실어 나르고 있고 먼 쪽은 그 목적지에 응답하지 않는 것입니다. 사설 목적지가 응답하는데 공인 확인이 바뀌지 않는다면, 프로필은 분할 터널을 쓰고 있으며 일부 트래픽만 세션을 사용합니다.

세 단계를 분리해 두십시오

인증, 주소 협상, 전달은 각기 다른 방식으로 실패합니다, 그리고 각각 담당이 다릅니다. 자격 증명은 신원 문제이고, IPCP 고갈은 서버 정책 문제이며, 돌아오는 경로의 부재는 네트워크 설계 문제입니다. 셋 모두를 “VPN이 고장 났다”고 보고하면 느린 수리를 보장합니다.

할당된 주소, 그것이 온 풀, 그리고 LAN이 그곳에 닿아야 하는지를 기록하십시오. 그 한 줄의 메모가 다음 사람이 DHCP 임대라고 가정하고 관여한 적 없는 범위를 찾는 일을 막습니다.

관련 글