Android OpenVPN: 휴대전화를 루팅하지 않고 개인 경로 추가하기

프로필에 아직 없는 개인 서브넷이 하나 더 필요합니다. 예를 들어 10.60.0.0/24입니다. 노트북이라면 경로를 추가하고 넘어가면 됩니다. Android에서는 VPN이 앱이고 tun 장치도 그 앱의 것이며, root 없이 편집할 라우팅 테이블이 없습니다. 경로는 여전히 존재해야 하지만, 클라이언트가 불러오는 프로필 안으로 들어가며 상대편이 동의할 때만 동작합니다. 여기 편집, 재연결, 서버 쪽, 되돌리기가 있습니다.

편집 전에: 경로가 할 수 있는 일과 없는 일

경로는 한 가지 질문에 답합니다. 이 목적지로 가는 트래픽을 어느 인터페이스가 실어 나를지입니다. 경로는 아무것도 허가하지 않습니다. 네트워크 소유자가 이 휴대전화가 그 서브넷에 닿는 것을 허용하지 않았다면, 올바른 경로는 올바르게 보이는 설정과 게이트웨이에서의 조용한 폐기를 만들고, 다음 한 시간은 잘못된 파일을 편집하며 보내게 됩니다.

먼저 그 동의를 받으세요. 네트워크에 소유자가 있다면 문서로 받으세요. 그다음 무엇을 하지 않는지 적어 두세요. 휴대전화에 그 LAN 안의 주소를 주는 것도, 서버의 리스너를 바꾸는 것도, 호스트 이름으로 사이트를 고르는 것도 아닙니다. 이는 서로 다른 네 가지 변경이며 첫 번째만 당신의 몫입니다.

클라이언트가 실제로 불러오는 프로필을 편집하세요

일반 OpenVPN 옵션 텍스트를 가져오는 호환 클라이언트라면 추가는 한 줄입니다.

route 10.60.0.0 255.255.255.0

프로필 본문의 다른 라우팅 지시자 근처에 넣고, 운영자의 endpoint, 인증서, 키 처리, 검증 줄은 원래대로 두세요. 한 줄을 빌리려고 오래된 예시를 통째로 붙여 넣지 마세요. 압축, 절대 파일 경로, 폐기된 cipher 설정이 함께 따라와 별도의 디버깅 시간을 잡아먹습니다.

사람들이 놓치는 단계는 파일 소유권입니다. 앱이 프로필을 가져왔다면 앱이 쓰는 사본은 앱의 것이고, 내려받은 원본을 편집해도 아무것도 바뀌지 않습니다. 클라이언트가 지원하는 편집기를 쓰거나 업데이트 경로로 편집한 파일을 다시 가져오고, 비슷한 이름이 여러 개면 활성 프로필 이름을 확인하세요. 어느 것을 바꿨는지 기록하세요.

프로필에 이미 route-nopull이 있으면 서버에서 오는 경로는 하나도 설치되지 않으며, 휴대전화에 필요한 모든 프리픽스를 명시해야 합니다. 정당한 설계이지만, 빠뜨린 한 줄이 서버의 거부와 똑같이 보인다는 뜻입니다.

다시 연결하고 기기에서 확인하세요

먼저 연결을 끊고, 앱이 마지막 세션을 복원하게 두지 말고 편집한 그 프로필로 다시 연결하세요. 연결 로그를 열어 클라이언트가 새 줄을 해석했는지 확인하세요. 화면이 무시하는 경로 지시자는 잘못된 사본을 편집했을 때 흔한 결과입니다.

목적지는 이름이 아니라 주소로 시험하세요. 알려진 서비스 포트로의 TCP 점검이 ping보다 정보가 많습니다. 많은 호스트가 ICMP에는 응답하지만 서비스 포트는 필터링되기 때문입니다. 주소는 응답하는데 이름이 응답하지 않으면 라우팅이 아니라 리졸버 문제이며, 다음 절은 당신을 위한 것이 아닙니다.

