같은 라우터 뒤에서 VPN 클라이언트 하나만 연결되는 이유

두 대의 노트북이 같은 홈 네트워크에 있고, 사무실 VPN은 그중 정확히 한 대만 받아들입니다. 두 번째는 시간 초과가 되거나 첫 번째가 끊길 때까지 기다리며, 두 시도 사이에 아무도 클라이언트 설정을 건드리지 않았습니다. 자격 증명은 일 분 전에 성공한 것과 같으므로 인증이 원인이 아니라는 단서입니다. 이 패턴을 만드는 원리는 세 가지이며, 어느 것에 직면했는지는 서버 자체의 로그가 알려 줍니다.

클라이언트를 건드리기 전에 게이트웨이 로그를 읽으십시오

두 시도에 대한 서버 기록이 첫 질문에 답하며, 그 답은 세 가지 중 하나입니다. 두 번째 시도가 그 로그에 전혀 나타나지 않으면 패킷이 수신자에게 도달하지 않았고, 문제는 홈 라우터나 통신사 경로에 있습니다. 로그가 시도를 기록하고 거부하면 터널은 도착한 것이므로, 문제는 신원, 라이선스, 세션 한도이며 회선 위의 무언가가 아닙니다. 로그가 성공한 세션을 기록하는데 클라이언트가 여전히 실패를 보고하면, 되돌아오는 경로나 두 클라이언트에 같은 터널 주소가 주어지는지를 확인하십시오.

휴대전화 핫스폿은 첫 번째가 연결된 상태에서 두 번째 클라이언트를 모바일 데이터로 실행해 그 두 계열을 저렴하게 갈라 줍니다. 거기서 성공하면 홈 네트워크가 의심되고, 거기서 같은 실패가 나면 게이트웨이가 의심되어 라우터는 결백해집니다. 어느 결과도 단독으로는 결정적이지 않지만, 각각 한 번의 시도로 탐색 공간의 절반을 없앱니다.

무엇이든 바꾸기 전에 결과를 적어 두십시오. 세 가지 중 무엇을 보았는지 적은 메모는, 로그의 세 결과가 서로 무관한 세 가지 수리로 이어지기 때문에, 클라이언트 오류 화면 캡처보다 값집니다.

라우터가 GRE와 NAT-T를 어떻게 다루는가

PPTP는 전형적인 원인으로, 제어 채널은 TCP 1723이고 데이터 경로는 GRE, 즉 IP 프로토콜 47입니다. 많은 가정용 라우터는 제어 연결 하나만 추적하는 PPTP 도우미를 넣고 나오므로, 같은 NAT 뒤의 두 번째 클라이언트는 제어 채널을 열어도 데이터 경로를 전혀 받지 못합니다. 번호 47인 TCP 포트를 전달해도 GRE에 아무 효과가 없는 것은 GRE가 포트가 아니라 프로토콜 번호이기 때문입니다.

L2TP over IPsec은 설계상 다르게 동작하는데, IKE는 UDP 500을 쓰고 NAT 통과는 보호된 페이로드를 UDP 4500으로 옮기며, 캡슐화는 바로 하나의 주소 뒤에 있는 여러 클라이언트가 같은 게이트웨이에 닿도록 존재합니다. 그 설계는 게이트웨이나 중간 장비가 주소별 세션 한도를 부과하는 것을 막지 않으며, 소파에서 보면 두 실패는 똑같아 보입니다. SoftEther의 자체 프로토콜도 같은 부류의 문제를 안고 있어, 패스스루가 동작하지 않는 라우터는 LAN에서 첫 클라이언트를 들이고 두 번째를 떨어뜨립니다. 옛 클라이언트를 위해 작성된 도우미가 현재 클라이언트가 보내는 패킷을 망가뜨릴 수 있으므로 라우터의 ALG 또는 패스스루 스위치를 두 위치에서 모두 시험하십시오.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

전송 한도처럼 보이는 신원 한도

라우터만이 용의자는 아니며, 로그가 라우터와 다른 원인을 구분해 줍니다. OpenVPN 서버가 공통 이름을 하나의 터널 주소에 고정하면 두 기기가 그 주소를 받고, duplicate-cn가 없으면 새 세션이 옛 세션을 밀어냅니다. 그 옵션을 켜면 둘 다 연결된 채로 남지만 하나의 신원, 하나의 인증서, 하나의 폐기 결정을 공유하게 되어 보기보다 나쁩니다. 그러면 두 번째 기기만 따로 폐기할 수 없게 되므로, 편의를 위한 스위치가 나중에 필요할 수 있는 통제를 조용히 없앱니다.

서버 저널과 상태 파일을 함께 읽으면, 하나는 인증 결정을, 다른 하나는 지금 누가 연결되어 있는지를 보여 줍니다. 같은 공통 이름과 하나의 가상 주소를 공유하는 두 항목은 라우터 한도가 아니라 신원 충돌을 확인해 줍니다. 상용 게이트웨이는 동시 세션 하나만 허용하는 요금제, 라이선스 수, 공인 주소마다 세션 하나를 허용하는 규칙 같은 자체 한도를 더하며, 라우터 설정으로는 그중 어느 것도 바뀌지 않습니다.

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

수리를 로그 항목에 맞추십시오

로그의 거부는 기기마다 별도의 자격 증명, 서비스 운영자로부터의 더 높은 한도, 또는 한 대의 기기를 위한 두 번째 게이트웨이 엔드포인트를 요구합니다. 두 번째 시도가 서버에 전혀 닿지 않는다면, 오래가는 수리는 프로토콜을 전달하고 세션을 하나보다 많이 유지하는 라우터이거나, 라우터가 잘 다루는 전송 방식, 예컨대 단일 TCP 또는 UDP 흐름입니다. 둘 중 무엇을 고르느냐는 하드웨어 수명에 관한 결정이며 클라이언트 설정에 관한 것이 아닙니다.

동작하는 기기의 프로필을 두 번째 기기에 복사하고 끝냈다고 하지 마십시오. 그것은 잃어버린 노트북을 아직 쓰이는 사본과 구분할 수 없게 만들어 연결 문제를 접근 통제 문제로 바꿉니다. 원래 결함도 가려지며, 세 번째 기기가 나타나는 순간 다시 돌아옵니다.

두 개의 살아 있는 세션 검증

두 기기를 동시에 연결하고 각각에서 의도한 앱을 실행한 뒤, 하나를 다시 연결해 같은 일을 반복하십시오. 잠깐 나타나는 두 번째 아이콘은 트래픽에 대해 아무것도 증명하지 못하며, 열 분 뒤에 끊기는 세션은 다른 담당자의 다른 결함입니다. 마지막에 서버가 보고하는 것과 사용자가 본 것을 비교하십시오, 이 두 이야기는 자주 어긋나기 때문입니다.

두 세션이 모두 살아남아 트래픽을 실어 나르면 수정이 유지되고, 처음에 적은 메모가 무엇이 잘못이었는지의 기록이 됩니다. 하나만 살아남으면 첫 단계로 돌아가 지금 세 로그 결과 중 어느 것인지 확인하십시오, 답이 바뀌었을 수 있기 때문입니다. 라우터 도우미는 다른 네트워크에서 다시 나타나는 문제를 가릴 수 있지만, 주소별 한도는 기기가 아니라 사용자를 따라갑니다. 두 번째 네트워크에서 시험하는 것이 실제로 무엇을 고쳤는지 아는 가장 값싼 방법입니다.