☰

CentOS 7 VPN 서버

tag-icon • tag-icon centos vpn openvpn openssl openssh
CentOS 7 VPN 서버

VPN에 의해 ​​완전히 차단되도록 CentOS 7을 사용하여 원격 인터넷 웹 서버를 설정하는 방법은 무엇입니까? 사용 사례는 다음과 같습니다.

1.) This means that ALL requests for ANY interaction with the web server  
    would have to come through the VPN from a known user. Including  
    http/https requests.  
2.) Each server might have only 20 users who would connect to the server  
    over the internet to work with highly sensitive data that needs  
    tight security.  
3.) The users would not actually log into the OS.  
4.) Instead, the users would simply make http/https requests from pre-registered  
    devices that also contain a unique key identifying the user.  
5.) There would be one administrator who logs into the OS remotely,  
    but all other users would just have secure http/https access.  
6.) If any request came from a non-known device outside the vpn,  
    the request would be bounced off as if the server was not there.   
7.) But the server is connected to the internet and all VPN connections  
    come through the internet.

OpenSSH이것이 VPN의 최신 버전이라는 것을 읽었습니다 . 1024비트 암호화 키를 사용할 수 있다는 점은 마음에 들지만 OpenSSH를 사용하여 OS에 원격으로 로그인할 수만 있고 http/https 요청을 포함하여 시스템에 대한 모든 경로를 잠글 수는 없다는 인상을 받았습니다. . OpenSSH위에서 설명한 대로 전체 서버를 잠글 수 있습니까 ?

나는 그것에 대해 읽기 시작했습니다 . 라이센스 비용이 OpenVPN있다는 것을 알았습니다 . OpenVPN라이센스 비용은 문제가 되지 않지만 유료 옵션을 시도하기 전에 무료 옵션이 있는지 알고 싶습니다. 또한 OpenVPN위에서 설명한 내용을 수행할 수 있는지 확인하고 싶습니다 .

내가 읽은 내용 pptp에 따르면 pptp128비트 암호화 키만 지원되며 위의 모든 작업을 수행하는 것이 불가능할 수도 있습니다.

답변1

내가 아는 한, 모든 기능을 고정하는 맞춤형/상업용 제품 없이는 원하는 모든 기능을 달성할 수 없습니다.

필수 표준을 충족하는 방법을 자세히 설명할 때 염두에 두어야 할 몇 가지 아이디어는 다음과 같습니다.

일반적인 VPN 솔루션에는 라우팅이 추가됩니다. 경로를 추가하려면 사용자에게 클라이언트 컴퓨터에 대한 관리 권한이 필요합니다. 특히 고용주가 제공한 하드웨어를 사용할 때 항상 그런 것은 아닙니다. 구현에 따라 기존 VPN 솔루션에는 이 주제에 대한 해결 방법이 있습니다. 내가 아는 한 OpenVPN은 클라이언트가 설치될 때 Windows 서비스를 등록하여 사용자가 실제로 운영 중인 클라이언트의 요청을 기반으로 경로를 추가합니다. Tunnelblick(OpenVPN의 OS X 클라이언트)도 일부 마법을 사용하여 라우팅을 작동시키고 일부 지점에서는 관리 권한이 필요합니다. 따라서 OpenVPN은 이 문제를 해결하기 위해 클라이언트를 구성하는 데 최소한의 노력을 기울여야 합니다.

적어도 OpenVPN은 "연결되면" 경로를 추가할 수 있으므로 사용자는 실제로 경로를 직접 추가할 수 있습니다. OpenVPN 서버가 OpenVPN을 통해 연결할 수 있는 일부 호스트에 경로를 푸시한다고 가정합니다. 이로 인해 클라이언트는 이러한 호스트에 경로를 추가하게 됩니다. 사용자가 다른 호스트에 더 많은 경로를 추가하는 것을 금지하는 메커니즘은 없습니다. 따라서 이러한 경로가 실제로 유효하면 승인되지 않은 백엔드에 액세스할 수 있습니다. 이를 방지하려면 서버의 방화벽을 강화하고 허용된 호스트의 트래픽 외에는 아무것도 허용하지 않아야 합니다.

제공하려는 인프라를 호텔에서 서버에 자주 액세스하는 직원이 사용할 수 있어야 하는 경우 VPN이 전혀 작동하지 않을 수 있습니다. VPN 연결에 필요한 트래픽을 전달하지 않는 호텔이 꽤 있습니다. 어떤 경우에는 포트 80과 443만 허용됩니다.