여기에는 두 가지 범위 점검도 들어갑니다. 앱별 VPN은 시험에 쓰는 앱이 포함 집합 밖에 있어도 주소 경로가 존재할 수 있다는 뜻이므로, 실제로 안에 있는 앱으로 시험하세요. 그리고 IPv4 프리픽스는 IPv6 경로에 대해 아무것도 말하지 않습니다. 서비스가 dual-stack이라면 해당 IPv6 경로를 추가하거나, 클라이언트가 의도하지 않은 경로를 선호할 것을 예상하세요.

부정적인 결과 하나는 일찍 알아두는 편이 좋습니다. full-tunnel 경로가 이미 0.0.0.0/0을 덮고 있다면 프리픽스가 빠진 것이 아니며 다시 추가해도 아무것도 바뀌지 않습니다. 중복된 커버리지는 서버 쪽 거부나 빠진 응답을 고치지 않습니다.

서버에서 경로를 마무리하세요

휴대전화 밖에서 세 가지가 참이어야 합니다. 게이트웨이에는 목적지로 가는 경로와 휴대전화의 출발지를 그쪽으로 전달할 권한이 필요합니다. 목적지는 그 출발지를 받아들이고 응답을 게이트웨이로 돌려보내야 하며, 그렇지 않으면 설계에 출구에서의 의도적 변환이 필요합니다. OpenVPN 설명서의 route 옵션은 클라이언트 쪽 지시를 다루며, 전달과 반환 라우팅은 다른 기계의 별도 설정입니다.

목적지가 게이트웨이 바로 뒤가 아니라 다른 VPN 클라이언트 뒤에 있다면, 서버에는 그 피어의 서브넷에 대한 iroute가 필요합니다. 그 지시는 서버 소유이며 어느 클라이언트가 프리픽스를 갖는지 설명합니다. 휴대전화는 자기 프로필에서 그것을 제공할 수 없고, 클라이언트 쪽 편집을 아무리 해도 대신할 수 없습니다.

반환 경로를 명시적으로 확인하세요. 터널이 아니라 기본 경로로 나가는 응답은 전형적인 반쯤 열린 증상을 만듭니다. 연결은 한 방향으로 성립하고 아무것도 돌아오지 않습니다. 목적지가 되돌아 라우팅할 수 없을 때 게이트웨이에서의 출발지 변환은 정당한 수정이지만, 나름의 결과를 지닌 정책 결정입니다.

되돌리기와 수용

편집하기 전에 이전 프로필을 보관하세요. 변경으로 상황이 나빠지면 같은 재가져오기 경로로 그 사본을 되돌리고, 다시 연결하고, 예전 동작이 돌아오는지 확인하세요. 그래야 바꿨다고 생각한 것을 실제로 바꿨음이 확인됩니다. 예전 상태를 되돌리지 못하는 되돌리기는 앱이 당신이 찾지 못한 세 번째 사본을 쥐고 있다는 뜻입니다.

네 가지가 성립하면 변경을 받아들이세요. 새로 연결한 뒤 이 순서로 시험합니다. 목적지가 자기 서비스 포트에서 응답한다, 기대한다면 개인 이름이 해석된다, HTTPS가 여전히 의도한 호스트 이름을 검증한다, 재부팅이나 Wi-Fi에서 셀룰러로 바꾼 뒤에도 전부 동작한다. 마지막 점검이 Android가 터널을 다시 세울 때까지만 존재하는 경로를 잡아냅니다.

• 무엇이든 편집하기 전에 네트워크 소유자가 목적지를 허용하는지 확인한다.
• 클라이언트가 불러오는 프로필에 경로를 넣고, 다시 가져온 뒤 재연결한다.
• 올바른 주소 체계에 대해 앱별 범위 안에서 서비스 포트로 확인한다.
• 전달, 반환 라우팅, iroute는 서버에서 고친다. 휴대전화가 아니다.
• 되돌리기 사본을 남기고 재부팅 후 다시 시험한다.