상용 VPN이 포트 5432를 차단할까? 선택지 비교

그 애플리케이션은 매일 사무실에서 데이터베이스와 통신했다. 그런데 누군가 같은 노트북에서 상용 VPN 클라이언트를 켜자 핸드셰이크 후 연결이 재설정되기 시작했다. 애플리케이션은 아무것도 바뀌지 않았고, 터널은 정상이라고 보고하며, 당신이 관리하는 방화벽에는 차단 규칙이 없다. 바뀐 것은 출구 경로다. 제공업체 서버는 공유된 고트래픽 종단점이고, 제공업체는 남용을 줄이려고 아웃바운드 포트를 필터링한다. 데이터베이스와 메일 제출 포트가 그 대부분을 차지하는데, 익명 주소 풀에서 스캔과 스팸을 끌어들이는 포트가 바로 이것들이기 때문이다.

필터링을 나머지 모든 것과 구분하는 오 분 테스트

같은 머신에서 열려 있어야 하는 포트와 실패하는 포트를 같은 호스트에 대해 터널을 켠 상태와 끈 상태로 각각 확인한다. 두 번 모두 같은 명령을 사용해 유일한 변수가 터널이 되게 한다.

Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432

네 가지 결과로 거의 모든 경우를 설명할 수 있다. 443은 되고 5432가 터널을 켰을 때만 실패하면 출구 경로의 포트 필터링이다. 터널을 켜면 둘 다 실패하고 끄면 둘 다 되면 문제는 포트 정책이 아니라 라우팅이나 DNS다. 두 포트가 모두 연결되는데 애플리케이션이 여전히 실패하면 도달성이 아니라 인증이나 TLS 문제다. 그리고 제공업체의 서버 위치 하나만 실패하면 서버별 정책이므로, 설정을 건드리기 전에 다른 위치를 시도한다.

선택지 하나: 데이터베이스 서브넷을 분할 터널로

노트북이 상용 VPN을 다른 용도로만 필요로 한다면 데이터베이스 주소 범위를 터널에서 제외해 트래픽이 공유 출구로 전혀 들어가지 않게 한다. 두 경로가 정말로 만날 필요가 없을 때 가장 깔끔한 선택이며, 문서화할 수 있는 라우팅 규칙 외에는 비용이 들지 않는다. 대가는 분할 터널링이 두 번째 정책 표면을 도입한다는 점이다. 터널에서 제외하는 것은 의도적이어야 하며, 나중에 누군가 추가한 서브넷의 부작용이어서는 안 된다.

데이터베이스가 VPN이 도달해야 할 네트워크 안에 있는 순간 작동하지 않으므로, 이 선택을 확정하기 전에 확인해야 한다.

선택지 둘: 직접 만든 종단점, 직접 만든 출구

VPS에서 작은 VPN 종단점을 운영하면 출구 정책을 직접 통제할 수 있고 공유 풀은 관여하지 않는다. 상용 클라이언트와 정직하게 비교할 가치가 있는 선택지다. 예측 가능한 소스 주소를 얻는 대신 제공업체의 전 세계 거점과 편리함을 잃는다. 데이터베이스와 메일 포트가 하루 종일 필요한 팀이라면 보통 이 거래는 종단점 소유 쪽으로 기운다. 실패 방식이 다른 사람의 남용 정책이 아니라 자신의 설정 실수가 되기 때문이다.

소스 주소의 안정성, 누가 당신의 트래픽을 읽을 수 있는지, 종단점 제공업체가 자체 필터링을 바꾸는 날 무슨 일이 일어나는지 이 세 가지로 둘을 비교한다.

선택지 셋: 노트북을 경로에서 빼기

CI 작업, 예약된 컨테이너, 허용된 네트워크 안의 배스천 호스트는 사람의 터널 상태에 의존하지 않는다. 이미 허용된 호스트에서 SSH 터널로 데이터베이스에 도달하면 노트북이 포트와 직접 통신할 일이 없다. 여러 사람이 같은 제약에 부딪힐 때 확장되는 선택지이며, 문제를 우회하는 대신 없애는 선택지이기도 하다.

분할 터널 규칙보다 사전 작업이 더 들고, 지금 당장 대화형 세션이 필요한 한 사람에게는 도움이 되지 않는다.

제공업체 주소를 허용 목록에 넣는 것이 왜 잘못된 비교인가

제공업체의 출구 주소를 데이터베이스 허용 목록에 추가하면 실제로 작동하지만, 그 순간 그 주소를 공유하는 다른 모든 가입자에게도 접근 권한을 준다. 좁게 부여된 애플리케이션 계정 뒤의 읽기 전용 복제본이라면 하루 정도의 노출은 감수할 수 있을지 모른다. 쓰기가 가능한 무엇이든 그것은 이름 붙일 가치도 없는 거래이며, 출구 주소가 순환하면 더 나빠진다. 서버가 바뀔 때마다 규칙이 깨지고, 유지보수는 허용 목록의 목적을 무력화하는 광범위한 CIDR 항목을 부른다.

전용 또는 고정 주소는 제공업체가 판매하는 곳에서만 이 문제가 확장되는 유일한 형태다. 허용 목록을 오직 당신만의 주소에 연결하거나, 아예 연결하지 말아야 한다.

무엇을 선택하든 경로와 이유를 적어 두어야 한다. 다음 사람은 같은 재설정 연결을 만나고 애플리케이션을 탓하기 시작할 것이다.