Mac L2TP 분할 경로: 호스트 주소가 작동하지 않는 이유

VPN은 연결되고 메뉴 막대에 표시되는데도 내부 호스트는 여전히 시간 초과가 납니다. 이런 상황에는 세 가지 가능한 원인이 있고, 어느 것이 해당하는지는 터널이 어떻게 구성되었는지에 달려 있습니다. 경로 명령이 네트워크 주소가 필요한 자리에서 호스트 주소를 사용했거나, 프로필 자체가 결정을 삼켜 버리는 기본 경로를 설치하거나, 클라이언트가 프로필 키 대신 훅이 필요한 PPP 터널인 경우입니다. 이 순서대로 확인하세요. 첫 번째를 배제하는 것이 가장 저렴합니다.

목적지는 네트워크 주소이고, 마스크는 접두사를 나타냅니다

networksetup -setadditionalroutes는 목적지, 서브넷 마스크, 게이트웨이의 삼중항을 받습니다. 내부 서브넷 하나를 터널로 보내는 호출은 다음과 같습니다:

sudo networksetup -setadditionalroutes "VPN (L2TP)" 192.168.1.0 255.255.255.0 10.2.0.0

목적지가 무엇인지 보세요. 네트워크 주소이며, 도달하려는 서버의 주소가 아닙니다. 이 글을 낳은 사례에서는 그 자리에 192.168.1.20를 둔 동일한 명령이 아무 쓸모도 없었고, 192.168.1.0로 바꾸자 즉시 작동했습니다. 같은 마스크, 같은 게이트웨이, 다른 숫자 하나. 이것이 실패의 전부를 축소한 모습입니다.

이유는 정책이 아니라 산술입니다. /24 마스크와 짝지은 호스트 주소는 192.168.1.0/24를 설명하지 않습니다. 라우팅 테이블이 유용하게 담을 수 없는 무엇인가를 설명하므로 항목은 거부되거나 무시되고, 터널은 결국 의도보다 적게 나릅니다.

정확히 호스트 하나를 원할 때는 호스트 주소에 255.255.255.255 마스크를 사용하세요. 잘못되는 것은 혼합된 쌍이며, 호스트 주소의 사용 자체가 아닙니다. 한 주소로 만든 /32는 정당한 경로이고, 한 주소로 만든 /24는 실수입니다.

호출은 목록을 대체하고, 이름은 문자 그대로입니다

첫 시도에서 두 가지 동작이 사람들을 놀라게 합니다. 명령은 추가가 아니라 추가 경로 목록 전체를 설정하므로, 접두사 하나를 더하는 호출은 이전에 있던 다른 것들을 조용히 제거합니다. 전체 집합을 한 번의 호출로 만드세요.

서비스 이름도 당신이 지어낸 라벨이 아닙니다. 도구에서 읽고 유형 접미사까지 포함해 정확히 복사하세요:

networksetup -listallnetworkservices

한 글자만 다른 이름은 읽을 가치가 있는 오류도, 경로도 만들지 않습니다. 여기서 올바른 기법은 복사하여 붙여넣기이며, 기억에서 다시 입력하는 것이 아닙니다.

프로필이 기본 경로를 주장할 때

분할 경로는 명시적으로 포함하지 않는 모든 목적지에서 기본 경로에 집니다. 전체 터널로 구성된 L2TP 프로필은 바로 그것을 설치합니다. 프로필이 모든 것이 터널을 지난다고 말하면 추가 경로 목록은 거의 바뀌지 않습니다. 당신의 항목은 틀린 것이 아니라, 결코 이름 붙이지 않는 목적지에는 무관할 뿐입니다. 이에 대한 통제는 보통 어떤 경로 명령이 아니라 프로필의 모든 트래픽 보내기 설정에 있습니다.

더 많은 항목을 편집하기 전에 정말로 어떤 모델을 원하는지 결정하세요. 예외가 있는 전체 터널은 특정 접두사가 있는 분할 터널과 다른 구성이며, 둘을 섞으면 아무도 예측할 수 없는 표가 됩니다.

조직이 전체 터널을 요구한다면 로컬에서 분할하려는 시도를 멈추고 요구 사항을 정책 소유자에게 가져가세요. 그것에 반하는 로컬 추가 경로는 어차피 다음 프로필 업데이트에서 제거됩니다.

PPP 터널에는 키가 아니라 훅이 필요합니다

PPP 기반 터널에서 defaultroute는 기본 경로를 만드는 프로필 키입니다. 제거하면 클라이언트는 모든 목적지를 주장하지 않습니다. 그런 다음 인터페이스가 나타난 뒤 경로가 추가되며, 보통 /etc/ppp/ip-up에서 가져옵니다:

#!/bin/sh
/sbin/route add -net 192.168.1.0 -interface ppp0

스크립트는 root 소유이고 실행 가능하게 유지하고, 머신에 터널 프로필이 둘 이상 있을 때 인터페이스 이름에 가드를 추가하세요. 모든 PPP 링크마다 실행되며 장치 이름 하나를 가정하는 훅은 수명이 긴 작은 버그입니다.

세 가지 요청으로 분할을 검증합니다

연결된 동안 표를 캡처하고 어떤 인터페이스가 터널을 담당하는지 기록하세요. 그런 다음 그것을 만든 명령의 종료 상태를 믿는 대신 특정 목적지를 확인하세요. 종료 코드는 도구가 인수를 받아들였는지 알려줄 뿐, 트래픽이 의도한 경로를 가는지는 알려주지 않습니다.

분할을 증명하는 세 가지 요청으로 마무리하세요. 주소로 내부 호스트 하나, 내부 리졸버를 통한 내부 이름 하나, 그리고 여전히 로컬 연결을 사용해야 하는 공개 사이트 하나입니다. 공개 사이트도 이제 터널을 지난다면, 경로 목록이 무엇을 말하든 분할은 일어나지 않은 것입니다.

한 번 더 다시 연결하여 내부 요청을 반복하는 이유는, 손으로 추가한 경로가 그것을 유효하게 만든 인터페이스보다 오래 살 수 있고, 터널이 끊긴 뒤 트래픽을 조용히 블랙홀로 만들 수 있기 때문입니다.