Android의 L2TP 자동화: 스크립트는 요청할 수 있지만 구축할 수는 없다
shell 경로는 Android에서 L2TP/IPsec을 올리지 않습니다. IPsec, L2TP, PPP, 플랫폼 정책이 각각 한 부분을 맡으므로 무엇이 제어할 수 있는지 선택해야 합니다.
오해는 L2TP 가 Android에서 shell 스크립트가 시작할 수 있는 또 하나의 대상이라는 것입니다. 경로를 추가하고 옛 서비스를 호출하면 끝이라는 거죠. 그럴 수 없습니다. 터널이 패킷을 실어 나르기 전에 네 개의 서로 다른 계층이 합의해야 하기 때문입니다. IPsec 계층은 경로를 보호하고, L2TP는 세션을 나르며, PPP는 링크를 협상하고, Android는 그 결과를 라우팅할 수 있는 VPN으로 등록해야 합니다. 복사한 명령으로 두 번 시도하는 것을 보았는데, 두 번 모두 경로만 존재하고 아무것도 암호화되지 않았습니다.
경로 변경이 실제로 하는 일
경로를 추가하는 것은 패킷이 다음에 어디로 갈지 결정합니다. 보안 연결을 협상하지 않고, L2TP 세션을 열지 않으며, 주소와 피어, DNS 설정을 만들어 내는 PPP 교환도 실행하지 않습니다. 핸드셋에서 보이는 결과는 잘못된 경로로 나가는 트래픽, 혹은 나갔다가 죽는 트래픽이며, 어디에도 터널 상태는 없습니다.
구 버전에서 복사한 서비스 호출도 마찬가지입니다. Android의 내부 VPN 배관은 공개된 자동화 API가 아니며, 다른 버전의 번호가 매겨진 트랜잭션은 다른 작업에 닿거나 스크립트에 없는 권한을 요구할 수 있습니다. 비밀번호를 운반하는 자동화는 추측한 내부 인수에 의존해서는 안 됩니다. 실패 방식이 조용한 no-op이거나 아무도 정리하지 않는 반쯤 만들어진 프로필이기 때문입니다.
네 명의 소유자, 스크립트는 그중 어느 것도 아니다
순서대로 보십시오. IPsec은 보호된 경로를 설정하고 유지하며 피어를 인증합니다. L2TP는 그 위로 세션을 나르고, 이런 계층화 때문에 표준은 둘을 하나의 프로토콜이 아니라 별개의 메커니즘으로 다룹니다. 그 안에서 PPP는 클라이언트가 사용할 링크 매개변수를 협상합니다. 그다음 Android가 플랫폼 측을 소유합니다. 등록된 VPN 인터페이스, 앱별 범위, always-on 상태, 그리고 앱이 종료될 때 무슨 일이 일어나는지 결정하는 수명 주기입니다.
스크립트는 그 계층 중 마지막만 볼 수 있고, 보통 간접적으로 봅니다. 그 클라이언트가 문서화된 제어를 노출하면 연결을 요청할 수 있고, 이후 인터페이스 상태를 지켜볼 수 있습니다. 아래 세 계층을 대신할 수 없고, 플랫폼이 등록되지 않은 인터페이스를 VPN으로 취급하게 만들 수도 없습니다.
데몬도 지름길이 아닌 이유
기기에서 권한 있는 Linux 데몬을 시작하는 것은 빠진 조각처럼 보이며, 실제로 터널을 올리기도 합니다. 하지만 그 터널을 Android에 등록하지는 않습니다. 인터페이스는 커널 안에 존재하지만, 플랫폼의 VPN 선택, 앱별 라우팅, always-on 정책, 수명 주기는 그것을 알지 못하며, 데몬 자체의 경로와 DNS 변경은 같은 테이블을 두고 네트워크 관리자와 경쟁합니다.
결과는 데몬의 트래픽에는 작동하고 당신이 중요하게 여긴 앱에는 신비롭게 작동하지 않는 연결, 또는 시스템이 네트워크를 재평가할 때까지 살아남는 연결입니다. 어느 쪽도 플랫폼 버그가 아닙니다. 소켓을 소유하는 것과 VPN 기능을 소유하는 것 사이의 경계입니다.
지원되는 경로의 모습
조직이 Android가 직접 프로비저닝하는 프로필로 이동할 수 있다면 플랫폼 경로가 정직합니다. API 30부터 VpnManager 는 앱이 플랫폼 VPN 프로필을 프로비저닝하고 제어하는 것을 지원하며, 호출 앱에 연결된 권한 부여 흐름이 있습니다. 이것은 L2TP 변환기가 아닙니다. IKEv2용으로 프로비저닝하는 프로필 모델은 기존 L2TP 구성을 변환하지 않으며, 프로토콜 전환은 이름 변경이 아니라 마이그레이션입니다. ID, 경로, 프라이빗 DNS, 액세스 권한은 의도적으로 옮겨야 합니다.
서비스가 L2TP/IPsec으로 남아야 한다면, 지원되는 조합은 운영자가 실제로 문서화한 클라이언트와 OS 릴리스, 그리고 있다면 그 자동화 계약입니다. 문서화된 무인 제어가 없을 때 올바른 답은 지원되는 수동 연결이지, 한 빌드에서 우연히 작동하는 취약한 권한 스크립트가 아닙니다.
올바른 자동화가 하는 일
문서화된 제어가 있으면 자동화의 일은 작고 방어 가능합니다. 지정된 연결을 요청하고, 준비를 기다리고, 인증이나 설정 실패 시 멈추고, 의도한 작업을 실행하고, 정리는 연결을 소유한 구성 요소에 맡깁니다. 자격 증명은 저장과 순환을 아는 클라이언트에 남습니다.
첫 줄을 쓰기 전에 어느 구성 요소가 어느 계층을 소유하는지 적고, 결과를 그것과 대조해 확인하십시오.
- IPsec과 PPP는 클라이언트가 처리하며 스크립트의 경로가 아닙니다.
- 연결은 플랫폼의 VPN 상태에 나타나므로 앱별 범위와 always-on이 적용됩니다.
- 어떤 내부 서비스 호출, 트랜잭션 번호, 추측한 인수도 자격 증명을 운반하지 않습니다.
- 어느 단계에서 실패해도 반쯤 등록된 프로필이 남지 않습니다.