서버인가 클라이언트인가: 이중 역할 Pi에서 어떤 OpenVPN 유닛인가

OpenVPN 프로세스 두 개가 로밍 사용자를 받아들이면서 상위 공급자에도 도달하는 Pi에서 실행되며, 하드웨어 말고는 거의 아무것도 공유하지 않습니다. 하나는 들어오는 터널을 기다리고, 다른 하나는 바깥으로 연결합니다. 각자는 자기 디렉터리를 읽고, 각자 고유의 실패 방식을 가집니다. 잘못된 쪽을 다시 시작하는 것이 클라이언트 수정이 오히려 리스너를 흔들어 버리는 가장 흔한 경로입니다.

유닛 이름을 그 유닛이 불러오는 디렉터리와 맞추십시오

Upstream 2.6은 두 개의 템플릿 유닛, [email protected]와 [email protected]를 제공합니다. 서버 템플릿은 /etc/openvpn/server에서 시작해 거기서 %i.conf을 불러옵니다. 클라이언트 템플릿은 /etc/openvpn/client에서 시작합니다. roaming이라는 인스턴스는 서버로서도 클라이언트로서도 두 곳에 동시에 존재할 수 있으며, 서로 무관한 두 설정을 가지고 문자열 말고는 둘을 잇는 것이 없습니다.

파일 시스템이 아니라 systemd에 물으십시오. 패키지 제작자가 작업 디렉터리나 바이너리가 받는 인자를 바꿀 수 있는 추가 파일을 넣기 때문입니다.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

첫 명령은 실패했지만 로드된 채 남은 것까지 포함해 생성된 모든 유닛을 나열합니다. 둘째는 유닛 파일을 어떤 재정의와 함께 출력합니다. 셋째는 이 질문을 결정하는 두 사실, 즉 프로세스가 시작되는 디렉터리와 넘겨받은 설정 경로를 가장 빠르게 보는 방법입니다.

패킷 방향으로 판단하고 인터페이스 이름으로 판단하지 마십시오

서버 인스턴스는 대기 소켓을 소유하고 연결을 받아들입니다. 그 암호화 전송은 Pi에서 로컬 입력과 로컬 출력이지만, 사용자를 위해 전달하는 트래픽은 전달 경로를 따르고 다른 규칙 집합을 따릅니다. 클라이언트 인스턴스는 그런 의미의 리스너가 없습니다. 상대에게 연결하므로 암호화 전송은 하위 계층을 향한 로컬 출력입니다.

그 차이가 규칙이 어디에 속하는지 알려 줍니다. 전달 체인 안의 인터페이스와 일치하는 규칙은 라우팅이 이미 선택한 트래픽만 허용하며, 결코 경로를 선택하지 않습니다. 로밍 사용자의 패킷이 잘못된 길로 나갈 때 점검할 체인은 forward이고 output이 아닙니다.

이론을 세우기 전에 소켓을 보십시오. udp/1194에 묶인 서버는 대기 소켓을 보여 줍니다. 클라이언트는 공급자 주소와의 연결을 보여 주고 기다리는 것은 아무것도 없습니다.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

한 인스턴스의 기본 경로가 다른 쪽의 응답을 가로챌 수 있습니다

상위 클라이언트가 밀어 넣는 redirect-gateway는 머신의 다른 모든 것과 경쟁하는 기본 경로를 설치하며, 서버가 로밍 사용자에게 보내는 응답도 포함됩니다. OpenVPN은 터널이 도달 가능하게 남도록 자기 상대 주소에 예외를 두지만, 그 예외는 호텔 네트워크에 있는 휴대전화에 대해서는 아무것도 말하지 않습니다.

증상은 대개 비대칭입니다. 핸드셰이크가 끝나고 클라이언트가 연결되었다고 보고하며, 첫 응답 패킷 뒤에 트래픽이 죽습니다. 출발지 기반 정책 라우팅, 또는 서버 인스턴스에 --mark로 설정한 패킷 마크가 두 흐름을 분리합니다. 어느 것도 단독으로 완전한 규칙 집합이 아니며, 둘 다 선택한 테이블에 유효한 경로가 필요합니다.

터널 상태가 아니라 로컬 결정을 시험하십시오. 커널이 OpenVPN이 패킷을 보기 전에 출발지와 인터페이스를 고르기 때문입니다.

ip route get 203.0.113.44
ip rule show

한 역할을 다시 시작하고 다른 역할이 살아남았음을 증명하십시오

두 역할이 같은 하위 계층에 의존할 때는 순서가 중요합니다. 사용자 트래픽을 전달하려면 상위 경로가 먼저 있어야 한다면 클라이언트를 먼저 다시 시작하고, 리스너나 풀만 바꾼다면 서버를 먼저 다시 시작하십시오. 어느 경우든 나중에 두 유닛을 모두 확인하십시오. 실패한 재시작이 다른 역할을 낡은 상태로 계속 실행하게 둘 수 있기 때문입니다.

변경 전에 정지 조건을 적어 두십시오. 상위 터널을 잃으면 로밍 사용자가 막히는가, 아니면 Pi 자체의 상향 링크로 되돌아가는가. DNS와 IPv6에도 명확한 답이 필요합니다. 밀어 넣은 리졸버는 그것을 쓸모 있게 만든 경로보다 오래 사는 경우가 많기 때문입니다.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

세 가지가 동시에 성립할 때만 변경을 받아들이십시오. 새로 들어오는 연결이 완료되고, 전달된 애플리케이션이 의도한 출구로 목적지에 도달하고, 두 프로세스가 여전히 기대한 상대를 보고해야 합니다. 셋 중 하나가 실패하면 잘못된 인스턴스나 잘못된 경로를 바꾼 것이며, 다음 단계는 다른 무엇을 다시 시작하는 것이 아니라 유닛을 다시 읽는 것입니다.