어느 포럼 스레드에서 ifconfig-noexec는 터널이 올라올 때 SSH 세션을 살려 두는 해결책으로 제안됩니다. 그 논리는 이 옵션이 무엇을 건드리는지 확인하기 전까지는 그럴듯하게 들립니다. 이 옵션은 OpenVPN이 터널 인터페이스의 주소를 구성하지 못하게 하고 그 값을 대신 스크립트로 넘기지만, 관리 연결에 대한 응답이 어디로 가는지에 대해서는 아무 말도 하지 않습니다. 반대로 믿으면 쓸 수 있는 주소가 없는 터널과 그래도 죽는 SSH 세션이 남습니다.

이 옵션이 실제로 위임하는 것

기본적으로 클라이언트는 터널 장치를 올리고 서버가 준 로컬 및 원격 주소를 할당합니다. ifconfig-noexec이 설정되면 그 단계를 건너뛰고 협상된 값이 스크립트 환경으로 내보내져 다른 무언가가 그것을 적용할 수 있습니다.

소유가 옮겨갑니다. 그 자리에 무언가가 새로 만들어지지는 않습니다.

그래서 이 옵션이 답하는 질문은 누가 인터페이스를 구성하는가이고, 이 옵션이 답하지 않는 질문은 패킷이 어떻게 당신에게 되돌아오는가입니다. 이 둘을 분리해 두지 않으면 주소 없는 인터페이스를 메우려고 저녁 내내 경로를 편집하게 됩니다.

하는 일이 다른 비슷한 옵션 세 가지

이름이 한 단어만 다르고 증상이 겹치기 때문에 이 집안은 혼동하기 쉽습니다. 무엇을 고르기 전에 각각이 무엇을 억제하는지 읽어 보세요.

OptionWhat stops happening
ifconfig-noexecOpenVPN's own tunnel-address configuration; values go to scripts instead
route-noexecAutomatic route addition and removal; route details go to a script
route-nopullServer-pushed routes and related options such as DNS are rejected

이것들은 각각 따로 이해할 대안이지 함께 붙여 넣을 세트가 아닙니다. 주소 구성을 억제해도 경로 변경, 방화벽 규칙, DNS를 실어 보내는 푸시된 옵션은 억제되지 않습니다. 위임된 스크립트도 경로를 바꿀 자유가 있으며, 그것은 피하는 것이 아니라 당신이 넘겨주는 결정입니다.

벤더 클라이언트가 엔진을 감싼다면 프로필에 저수준 지시문을 넣고 래퍼가 그것을 존중하기를 바라는 대신 그 클라이언트가 지원하는 통합을 사용하세요. 래퍼는 연결할 때 프로필을 다시 생성하는 경우가 많아 수동 편집이 오류 없이 사라집니다. 파일에 저녁을 통째로 쏟기 전에 클라이언트가 설정을 어디에 두는지 확인하세요. 이것은 표의 모든 행에 해당하며, 당신이 찾아온 행만의 이야기가 아닙니다.

지키려던 SSH 세션

SSH 연결에는 출발지 주소, 목적지 주소, 응답 경로가 있습니다. 전체 터널 기본값을 막 설치한 서버에서는 공인 주소로 가는 응답이 터널과 일치해 버리고 VPN 게이트웨이가 그것을 버립니다.

터널 인터페이스의 주소 구성에서 무엇을 바꿔도 그것은 달라지지 않습니다.

이것을 고치는 것은 터널 이전 게이트웨이를 거쳐 관리 주소로 가는 더 구체적인 경로, 또는 그 트래픽을 돌리는 정책 규칙, 그리고 호스트가 적용하는 필터 설정입니다. 두 문제는 때때로 함께 나타나며, 그래서 하나가 다른 하나의 치료법으로 오해됩니다. 옵션 없이 터널을 올리고 인터페이스 주소와 응답 경로를 본 다음, 둘 중 어느 것이 실제로 고장 났는지 따로 시험하세요.

위임된 스크립트가 떠맡아야 할 것

정말로 다른 소유자가 인터페이스를 구성하게 하려면 로컬 및 원격 주소를 적용하고 장치를 올리고 해제 시 주소 지정을 복원하거나 제거하고 다시 연결한 뒤 같은 일을 또 하는, 그 작업을 나열하세요. 성공한 세션의 값을 하드코딩해서는 안 되는 것은 다음번에 서버가 다른 쌍을 줄 수 있기 때문입니다.

클라이언트가 내보내는 환경 변수가 그 작업에 대해 지원되는 유일한 입력입니다.

env | grep -E '^ifconfig_|^route_'

어떤 route-up 스크립트 안에서는 그 변수들을 쓸 수 있지만 cron 작업이나 수동 셸에서는 쓸 수 없습니다. 사용 중인 버전이 어느 수명 주기 훅을 쓰는지, 그 훅이 인터페이스를 바꿀 만큼 충분한 권한으로 실행되는지 확인하세요(클라이언트가 이미 비특권 사용자로 내려갔을 수 있습니다).

세션 하나가 아니라 전체 수명 주기를 시험하세요

터널을 올리고 장치의 주소를 확인한 다음 다시 연결해 또 확인하세요. 한 번은 되고 두 번째 시도에서 실패하는 구성은 보통 위임된 단계가 첫 연결에서만 실행된다는 뜻입니다.

그다음 의도한 관리 경로를 통한 새 SSH 연결이 되고 허용된 응용 프로그램이 터널을 올바르게 사용한다는 두 가지 승인 기준을 함께 시험하세요.

터널에 주소가 없는데도 옛 SSH 세션이 우연히 살아 있는 것은 성공이 아니며, 아무도 그 일을 떠맡지 않을 때 이 옵션이 만드는 것이 바로 그 상태입니다. 먼저 인터페이스 주소를, 다음으로 관리 응답 경로를, 마지막으로 응용 프로그램을 확인하세요. 셋 중 둘이 틀렸다면 이 옵션은 일을 옮겼을 뿐 주인을 주지 않은 것입니다.

관련 글