여러 OpenVPN 리모트: 장애 조치 목록이지 링크 본딩이 아니다
두 번째 리모트는 두 번째 시도이지 두 번째 차선이 아닙니다. 클라이언트가 endpoint 목록으로 무엇을 하는지, 진짜 집계에는 무엇이 필요한지 설명합니다.
한 프로필에 remote 줄이 두 개 있으면 두 번째 차선처럼 보이지만, 실제로는 두 번째 시도입니다. 첫 endpoint가 응답을 멈추면 클라이언트는 다음으로 넘어가고 세션은 넓어지지 않습니다. 목록을 처음부터 장애 조치라고 불러 두지 않으면 잘못된 손잡이를 돌리게 됩니다.
remote 목록이 주는 것
프로필을 용량 풀이 아니라 순서가 있는 시도 집합으로 보세요. 각 항목이 터널을 올릴 차례를 얻고, 세션은 응답한 항목 위에 남습니다. 목록이 길어지면 연결 확률이 올라갈 뿐, 파이프 폭이 넓어지는 것은 아닙니다.
진짜 집계는 다른 기계입니다. 하나의 흐름을 여러 경로로 나누려면 양쪽 끝에 트래픽을 나누고 순서대로 다시 조립하는 소프트웨어가 필요합니다.
더 많은 서버에서 더 빠른 터널을 약속하는 업체는 바로 그 두 번째 모델을 파는 것이지, 긴 목록을 파는 것이 아닙니다. 클라이언트가 endpoint를 차례로 시도할 뿐이라면, 다섯 항목이 바꾸는 것은 확률뿐이고 다른 것은 없습니다. 장애가 나면 세션은 끊겼다가 다른 곳에서 돌아오고, 로그에는 새 endpoint로 나타나며, 결코 더 넓은 파이프로 나타나지 않습니다.
설정을 하나의 endpoint에 묶어 두는 블록
보통의 remote 줄은 주소를 나르고, 때로 포트와 프로토콜도 나릅니다. endpoint에 프록시가 필요하거나 파일의 나머지가 쓰지 않는 전송이 필요하면, 그 설정을 연결 블록에 넣어 함께 두세요. 인라인 블록은 하나의 .ovpn 파일에서도 작동하며, 대부분의 프로필이 그렇게 배포됩니다.
블록 밖의 모든 것은 그것을 덮어쓰지 않는 항목의 기본값 역할을 합니다. 그래서 만들어진 블록 하나와 보통 remote 네 개가 주소 목록으로는 설명할 수 없는 방식으로 동작합니다.
알아보지 못하는 블록을 지우는 것은 겉모양 문제가 아닙니다. 그 블록이 속했던 endpoint는 파일의 기본값으로 돌아가고, 그 값은 그것이 듣는 전송과 다를 수 있습니다. 잘못된 포장을 제거하면 한 항목만 실패하고 나머지는 동작하므로, 깨진 프로필이 아니라 나쁜 서버처럼 보입니다. 편집 전에 각 remote를 전송, 포트, 프록시와 함께 읽으세요.
재시도 순서와 remote-random의 비용
죽은 항목마다 다음 시도 전에 시간을 쓰므로 순서가 중요합니다. 원하는 endpoint를 맨 앞에 두고 나머지는 순위가 매겨진 대체로 취급하세요.
remote-random은 시작 순서를 섞어 부하를 동등한 서버들에 분산시키지만, 한 endpoint가 분명히 주용일 때는 역효과가 납니다. 어느 쪽이든 클라이언트가 고른 endpoint를 기록하세요; 연결이 느리게 느껴질 때 프로필 이름은 아무것도 말해 주지 않습니다. 자세한 로그에서 링크 줄을 grep하면 세션이 어디에 내려앉았는지 보입니다.
운영자를 섞으면 신뢰 선언이 깨진다
프로필은 신원에 대한 선언이기도 하며, 이 주소들은 여러분이 닿으려던 서비스이고 고정한 인증서는 그것에 속합니다. 그 파일에 무료 공용 서버를 집어넣으면 선언이 깨집니다: 그들의 인증서와 여러분의 인증서는 서로 다른 서비스를 가리킵니다. 흔한 결과는 신원 검증 실패이거나, 제공자 네트워크 밖의 호스트에 자격 증명을 내주는 일입니다. 대안은 운영자가 배포하는 집합 안에 두고, 자격 증명과 신뢰 자료를 맞추세요.
두 제공자의 endpoint가 필요하다면 그것은 라우팅이지 프로필 편집이 아닙니다. 터널 위에서 해결하세요—어느 트래픽이 어느 경로를 타는지 거기서 정할 수 있습니다.
가정하지 말고 각 항목을 시험하라
승인된 프로필 업데이트 뒤에 필요한 각 endpoint에 일부러 연결해 어느 전송이 올라왔는지 확인하세요. 자세한 실행이 그것을 보이게 합니다. openvpn --config office.ovpn --verb 4를 시작하고 기대한 주소의 링크 줄을 읽으세요. 그다음 터널 뒤의 자원을 확인하세요; 항목이 핸드셰이크를 마쳐도 어디로도 라우팅하지 않을 수 있습니다.
장애 조치에는 희망이 아니라 자체 시험이 필요합니다. 실험실에서 첫 endpoint를 막고 클라이언트를 시작한 뒤 다음으로 넘어가는 데 걸리는 시간을 재세요. 느린 첫 항목 뒤의 긴 목록은 잘 시작하는 짧은 목록보다 나쁩니다.
운영자가 목록을 바꿀 때마다 다시 확인하세요. 가져온 집합은 그 항목이 존재하고 블록이 설명하는 전송을 말하는 동안에만 유용합니다. OpenVPN 2.6 설명서는 여기서 remote, connection, random-order 지시문을 다루며, 구문이 의심스러울 때 확인할 버전입니다.