OpenVPN에 대한 내 생각에서 벗어나려면 "신뢰할 수 있는" 장치에서만 연결을 허용하라는 요구 사항은 내가 아는 한 불가능합니다. 이는 방화벽(보통 CentOS에서는 iptables)을 통해 수행됩니다. 원하는 규칙은 DROP신뢰할 수 없는 장치에서 오는 패킷에 대한 것입니다. 안타깝게도 iptables는 이제 해당 정보가 패킷의 일부가 아니기 때문에 장치를 신뢰할 수 있는지 확인할 수 있습니다. 비슷한 방식으로 필터링하는 솔루션이 있지만 적어도 호환 가능한 네트워크에서는 가능합니다(이 주제에 관심이 있다면 Google에 General Dynamics의 PitBull Foundation을 문의하세요).

이제 몇 가지 필수 표준이 부족하더라도 실제로 시나리오를 구현하는 방법에 대해 생각해 보세요.

우선, OpenSSH는 VPN 솔루션이 아닙니다. VPN과 유사한 터널을 구축할 수 있지만, 제가 아는 한 다른 VPN 솔루션은 성능과 기능 측면에서 OpenSSH 접근 방식을 능가합니다.

그런데 사용자는 일반적으로 http/https 서비스만 사용한다고 말씀하셨습니다. VPN과 같은 기능 없이도 SSH 터널을 통해 쉽게 액세스할 수 있습니다. 구성 방법에 대해 자세히 설명하지는 않지만 OpenSSH 사용에 대한 일반적인 접근 방식을 지적하겠습니다.

가장 먼저 이해할 수 있는 일은 포트 80 또는 443을 사용하도록 SSH 데몬을 구성하는 것입니다. 이를 통해 사용자는 호텔을 비롯한 거의 모든 곳에서 서버에 연결할 수 있습니다.

보안과 관련하여 sshd 구성을 사용하면 사용자, 호스트 등과 일치하는 규칙을 추가할 수 있습니다. 이는 실제로 방화벽에서 필터링하지 않고도 OpenSSH 서버 뒤의 특정 호스트로 사용자 트래픽을 제한할 수 있음을 의미합니다. 이러한 규칙은 다음과 같습니다.

Match User JohnDoe
    AllowTcpForwarding yes
    PermitOpen internal.resource:80 other.internal:443

보안인증은 필수입니다. OpenSSH는 PAM 모듈을 활용하여 사용자를 인증할 수 있습니다. LDAP, Radius 등에 대한 인증과 같은 다양한 가능성이 있습니다. 2단계 인증을 간단한 방법으로 사용하는 깔끔한 솔루션은 PAM 모듈도 포함된 Google Authenticator를 사용하는 것입니다. 여러 리소스에 Google Authenticator를 사용하도록 OpenSSH를 구성하는 방법이 나와 있습니다.

실제로 이 솔루션을 사용할 때 가장 어려운 부분은 클라이언트 측에서 일어나는 일입니다. 클라이언트에는 터널링을 지원하는 SSH 클라이언트가 필요합니다. 가장 중요한 것은 클라이언트가 클라이언트를 사용하는 방법과 설정된 터널에 연결하는 방법을 알아야 한다는 것입니다. 셸에서 수동으로 터널을 열었지만 일반 사용자는 교육 없이는 이러한 작업을 수행하지 못할 수도 있습니다. 언뜻 보면 이 클라이언트가 유용할 수 있습니다.자동(자동) SSH 터널 관리자

제가 제안한 솔루션을 귀하의 요구 사항 목록과 일치시키려면 다음을 수행하십시오.

  1. 모든 요청은 SSH 터널을 통과합니다. SSH 서버의 한 포트는 인터넷에서 액세스할 수 있어야 합니다. 확인하다.
  2. 이 20명의 사용자를 생성하고 허용하면 다른 누구도 연결할 수 없습니다. 확인하다.
  3. 올바르게 구성되면 사용자는 쉘을 얻을 수 없습니다. 터널을 설정하는 데 쉘이 필요하지 않습니다. 확인하다.
  4. 2단계 인증을 사용하는 것이 좋지만 각 장치에 키가 있는 공개 키 인증을 수행할 수도 있습니다. 그러나 이러한 키는 다른 장치로 전송될 수 있습니다. 따라서 추가 조사 없이 확인이 필요하지 않지만 트래픽이 http/https로 제한될 수 있습니다.
  5. 연결할 때 셸을 가져오도록 루트 또는 지정된 사용자를 구성할 수 있습니다. 확인하다.
  6. 불가능한.
  7. 내 솔루션에서는 "VPN"이 아니지만 예, 액세스는 그런 식으로 진행됩니다. 확인하다.

관련 정보