한 호스트에서 충돌 없이 VPN과 웹사이트 운영하기

공용 사이트와 VPN 사이에 호스트 하나를 공유하면 무엇이 어디에서 수신하는지, 그리고 누가 누구를 인증하는지라는 물음 둘을 물려받습니다. 구성 파일을 만지기 전에 둘 다 답하십시오, 기본값은 부하가 걸려야 드러나는 방식으로 틀려 있기 때문입니다. HTTPS로 열리는 페이지는 웹 리스너가 응답한다는 것만 증명하고 피어 리스너에 대해서는 아무것도 말하지 않습니다. 이어지는 내용은 둘이 서로를 잡아먹지 않게 하는 결정 순서입니다.

어느 주소와 전송 계층에서 무엇이 수신하는지 결정하기

주소, 전송 계층, 포트 세 열에 관리 인터페이스를 포함한 서비스별 행을 더한 표를 쓰십시오. 사이트의 TCP 443과 VPN의 UDP 443은 숫자가 같아도 전송 계층이 다르므로 충돌이 아닙니다. 같은 주소와 전송 계층, 포트에서 두 서비스를 돌리려면 구현이 문서화한 배열이 필요하며, 장애 중에 즉석에서 만들어내는 것이 아닙니다. 그 표는 다음 변경을 검토 가능하게 만드는 산출물이기도 합니다.

주소를 나누거나 두 번째 포트 사용하기 패킷 캡처에서 소유 관계가 드러나며 이는 우아함보다 값집니다. 일부 VPN 구현은 웹 서버와 포트를 공유하는 것을 지원하지만, 데몬이 첫 바이트를 검사해 자기 프로토콜이 아닌 트래픽을 넘기는 방식으로 한정됩니다. 일반 HTTP 리버스 프록시는 그렇게 하지 않으며 헤더를 다시 써도 암호화된 터널의 핸드셰이크를 이해시키지 못합니다. 프로토콜의 배포 문서, 예를 들어 OpenVPN 리스너 문서를 읽고 거기서 설명하는 배열을 따르십시오.

어느 아이덴티티가 어느 서비스에 속하는지 결정하기

브라우저 인증서와 VPN 피어 자격 증명은 신뢰 모델이 다른 별개의 객체입니다. 웹 인증서는 공인 기관이 검증하고 호스트 이름을 표시하는 반면, 피어 자격 증명은 장치나 사용자를 집중기 쪽으로 인증하며 자체 서명되거나 내부에서 발급될 수 있습니다. 하나를 다른 하나로 재사용하는 것은 좁은 경우에만 통하고 그 결합에 값할 때가 거의 없습니다. 공유 인증서를 맞추려고 검증을 끄는 것은 분리 계획이 아니며, 자격 증명에 의미를 주던 검사를 없앨 뿐입니다.

두 저장소를 독립적으로 유지하고 어느 기관이 각각을 발급하는지 적어 두십시오. 하나를 교체할 때 다른 하나는 바뀌지 않아야 하며, 바뀐다면 그 결합이 고칠 대상입니다.

관리를 어디에 둘지 결정하기

VPN의 관리 인터페이스는 관리 경로에 속하며, 호스트가 이미 인터넷을 제공하더라도 공용 리스너에 두어서는 안 됩니다. 443의 웹 서버는 피어 콘솔이 어디서나 접근 가능해야 한다는 뜻이 아니며, 콘솔은 보통 더 값어치 있는 표적입니다. 루프백이나 관리 주소에 묶고 출발지로 제한하며, 터널이 올라와 있다는 데 의존하지 않는 복구 경로를 유지하십시오. 복구 경로가 중요한 이유는 흔한 실패가 잠금을 고치다가 스스로 잠기는 것이기 때문입니다.

리스너마다 좁은 방화벽 규칙을 쓰고, 플랫폼이 지원하는 곳에서는 인터페이스나 서비스 계정을 명시하십시오. 사이트에 443이 필요하다는 이유로 호스트를 여는 넓은 규칙이 관리 인터페이스를 스캐너 색인에 올리는 경로입니다.

서비스가 추가될 때마다 그 규칙을 리스너 표와 대조해 검토하십시오. 검토는 값싸고, 새벽 두 시에 누군가 더한 규칙을 잡아냅니다.

둘이 경쟁할 때 무엇을 할지 결정하기

호스트를 공유한다는 것은 CPU, 메모리, 파일 디스크립터, 대역폭을 공유한다는 뜻이며, 다투는 자원이 늘 뻔한 것은 아닙니다. 바쁜 사이트는 연결 표를 채우고, 워커 슬롯을 고갈시키며, 디스크 큐를 밀어붙여 VPN 기록이 멈추게 할 수 있습니다. 평균은 어느 프로세스가 굶고 있는지 감추므로 호스트 총계 대신 서비스별 사용량을 보십시오. 한 작업 부하가 다른 쪽을 반복해서 방해하면 증상 주위를 조정하는 대신 둘을 분리하십시오.

격리는 컨테이너, cgroup 제한, 별도 큐, 또는 두 번째 호스트일 수 있으며 올바른 선택은 어느 자원이 다투는지에 달려 있습니다. 포트 변경은 여기서 아무것도 고치지 못하고, 제한이 포화된 큐 하나라면 더 큰 인스턴스도 아무것도 고치지 못합니다. 측정으로 결정하되, 자원을 지목하고 부하를 걸어 본 뒤 경쟁을 없애는 가장 작은 격리를 고르십시오.

바깥에서 검증하고, 재시작 뒤에 다시 검증하기

호스트 자체의 네트워크에 있지 않은 기기에서 사이트를 열고 터널을 올린 뒤 그것을 요구하는 자원 하나에 도달하십시오. 그다음 각 서비스를 따로 재시작해 다른 시험을 반복하되, 재시작은 공유 리스너 배열이 순서를 잃는 순간이기 때문입니다. VPN이 공유 포트를 소유한 웹 서버보다 먼저 시작하면 공유 메커니즘이 아예 붙지 않을 수 있고, 증상은 어제까지 돌던 터널입니다. 의존성을 유닛 순서에 명시하십시오.

그다음 사이트는 자기 포트에서, VPN은 자기 포트에서, 관리 인터페이스는 관리 경로에서만 응답하는지 경계를 확인하십시오. 결과를 날짜와 함께 리스너 표 옆에 기록하십시오. 재시작 뒤 세 가지 검사를 모두 통과하는 호스트는 브리핑 없이 다른 사람에게 넘길 수 있는 호스트입니다.