터널 생성. SSH에 대한 자세한 설명과 터널 사용 예입니다. Secure Shell - 보안 데이터 전송
홈 서버에서 다음 인수와 함께 autossh를 실행하여 릴레이 서버를 향한 영구 SSH 터널을 만듭니다.
Homeserver~$ autossh -M 10900 -fN -o "PubkeyAuthentication=yes" -o "StrictHostKeyChecking=false" -o "PasswordAuthentication=no" -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 1.1.1.1:10022: 로컬호스트:22 [이메일 보호됨]
"-M 10900" 매개변수는 모니터링되고 SSH 세션을 모니터링할 때 테스트 데이터를 교환하는 데 사용되는 릴레이 서버 서버의 포트를 지정합니다. 이 포트는 릴레이 서버의 다른 프로그램에서 사용되어서는 안 됩니다.
"-fN" 옵션은 ssh 명령으로 리디렉션되어 SSH 터널이 백그라운드에서 실행될 수 있도록 합니다.
"-o XXXX" 옵션은 ssh 명령에 다음을 알려줍니다.
- 비밀번호 인증 대신 키 인증을 사용하세요.
- (알 수 없는) SSH 호스트 키를 자동으로 수락
- 60초마다 연결 유지 메시지를 교환합니다.
- 응답을 받지 않고 최대 3개의 연결 유지 메시지를 보냅니다.
나머지 SSH 역터널링 매개변수는 이전 예와 동일합니다.
시스템 부팅 시 SSH 터널이 자동으로 나타나도록 하려면 위의 autossh 명령을 /etc/rc.local에 추가하면 됩니다.
결론
이 문서에서는 역방향 SSH 터널을 사용하여 액세스하는 방법에 대해 설명했습니다. 리눅스 서버, 네트워크를 보호하는 방화벽 또는 NAT 게이트웨이 뒤에 있습니다. 외부 세계. 해당 사건에 대해 이를 수행하는 방법을 시연했습니다. 홈 네트워크공개 가상 비공개를 사용하여 VPS 서버. 회사 네트워크에서 이 기술을 사용할 때는 주의해야 합니다. 이러한 터널은 회사 방화벽을 우회하고 회사 네트워크를 외부 공격에 노출시킬 수 있으므로 회사 정책 위반으로 간주될 수 있습니다. 이 접근 방식은 잘못 사용되거나 의도적으로 나쁜 목적으로 사용될 가능성이 높습니다. 따라서 먼저 모든 설정에 대한 책임은 본인에게 있다는 점을 항상 기억하십시오.
때때로 SSH 네트워크 프로토콜을 사용하는 사람들은 리모콘서버를 운영하려면 VPN을 구성해야 합니다. SSH 터널을 열려면 이것이 필요합니다. 이 기사에서는 이것이 무엇인지, 다양한 방법으로 SSH 터널을 생성하는 방법 및 이에 사용할 수 있는 도구를 살펴보겠습니다.
SSH 터널링이란 무엇이며 왜 필요한가요?
사실 모든 것이 매우 간단합니다. 예를 들어 원격 서버와 로컬 컴퓨터가 있습니다. 어느 시점에서는 일부 데이터를 호스트에 업로드해야 하거나 그 반대로 일부 파일을 서버에서 컴퓨터로 다운로드해야 합니다. 왜냐하면 네트워크 프로토콜이는 일반 웹 인터페이스처럼 작동하지 않습니다. 정보를 다운로드하려면 SSH 터널을 만들어야 합니다. 이는 서버와 데이터를 교환할 수 있는 채널과 같으며 정방향 및 역방향 SSH 터널이 모두 있습니다.
SSH 터널을 만드는 데 도움이 됩니다. VPN 기술. 그 핵심은 VPN을 사용하면 기존 네트워크 위에 안전한 개인 네트워크를 만들 수 있다는 것입니다.
이것이 네트워크 프로토콜에 터널을 구현하는 방법입니다. 그러나 이를 위해서는 특별한 유틸리티가 필요합니다. 이 순간인터넷에는. 동종 최고 중 하나는 SSH Tunnel Easy입니다. 그녀의 리뷰부터 시작하겠습니다.
SSH 터널 용이성
안타깝게도 온라인에서 이 프로그램 설정에 대한 리뷰와 매뉴얼을 많이 찾을 수 없습니다. 사실 해외에서도 인기가 많아 30~50달러 정도에 팔리고 있습니다. 그러나 오랫동안 RuNet에는 많은 "균열"이 있었기 때문에 SSH Tunnel Easy를 컴퓨터에 다운로드하게 될 것입니다.
SSH Tunnel Easy의 특징은 이 프로그램이 사용자의 문제를 완전히 해결한다는 것입니다. 즉, SSH 터널을 생성합니다. 즉, 한 애플리케이션에서 다른 애플리케이션으로 서두를 필요가 없습니다. 필요한 기능 SSH Tunnel Easy에서는 이미 사용 가능합니다. 이 프로그램을 사용하면 데이터 전송뿐만 아니라 구성도 할 수 있습니다. 자동 다운로드여러 채널을 통해 파일을 전송합니다. 그렇지 않으면 SSH Tunnel Easy 대신 문제의 애플리케이션이 제공하는 기능을 아직 구현할 수 없는 많은 프로그램을 설치해야 합니다.
SSH Tunnel Easy는 병렬 연결 문제를 해결합니다. 사실 데이터 전송 요청으로 여러 병렬 채널을 통해 동시에 서버에 연결하려고 하면 SSH 호스트가 이를 견디지 못하고 중단되는 경우가 많습니다. SSH Tunnel Easy는 각 다운로드 채널에 대해 별도의 네트워크 프로토콜을 생성하므로 서버 중단을 방지합니다. 이 영리한 솔루션을 사용하면 여러 분기로 나누어지는 왕복 터널과 전방 터널을 만들 수 있으므로 결과적으로 처짐이나 오작동이 더 이상 발생하지 않습니다!
OpenSSH를 사용하여 터널 및 VPN 설정
쉬운 방법을 찾고 싶지 않다면 다음을 사용할 수 있습니다. 표준 프로그램 SSH 네트워크 프로토콜을 사용하여 다운로드 터널을 구성하기 위한 OpenSSH입니다. 이 방법은 운영 체제가 설치된 사용자에게 매우 적합합니다. 우분투 시스템또는 리눅스. 먼저 OpenSSH를 설치해야 합니다. 이렇게 하려면 콘솔에 다음을 입력하세요. 다음 명령: sudo 적성 설치 openssh-server.
사실은 모든 터널, 역방향, 직접 및 다중 채널을 다음을 사용하여 생성할 수 있다는 것입니다. 표준 기능 OpenSSH. 하지만 이렇게 하려면 이 애플리케이션의 기능을 이해하고 해당 구성을 구성할 수 있어야 합니다. 터널을 만들려면 최소한 내부 터널에 대한 권한을 부여해야 합니다. 구성 파일, SSH 프로토콜 설정을 정의합니다. 터널링을 활성화하려면 다음을 입력하십시오. 다음 줄파일로: PermitTunnel 지점 간. 그런 다음 OpenSSH 서버 프로그램을 다시 시작해야 합니다. 이렇게 하려면 다음 명령을 입력하십시오: service ssh restart.
이러한 터널 조직에는 큰 문제가 하나 있다는 점을 바로 알아두시기 바랍니다. 그리고 터널을 연결하려면 최고 관리자 계정을 통해 호스트에 로그인해야 한다는 사실에 있습니다. 아시다시피 이는 SSH 프로토콜 보안 규칙을 심각하게 위반하는 것입니다. 루트 사용자는 기본적으로 활성화되어 있지만 전혀 안전하지 않습니다. 귀하의 비밀번호가 도난당하면 모든 것을 잃게 됩니다. 사이트는 말 그대로 강탈당하고 파괴될 것입니다. 따라서 매우 복잡한 암호화된 비밀번호를 만들거나 공개 키를 사용하여 인증을 활성화하십시오.
루트로 로그인하면 다음을 사용하여 터널을 생성할 수 있습니다. 명령줄. sudo 또는 루트를 통해 명령을 실행해야 합니다. 그리고 -w local_tunnel:reverse_tunnel과 같은 작업을 등록해야 합니다. 로컬 및 반환 터널 대신 숫자를 입력하십시오. 두 개의 0을 입력하면 서버와 클라이언트 모두에 대해 tun0 터널이 생성됩니다.
다음 단계는 두 터널이 서로 데이터를 전송할 수 있도록 구성하는 것입니다. 다음은 터널 설정의 예입니다. 서버 터널의 경우 - ifconfig tun0 10.0.0.1/30 pointopoint 10.0.0.2, 클라이언트 터널의 경우 - ifconfig tun0 10.0.0.2/30 pointopoint 10.0.0.1.
하지만 그게 전부는 아닙니다. 터널을 통해 자동 데이터 다운로드를 생성하려면 설정에서 이를 기본 게이트웨이로 지정해야 합니다. 하지만 이 경우 DNS와 서버에 대한 경로가 손실됩니다. 따라서 현재 게이트웨이는 다음을 통해 라우팅 테이블에 등록되어야 합니다. 경로 명령 add -host XX.XX.XX.XX gw HH.HH.HH.HH (XX는 한 줄에 DNS IP, 다른 줄에 서버 IP, HH는 삭제해야 하는 현재 게이트웨이의 IP입니다. 두 명령 모두에서).
이제 현재 게이트웨이를 삭제하고 새 게이트웨이를 추가합니다. 다음을 사용하여 제거 노선델 기본값. 그리고 비슷한 기능을 사용하여 새 것을 등록합니다: Route add default gw 10.0.0.1 (귀하의 경우 터널을 생성할 때 지정한 내용에 따라 IP가 다를 수 있습니다).
이러한 설정을 정의한 후에는 모든 것이 잘못됩니다. 표준 채널, 터널을 통해 보안 네트워크 프로토콜로 자동 리디렉션됩니다. 즉, 이런 방식으로 모든 데이터와 트래픽을 통과하는 자동 터널이 생성되었습니다. 그러나 한 가지 문제가 더 남아 있습니다. 트래픽이 서버에 도달하지만 아무 일도 일어나지 않습니다. 그런 다음 방송을 설정하기만 하면 됩니다. 네트워크 주소 SSH 클라이언트용 NAT. 이를 구현하려면 iptables -t nat -A POSTROUTING -s 10.0.0.2 -j MASQUERADE라는 새 규칙을 추가해야 합니다. 이제 남은 것은 커널을 통해 IP 전달을 활성화하고 시작할 때마다 활성화를 구성하는 것입니다. 그 후에는 터널링이 성공한 것으로 간주될 수 있습니다! 보시다시피 OpenSSH를 사용하면 모든 것이 훨씬 더 복잡하지만 그럼에도 불구하고 시도하면 모든 것이 현실입니다.
VPN 열기
물론, 프로그램 간의 경쟁이 제 역할을 했습니다. 이제 다양한 방법으로 VPN 채널을 생성할 수 있습니다. 그 중 하나가 Open VPN입니다. Linux에서도 사용할 수 있습니다. 따라서 Open VPN을 설치하려면 터미널로 이동하여 apt-get install openvpn openvpn-docs 줄을 입력해야 하며 그 후에 애플리케이션이 다운로드되어 설치됩니다. 관리자 비밀번호를 묻는 메시지가 나타날 수 있습니다.
Open VPN은 작업의 전반적인 복잡성에 따라 다양한 방식으로 구성할 수 있습니다. 예를 들어 두 컴퓨터 사이에 터널링이 필요한 경우 설정은 매우 간단하지만 컴퓨터가 많으면 구성에 어려움을 겪게 됩니다.
따라서 두 컴퓨터 사이에 간단한 터널을 생성하려면 다음을 생성해야 합니다. 특수 키. 이는 openvpn —genkey —secret static.key 요청을 사용하여 수행됩니다. 생성된 키는 설치 중에 생성된 Etc 디렉터리에 있는 openvpn 폴더로 서버와 클라이언트 모두에 전송되어야 합니다. 이 폴더 안에는 서버와 클라이언트에 대해 다르게 이름을 지정할 구성이 포함된 파일을 생성합니다. 서버에서는 server.conf를 생성하고 클라이언트에서는 client.conf를 작성합니다. 표준 설정웹사이트에서 구성 파일을 찾을 수 있습니다. 애플리케이션 열기 VPN.
공식 Open VPN 웹사이트에서 복사한 특수 구성을 추가한 후에는 서버와 컴퓨터 모두에서 애플리케이션을 실행하고, 채널의 핑을 확인하고, 시스템을 활성화한 후 애플리케이션의 영구 자동 실행을 활성화하기만 하면 됩니다. 코드: chkconfig openvpn 켜짐. 그 후에는 서버와 클라이언트 간에 데이터를 교환할 수 있습니다.
한편으로 Open VPN은 매우 편리한 적용, 이를 통해 서버 간에 터널을 빠르게 생성할 수 있지만, 반면에 여러 클라이언트를 호스트에 연결하는 VPN을 쉽게 생성할 수는 없습니다. 이렇게하려면 실제로 머리 위로 뛰어 올라 설정에 빠져야합니다. 너무 어렵습니다. 따라서 이러한 문제를 해결하려면 다른 유틸리티를 사용하는 것이 좋습니다.
SSH를 통해 정방향 및 역방향 터널을 만드는 다른 방법은 무엇입니까?
이 문제를 해결하기 위해 설명된 방법은 프로그래머가 기본적으로 가지고 있는 전체 도구 목록이 아닙니다. 동일한 Linux를 통해 여러 가지 방법으로 터널을 만들 수 있습니다. 이제 컴퓨터를 원격 서버에 연결하는 방법과 SSHD에 연결된 다른 컴퓨터에 대한 연결을 설정하는 방법에 대한 매우 간단한 방법을 살펴보겠습니다.
따라서 10.10.2.1:80에 있는 인터넷 서비스에 연결해야 한다고 가정해 보겠습니다. 이 경우 호스트는 site.ru와 같은 특정 도메인을 통해 작동합니다. 당신이 해야 할 일은 서버를 통해 원하는 IP 주소로 터널을 전달하는 것뿐입니다. 이는 -f, -N 및 -L 명령을 사용하여 수행됩니다. 첫 번째는 연결을 활성화한 후 백그라운드로 들어가야 한다는 것을 프로토콜에 설명하고, 두 번째는 모든 후속 명령을 취소하고, 세 번째는 특정 호스트에 대한 연결을 필요한 IP 주소로 리디렉션합니다. 명령은 다음과 같이 들립니다: ssh -f -N [이메일 보호됨]-L 8080:10.10.2.1:80.
보시다시피 이것은 매우 간단한 솔루션입니다. 어떤 방법을 선택하느냐는 업무와 기술에 따라 달라집니다!
게시자: 관리자 2017년 10월 17일
SSH 터널링 작동 방식
SSH 터널 또는 man(1) ssh가 부르는 SSH 포트 전달은 익숙한 일반 SSH 세션 위에서 실행되는 선택적 프로토콜 기능입니다. SSH 터널을 사용하면 다음을 보낼 수 있습니다. TCP 패킷 SSH 연결의 한 쪽에서 다른 쪽으로 IP 헤더를 미리 브로드캐스트합니다. 특정 규칙전송 과정 중.
SSH 터널의 작동 방식을 이해하는 것은 매우 간단합니다. 이를 지점 간 연결로 상상하면 됩니다. PPP와 마찬가지로 연결의 한쪽 끝에 도달하는 모든 패킷은 터널의 다른 쪽 끝에서 전송되고 수신됩니다. 또한 IP 헤더에 지정된 수신자 주소에 따라 패킷은 터널의 수신측에서 처리되거나(패킷이 직접 패킷을 대상으로 하는 경우) 네트워크로 더 라우팅됩니다(수신자가 다른 네트워크인 경우). 마디).
SSH 터널과 PPP 연결의 주요 차이점은 SSH 터널에서는 TCP 트래픽만 래핑할 수 있다는 것입니다. (참고: SSH 터널 내부의 TCP 소켓을 통해 UDP를 전달하는 몇 가지 해킹이 있지만 해당 솔루션은 이 기사의 범위를 벗어납니다.)
두 번째 차이점은 지점 간 연결의 경우 들어오는 트래픽 SSH 터널의 경우 트래픽의 "진입점"을 명시적으로 설정해야 하는 반면, 어느 쪽에서나 시작할 수 있습니다. "진입점"은 형식의 매개변수입니다.<адрес>:<порт>, 터널에 들어가기 위해 열어야 하는 소켓을 나타냅니다(SSH 세션의 로컬 또는 원격 측에서).
진입점 외에도 다음 형식의 규칙을 추가로 지정해야 합니다.<адрес>:<порт>, 이에 따라 전송 중에 TCP 패킷의 헤더(보다 정확하게는 주소 및 대상 포트)를 다시 작성해야 합니다. 진입점은 터널의 양쪽 끝에서 설정할 수 있습니다. –L(로컬) 및 –R(원격) 키가 이 매개변수를 담당합니다. 로컬 및 원격이란 원래 측, 즉 SSH 세션을 설정하는 호스트의 관점에서 터널 측을 의미합니다.
지금까지는 다소 혼란스러워 보이므로 구체적인 예를 들어 살펴보겠습니다.
직접 SSH 터널 - NAT 뒤의 서버에 대한 액세스 제공
Alex는 Qwerty Cakes라는 소규모 사과 파이 회사의 시스템 관리자로 일하고 있습니다. 회사 전체의 네트워크는 하나의 브로드캐스트 도메인 192.168.0.0/24에 위치합니다. 인터넷에 접속하기 위해 Linux 기반 소프트웨어 라우터가 사용되며, 그 주소는 회사 네트워크 측에서는 192.168.0.1이고 인터넷 측에서는 1.1.1.1입니다. OpenSSD 데몬은 소켓 1.1.1.1:22를 통해 액세스할 수 있는 라우터에서 실행 중입니다. 네트워크 내부에서는 내부 기업 포털, Alex는 내일 아침까지 변경해야 합니다. 웹 인터페이스. 그러나 Alex는 직장에 늦게까지 머물고 싶지 않고 집에서 포털에 액세스하고 싶어합니다. 가정용 컴퓨터주소는 2.2.2.2입니다.
Alex는 집에 돌아와 저녁 식사 후 회사 라우터에 다음 연결을 설정합니다.
무슨 일이에요? Alex는 자신의 집 컴퓨터에서 터널 127.0.0.1:8080에 대한 로컬 "진입점"을 여는 동안 주소 2.2.2.2와 1.1.1.1 사이에 SSH 세션을 설정했습니다.
alex@Alex-PC:~$ sudo lsof -nPi | 그렙 8080
SSH 3153 알렉스 4u IPv4 9862 0t0 TCP 27.0.0.1:8080(듣기)
Alex의 컴퓨터에서 소켓 127.0.0.1:8080에 도달하는 모든 TCP 패킷은 다음을 통해 전송됩니다. 지점 간 연결 SSH 세션 내에서 이 경우 TCP 헤더의 대상 주소는 127.0.0.1에서 192.168.0.2로, 포트는 8080에서 80으로 다시 작성됩니다.
이제 회사 포털에 액세스하려면 Alex는 브라우저에 다음을 입력하기만 하면 됩니다.
그들은 어떻게 가나요? 네트워크 패킷 SSH 터널 내부
SSH 터널을 통과할 때 TCP 패킷에 어떤 일이 발생했는지 자세히 살펴보겠습니다.
1. 소스 주소가 127.0.0.1이고 대상 주소와 포트가 127.0.0.1:8080인 TCP 패킷이 소켓 127.0.0.1:8080에 들어갔습니다. 프로세스별로 열기 SSH;
2. SSH 프로세스는 변환 규칙에 따라 패킷을 수신하고 대상 주소와 포트를 192.168.0.2:80으로 다시 작성하고 SSH 세션 내에서 원격 당사자 1.1.1.1로 보냈습니다.
3. 라우터 1.1.1.1의 sshd 프로세스는 패킷을 수신하고 대상 주소를 확인한 후 이를 호스트 192.168.0.2로 보냈습니다. 동시에 소스 주소를 127.0.0.1에서 자체 인터페이스 주소 192.168.0.1로 다시 썼습니다. SSH 터널의 존재에 대해 아무것도 모르는 수신자가 패킷을 라우터로 반환하고 자체 로컬 호스트 127.0.0.1로 보내지 않았습니다.
alex@Alex-PC:~$ ssh -L
127.0.0.1:8080:192.0.0.2:80 [이메일 보호됨]
안에 이 예에서는, Alex가 액세스해야 하는 포털이나 기타 리소스가 라우터 자체에 있는 경우(예: 192.168.0.1:80) 명령은 다음과 같습니다.
localhost에서 서비스를 사용할 수 있는 경우(예: 로컬 SQL서버), 다음과 같이 액세스할 수 있습니다.
alex@Alex-PC:~$ ssh -L
127.0.0.1:13306:127.0.0.1:3306 [이메일 보호됨]
-L 127.0.0.1:80:127.0.0.1:80 과 같은 구성은 언뜻 보면 꽤 이상해 보일 수 있습니다. 그러나 패킷 라우팅에 대한 결정이 터널의 원격 측에서 이루어진다는 점을 기억하면 복잡한 것은 없습니다. 기본 규칙을 기억해야 합니다: 두 번째 쌍<адрес>:<порт>터널의 원격 측에서 처리됩니다.
따라서 변환 규칙의 대상 주소가 127.0.0.1인 패킷은 SSH 세션의 두 번째 측면에서 처리되며 다른 것은 처리되지 않습니다.
이미 짐작하셨겠지만 터널 진입점은 루프백 인터페이스에서만 생성할 수 있는 것이 아닙니다. 로컬 호스트뿐만 아니라 다른 네트워크 참가자도 터널에 액세스할 수 있어야 하는 경우 실제 인터페이스 주소를 소켓 주소로 지정할 수 있습니다.
alex@Alex-PC:~$ ssh -L
10.0.0.5:8080:192.0.0.2:80 [이메일 보호됨]
Alex의 컴퓨터 Alex-PC에는 주소가 2.2.2.2와 10.0.0.5인 두 개의 네트워크 인터페이스가 있습니다. 세션 설정 프로세스 중에 ssh는 Alex-PC 컴퓨터에서 소켓 10.0.0.5:8080을 엽니다. 이제 Alex는 주소가 10.0.0.4인 노트북과 전체 홈 네트워크 10.0.0.0/24에서 포털 192.168.0.2:80에 액세스할 수 있습니다.
역방향 SSH 터널 - 리소스를 인터넷에 노출
이미 말했듯이 터널 진입점은 SSH 세션 개시자 측뿐만 아니라 원격 측, 즉 SSH 세션을 설정하려는 측에서도 열 수 있습니다. 이렇게 하려면 -L 옵션 대신 -R 옵션을 사용하십시오. 그것은 무엇을 위한 것입니까?
예를 들어, 출판할 수 있으려면 지역 서비스원격 액세스용.
Alex의 랩탑은 회사 포털의 테스트 사본과 함께 127.0.0.1에서 사용 가능한 Apache 웹 서버를 실행합니다. Alex는 인터페이스를 테스트하기 위해 동료에게 웹 서버에 대한 액세스 권한을 부여해야 합니다. 일반적으로 이러한 목적을 위해서는 Alex가 보다 안정적인 테스트 샌드박스를 구현하는 것이 좋을 것입니다. 그러나 Alex는 이 기사에서 가상 캐릭터에 지나지 않기 때문에 SSH 터널의 작동을 보여주기 위해 자신의 랩탑과 Linux 라우터 사이에 세션을 설정합니다. -R 매개변수를 사용하면 포트 8080이 열립니다. 내부 인터페이스테스트 웹 서버의 소켓 127.0.0.1:80을 가리키는 주소 192.168.0.1의 라우터입니다.
보시다시피, 라우터에서 sshd 프로세스가 로컬 소켓 8080을 열었습니다.
알렉스@라우터:~$
sudo lsof -nPi | 그렙 8080
SSHD
17233 알렉스 9u IPv4
95930 0t0 TCP 192.168.0.1:8080 (듣기)
컴퓨터 192.168.0.200에서 192.168.0.1:8080에 게시된 테스트 포털로 전송된 TCP 패킷에서 어떤 일이 발생하는지 살펴보겠습니다.
1. 소스 주소가 192.168.0.200이고 대상 주소와 포트가 192.168.0.1:8080인 TCP 패킷은 sshd 프로세스에 의해 열린 소켓 192.168.0.1:8080에서 종료됩니다.
2. 변환 규칙에 따라 패킷을 수신한 sshd 프로세스는 대상 주소와 포트를 192.168.0.1:8080에서 127.0.0.1:80으로 다시 작성하고 SSH 세션 내에서 이를 원래 당사자에게 보냅니다. 2.2. 2.2;
3. 패킷을 수신하고 대상 주소를 확인한 Alex 노트북의 ssh 프로세스는 192.168.0.200의 보낸 사람 주소를 루프백 주소로 다시 쓰고 이를 아파치가 연 로컬 소켓 127.0.0.1:80으로 보냅니다. 프로세스.
보시다시피 방송 규칙은 매우 간단합니다. 터널용 소켓을 여는 호스트는 변환 규칙에 따라 대상 주소와 포트를 변환합니다. 터널 반대쪽에 있는 호스트는 라우팅 테이블에 따라 소스 주소와 포트를 변경합니다. 라우팅 테이블은 첫째, 올바른 방향으로 패킷을 전송하고, 둘째, 소스 주소를 패킷이 전송될 인터페이스의 주소로 대체하기 위해 필요합니다.
기사 마지막 부분에 남긴 중요한 메모 하나입니다.
터널 진입점을 열 때 실제 인터페이스의 주소 대신 localhost가 사용되는 경우 이를 생략할 수 있으므로 다음과 같이 명령을 단축할 수 있습니다.
alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [이메일 보호됨]
~ 전에
알렉스@알렉스-PC:~ssh -L
8080:192.0.0.1:80 [이메일 보호됨]
이것 중요한 특징구문은 다음 예에서 유용할 것입니다.
이중 터널링
조금 더 살펴보자 복잡한 예. NAT 뒤에 있는 SQL-Tester 사용자는 다음의 데이터베이스에 액세스해야 합니다. SQL 서버, NAT 뒤에도 있습니다. NAT 서버 네트워크에 해당 변환이 없기 때문에 SQL-Tester는 서버에 직접 연결할 수 없습니다. 그러나 두 호스트 모두에서 중간 서버 3.3.3.3과 SSH 세션을 설정할 수 있습니다.
SQL 서버에서 서버 3.3.3.3에 대한 SSH 연결을 설정하고 서버 3.3.3.3의 루프백 인터페이스에서 포트 13306을 엽니다. 이는 SQL 서버의 로컬 소켓 127.0.0.1:3306에서 실행되는 로컬 SQL 서비스를 나타냅니다. :
dbuser@SQL-server:~$ ssh -R 13306:127.0.0.1:3306
이제 SQL-Tester 클라이언트 호스트에서 3.3.3.3과의 연결을 설정하고 클라이언트의 루프백 인터페이스에서 포트 3306을 엽니다. 이는 차례로 서버 3.3.3.3의 127.0.0.1:13306을 참조합니다. SQL Server의 127.0.0.1:3306을 나타냅니다. 간단 해.
tester@SQL-테스터:~$ ssh -L
3306:127.0.0.1:13306 [이메일 보호됨]
동적 터널 - SSH를 양말 프록시로 사용
변환 규칙을 명시적으로 표시하는 터널과 달리 동적 터널은 완전히 다른 원리로 작동합니다. 각 대상 주소와 포트에 대해 일대일 주소:포트 매핑을 지정하는 대신 SSH 세션의 로컬 측에서 소켓을 열어 호스트를 SOCKS4/SOCKS5 프록시 서버로 전환합니다. 한 번 보자
예:
서버 2.2.2.2에 대한 SSH 세션 내부의 클라이언트 호스트에 동적 터널 소켓 127.0.0.1:5555를 생성합니다.
사용자@클라이언트:~$ ssh -D 5555 [이메일 보호됨]
포트가 열려 있는지 확인
user@client:~$ sudo lsof -nPi | 그렙 5555
7284 사용자 7u
IPv4 0x74fcb9e03a5ef5b1 0t0 TCP 127.0.0.1:5555(듣기)
그리고 브라우저 설정이나 SOCKS 프록시를 지원하는 다른 소프트웨어에 프록시를 등록합니다.
이제 모든 브라우저 트래픽은 호스트 1.1.1.1과 2.2.2.2 사이의 암호화된 SSH 연결 내에서 SOCKS 프록시를 통과합니다.
Microsoft Windows에서 SSH를 사용하는 방법은 무엇입니까?
기사를 읽은 후에는 SSH 터널의 모든 이점이 Unix 계열 시스템 사용자에게만 제공된다는 결론을 내릴 수 있습니다. 그러나 그렇지 않습니다. 거의 모든 것 터미널 클라이언트 SSH 프로토콜을 통해 실행되는 Windows의 경우 터널링을 지원합니다.
한동안 Windows를 다음과 같은 용도로 사용할 수 있었습니다. SSH 클라이언트. Windows에 SSH 서버를 설치할 수 있습니다.
SSH 터널은 언제 사용하나요?
물론, 전투 서버에 영구 터널을 만들려면 특수한 터널을 사용해야 합니다. 소프트웨어. 이 아니라면 빠른 솔루션포트 전달, 문제 해결, 빠른 원격 액세스 확보 및 일반적으로 "지금 여기"의 특정 문제 해결 등의 작업을 수행할 때 SSH 터널을 사용하면 종종 좋은 도움이 됩니다.
이들의 도움을 받아 전체 네트워크, 터널 내 터널을 구축하고 터널 유형을 결합할 수 있습니다. 이를 통해 접근이 불가능해 보이는 장소에 빠르게 접근할 수 있습니다.
누구나 시스템 관리자지속적으로 원격으로 작업해야 하는데, 급하게 노드에 연결해야 하는 상황이 있습니다. 내부 네트워크, 외부에서 접근이 차단됩니다. 특정 네트워크의 다른 노드에 대한 액세스가 있으면 좋지만 다음에서 액세스하는 경우가 발생합니다. 글로벌 네트워크아니요, 이 경우 일반적으로 TeamViewer 또는 유사한 소프트웨어를 사용하지만 SSH를 통해 해당 네트워크에 연결하거나 중간 SSH 서버와 연결을 설정할 수 있는 경우 제3자의 개입 없이 빠르고 쉽게 액세스를 구성할 수 있습니다. 파티 소프트웨어.
보안 수준이 낮은 네트워크에 대한 원격 액세스와 관련하여 가장 먼저 떠오르는 것은 VPN이지만, 관리 연결을 위해 VPN을 설치하는 것이 항상 권장되는 것은 아닙니다. 특히 다음과 같은 경우에는 더욱 그렇습니다. 우리 얘기 중이야아웃소싱 또는 "들어오는 관리자"에 대해. 또한 통신 조건이 항상 안정적인 VPN 연결을 허용하는 것은 아니며, 특히 모바일 네트워크를 사용해야 하는 경우 더욱 그렇습니다.
또한 거의 모든 네트워크에서 SSH를 통해 액세스할 수 있는 장치나 서버를 찾을 수 있거나 글로벌 네트워크에 VPS와 같은 중간 서버가 있습니다. 이 경우 훌륭한 솔루션전용 IP 주소 문제를 제거하는 중간 노드를 포함하여 보안 통신 채널을 쉽게 구성할 수 있는 SSH 터널이 있을 것입니다.
엄밀히 말하면 SSH 터널은 본격적인 터널이 아니며 이 이름은 전문적인 환경에서 개발된 안정적인 이름으로 간주되어야 합니다. 해당 기술의 공식 명칭은 SSH 포트 전달- 이것은 선택적인 기능입니다 SSH 프로토콜를 사용하면 SSH 연결의 한 쪽에서 다른 쪽으로 TCP 패킷을 전송할 수 있으며, 전송 과정에서 미리 정해진 규칙에 따라 IP 헤더를 브로드캐스팅할 수 있습니다.
또한 모든 트래픽을 모든 방향으로 전송할 수 있는 VPN 터널과 달리 SSH 터널에는 진입점이 있으며 TCP 패킷으로만 작동할 수 있습니다. 실제로 이는 SSH 프로토콜을 통해서만 포트 전달(공식 이름에서 알 수 있듯이)과 가장 유사합니다.
SSH 터널의 동작을 좀 더 자세히 살펴보겠습니다. 예를 들어, RDP 프로토콜을 통해 일부 원격 서버에 대한 액세스를 제공하는 전형적인 사례를 살펴보겠습니다.
원격 네트워크에 주소가 192.168.0.105인 대상 서버가 있지만 외부 네트워크에서 해당 서버에 액세스할 수 없다고 가정해 보겠습니다. 우리가 연결할 수 있는 유일한 장치는 주소가 192.168.0.1인 라우터뿐입니다. SSH 연결을 설정할 수 있습니다.
매우 생각해보자 중요한 점: 모든 SSH 터널 매개변수를 설정합니다. 창시자연결, 일명 SSH 클라이언트, 터널의 두 번째 끝은 항상 우리가 연결하는 서버입니다. SSH 서버. 이러한 맥락에서 클라이언트와 서버는 순전히 연결 측면으로 이해되어야 합니다. 예를 들어 VPS 서버는 SSH 클라이언트 역할을 할 수 있고 관리자의 노트북은 SSH 서버 역할을 할 수 있습니다.
진입점은 다음 위치에 있을 수 있습니다. 어느 쪽이든연결하면 TCP 소켓이 열립니다. 지정된 매개변수, 들어오는 연결을 허용합니다. 종료점은 연결을 허용할 수 없으며 변환 규칙에 따라 패킷을 라우팅하기만 합니다.
위의 다이어그램을 살펴보겠습니다. 우리는 다음을 사용하여 SSH 터널을 설정했습니다. 로컬 머신에게 원격 라우터로, 로컬 지정 진입점 127.0.0.1:3389그리고 번역 규칙 192.168.0.105:3389. 다시 한 번, 변환 규칙은 종료 지점을 나타내는 것이 아니라 터널을 나갈 때 패킷이 전송될 노드를 결정한다는 사실에 주목합니다. 잘못된 주소를 지정하거나 호스트가 연결을 허용하지 않는 경우 SSH 터널이 설정되지만 대상 호스트에 액세스할 수 없습니다.
지정된 진입점에 따라 SSH 서비스는 포트 3389에서 연결을 수신하는 로컬 TCP 소켓을 생성합니다. 따라서 RDP 연결 창에서 대상으로 지정합니다. 로컬호스트또는 127.0.0.1 , RDP 클라이언트는 동적 포트를 열고 대상 주소가 포함된 패킷을 보냅니다. 127.0.0.1:3389 및 소스 주소 127.0.0.1:61256 , 그는 패킷 수신자의 실제 목적지에 대해 아무것도 모릅니다.
진입점에서 현재 패키지 SSH 터널 반대편으로 전송되며 변환 규칙에 따라 대상 주소가 다음으로 변경됩니다. 192.168.0.105:3389 , SSH 서버는 자체 라우팅 테이블에 따라 추가 결정을 내리고 소스 주소를 자체 주소로 대체합니다. 그렇지 않으면 대상 서버는 응답 패킷을 로컬 주소로 보내려고 시도합니다.
따라서 RDP 클라이언트는 로컬 소켓과 함께 작동하며 RDP 패킷은 이 노드를 벗어나지 않습니다. 터널 내부에서는 SSH 프로토콜을 통해 암호화된 형식으로 전송되지만 SSH 서버와 RDP 서버 간에는 일반 RDP 연결이 설정됩니다. 네트워크 192.168.0.0 , 공개 형식. 안전하지 않은 프로토콜을 사용할 때 이 점을 고려해야 하며, 변환 규칙이 종료점이 있는 노드 너머를 가리키는 경우 그러한 연결(종료점과 대상 노드 사이)이 발생한다는 점을 확실히 기억해야 합니다. 자신을 변호하지 않고 SSH를 통해.
알아낸 후 일반 개요 SSH 터널이 어떻게 작동하는지 살펴보겠습니다. 실용적인 옵션사용 시 Debian/Ubuntu 제품군의 Linux 시스템을 하나의 플랫폼으로 간주할 것입니다. 그러나 약간의 수정을 거쳐 아래에 설명된 모든 내용은 모든 UNIX 계열 시스템에 유효합니다.
로컬 진입점이 있는 SSH 터널
터널 지역 지점로그인은 원격 네트워크에 전용 IP 주소가 있다고 가정하는 노드 중 하나와 SSH 연결을 설정할 수 있는 경우 원격 네트워크의 노드에 액세스하는 데 사용됩니다.
동일한 옵션인 원격 서버에 대한 RDP 연결을 고려해 보겠습니다. 다이어그램의 주황색 점선은 보안 SSH 연결을 나타내고 파란색 화살표는 일반 TCP 연결을 나타냅니다.
가장 간단한 버전에서는 클라이언트 PC에서 원격 네트워크의 라우터로의 연결을 설정하고 변환 규칙에 대상 노드를 지정합니다.
SSH -L 127.0.0.1:3389:192.168.0.105:3389 [이메일 보호됨]
열쇠 -엘는 진입점이 로컬에 있음을 나타내고 콜론은 진입점의 주소와 포트를 나타내고 변환 규칙의 주소, 포트를 나타냅니다. 종료점은 우리가 연결하는 노드입니다. rt.example.com.
네트워크에 라우터(또는 다른 Linux 서버)도 있는 경우 이를 진입점으로 만들 수 있습니다. 지역 네트워크. 이론적으로 이렇게 하려면 다음과 같이 터널을 세워야 합니다.
SSH -L 192.168.31.100:3389:192.168.0.105:3389 [이메일 보호됨]
이 경우 SSH 서비스는 인터페이스 192.168.31.100에서 TCP 소켓을 열어야 하지만 실제로는 이런 일이 발생하지 않습니다. 이는 대부분의 UNIX 계열 시스템의 표준인 OpenSSH의 구현 기능 때문입니다.
기본적으로 OpenSSH는 진입점을 엽니다. 방금 로컬 인터페이스 . 이것을 확인하는 것은 쉽습니다:
외부 인터페이스에서 TCP 소켓에 대한 액세스를 제공하려면 키를 사용해야 합니다. -g, 또는 추가 구성 파일 /etc/ssh/sshd_config옵션:
게이트웨이 포트 예
그러나 이후 소켓은 다음으로부터의 연결을 허용합니다. 어느개시자 네트워크 인터페이스:
이는 포트 3389가 모든 사용자에게 열려 있음을 의미합니다. 네트워크 인터페이스, 따라서 진입점이 에지 장치인 경우 예를 들어 iptables를 사용하여 소켓에 대한 액세스를 제한해야 합니다. 예를 들어, 외부 네트워크(eth0 인터페이스)로부터의 액세스를 차단해 보겠습니다.
Iptables -A INPUT -i eth0 -p tcp --dport 3389 -j DROP
따라서 다음 명령을 사용하여 작업 터널을 올려야 합니다.
SSH -L -g 3389:192.168.0.105:3389 [이메일 보호됨]
한 가지 더 참고하세요. 진입점이 로컬 인터페이스와 일치하고 OpenSSH의 경우 항상 그런 경우 진입점 포트에서 명령을 즉시 시작하여 생략할 수 있습니다.
가능하면 키를 사용하는 것이 좋습니다. -g, 구성 파일에 옵션을 추가하는 대신 후자의 경우 이 설정을 잊어버리면 원격 네트워크의 보호되지 않은 서비스에 대한 액세스가 외부 세계에 공개될 위험이 있기 때문입니다.
원격 진입점이 있는 SSH 터널
반대로 원격 진입점이 있는 터널을 사용하면 원격 네트워크에 로컬 서비스를 게시할 수 있습니다. 가장 일반적인 용도 중 하나는 전용 IP 주소 없이 네트워크에 액세스하는 것입니다. 관리자 네트워크.
첫 번째 옵션에서는 원격 서버 자체가 로컬 네트워크 라우터와 연결을 설정합니다. 이 작업은 다음과 같은 간단한 명령으로 수행할 수 있습니다.
SSH -R 3389:127.0.0.1:3389 [이메일 보호됨]
-R 키는 터널의 원격 측에서 액세스 포인트를 열도록 지정한 다음 TCP 소켓 및 변환을 위한 포트를 지정합니다. 종료 지점에 도착하는 패킷은 로컬로 처리되어야 하기 때문에 로컬 인터페이스도 지정합니다.
주의 깊은 독자라면 우리가 키를 지정하지 않았다는 것을 알게 될 것입니다. -g, 그렇습니다. 사실 원격 진입점이 있는 터널의 경우 이 키는 적용 가능하지 않으며 다음 옵션을 사용해야 합니다.
게이트웨이 포트 예
SSH 서버 측에서.
안전상의 이유로 다음을 사용하는 것이 좋습니다. 이 설정 INPUT 체인에 대한 기본 정책 DROP을 사용하면 실수로 게시되는 것을 방지할 수 있습니다. 외부 인터페이스내부 서비스 및 리소스. 최소 구성에서는 INPUT 체인의 시작 부분에 네 가지 규칙을 추가해야 합니다.
Iptables -P 입력 삭제
iptables -A 입력 -i eth0 -m 상태 --상태확립됨, 관련됨 -j 수락
iptables -A 입력 -i eth1 -j 수락
iptables -A 입력 -i eth0 -p tcp --dport 22 -j 수락
첫 번째는 들어오는 패킷에 대한 기본 거부 정책을 설정하고, 두 번째는 호스트 자체에서 시작된 들어오는 패킷(나가는 패킷에 대한 응답)을 허용하며, 세 번째는 로컬 네트워크의 모든 연결을 허용합니다. 마지막으로 네 번째 규칙은 들어오는 SSH 연결을 위해 포트 22를 엽니다. 동일한 방식으로 외부 연결을 위해 다른 포트를 열 수 있습니다.
다이어그램에 제시된 두 번째 옵션은 SSH 터널이 네트워크 라우터에 의해 생성되는 것을 제공합니다. 이 경우 명령은 다음과 같습니다.
SSH -R 3389:192.168.0.105:3389 [이메일 보호됨]
우리의 진입점이 터널 반대편에 위치하므로 방송이 터널 개시자 측에 대해 표시된다는 사실에 다시 한 번 주목해 보겠습니다. V 이 경우 SSH 클라이언트는 두 개의 연결을 설정합니다. 하나는 rt.example.com을 사용하는 SSH이고 다른 하나는 192.168.0.105를 사용하는 두 번째 RDP입니다. 반면 로컬 진입점이 있는 터널을 사용하면 개시자는 SSH 서버와의 단일 연결을 설정합니다.
이중 SSH 터널
전용 IP 주소가 없는 두 노드를 연결해야 하는 경우가 종종 발생합니다. 이 경우 일반적으로 TeamViewer 또는 이와 유사한 타사 소프트웨어가 사용되지만, 사용 가능한 서버전용 IP 주소를 사용하면 더 쉽게 할 수 있습니다.
위의 다이어그램에 주목합시다. SSH를 사용하면 다음 터널의 진입점을 이전 터널의 종료점에 연결하여 전체 터널 체인을 구축할 수 있습니다. 따라서 관리 PC에서 RDP 서버로 터널을 가져오려면 두 노드 모두 회색 IP 주소를 가지며 중간 노드가 있는 두 개의 터널을 만들어야 합니다.
관리 PC의 로컬 진입점이 있는 터널:
SSH -L 3389:127.0.0.1:3390 [이메일 보호됨]
RDP 서버에 원격 진입점이 있는 터널:
SSH -R 3390:127.0.0.1:3389 [이메일 보호됨]
우리는 원격 서버에 구체적으로 표시했습니다. 비표준 포트더 명확하게 하기 위해 이제 모든 것이 어떻게 작동하는지 살펴보겠습니다. RDP 서버부터 시작하겠습니다. 원격 진입점이 있는 터널을 생성하고 포트 3390에서 연결을 허용하는 TCP 소켓을 엽니다. RDP 서버 자체를 브로드캐스트(127.0.0.1:3389)로 지정합니다. 즉. 이 터널의 입구에 도착하는 모든 패킷은 다음으로 전달됩니다. 로컬 포트 3389.
관리자 PC에 로컬 진입점이 있는 터널은 RDP 클라이언트가 브로드캐스트로 연결되는 포트 3389에서 로컬 소켓을 엽니다. 두 번째 터널의 진입점은 127.0.0.1:3390입니다.
이미 말했듯이 체인의 터널 수에는 제한이 없지만 실제로 두 개 이상의 중간 노드가 있는 터널이 필요한 경우는 거의 발생하지 않습니다. 각각의 새로운 중간 노드로 인해 전체 회로의 신뢰성이 감소하고 최종 속도는 경로의 가장 느린 섹션의 속도로 제한된다는 점을 기억해야 합니다.
동적 SSH 터널
위에서 설명한 것과 달리 동적 터널은 다르게 작동합니다. 즉, 호스트에서 로컬 TCP 소켓을 열어 SOCKS4/SOCKS5 프록시로 사용하여 원격 SSH 서버를 통해 인터넷에 액세스할 수 있습니다. 이는 다른 관할권에서 완전한 VPN을 설치할 필요가 없고 보안상의 이유로 공용 프록시나 VPN을 사용할 수 없는 경우 일부 제한 사항을 우회하는 데 유용할 수 있습니다.
이 유형의 터널은 다른 노드에서 인터넷에 일회성 액세스가 필요한 경우 특히 편리합니다. 간단한 예: 제 친한 친구가 미국에서 통신사 계약 iPhone 두 대를 가져와서 잠금 해제를 요청했습니다. 어려움 이 작업비밀은 없습니다. 계약 조건을 위반하지 않은 경우 운영자 웹 사이트로 이동하여 잠금 해제 신청서를 작성하세요. 그러나 문제는 T-Mobile 운영자가 미국 거주자만 사이트의 이 섹션에 액세스할 수 있었고 공용 프록시 및 VPN의 연결이 안전하지 않아 거부되었다는 것이 밝혀졌습니다.
동적 SSH 터널을 사용하면 미국에서 VPS를 사용하여 이 문제를 신속하게 해결할 수 있습니다. 이러한 터널을 만들려면 다음 명령을 입력하세요.
SSH-D 1080 [이메일 보호됨]
여기서 1080은 SOCKS 프록시를 사용할 수 있는 포트입니다. 남은 것은 로컬 프록시 서버를 사용하도록 브라우저를 구성하는 것뿐입니다.
이 방법의 또 다른 장점은 프록시 서버가 호스트에 로컬로만 존재하고 호스트에 추가 포트가 없다는 것입니다. 외부 네트워크열 필요가 없으며 클라이언트와 서버 사이에는 SSH 연결만 있습니다.
이를 통해 외부 관찰자로부터 인터넷 활동의 성격을 숨길 수 있으며, 이는 다음과 같은 경우에 유용할 수 있습니다. 공용 네트워크, 제3자가 트래픽을 가로채서 분석할 수 있다고 믿을 만한 합리적인 근거가 있는 경우. 이 경우 SSH 터널은 다음을 제공합니다. 강력한 암호화안전하지 않은 네트워크를 통해 데이터를 전송했지만 이를 위해서는 완전한 신뢰귀하가 인터넷에 접속하는 서버에.
안전에 관한 몇 마디
이는 기사의 범위를 벗어나지만 상당한 이점을 가져올 수 있는 한 가지 기능은 언급할 수 없습니다. 불쾌한 놀라움. 위 명령 중 하나를 사용하여 SSH 터널을 올리면 터널 외에도 다음을 얻을 수 있습니다. 콘솔 열기연결하려는 서버에서. 아래 스크린샷의 초대 문구를 자세히 살펴보세요.
상단에는 로컬 호스트의 초대가 표시되고 하단에는 터널을 올린 후 원격 서버의 초대가 표시됩니다. 통신 채널을 확인해야 하거나 원격에서 특정 설정을 수행해야 할 경우 편리하지만 일상 생활에서 콘솔이 어느 서버에 연결되어 있는지 잊어버리거나 주의를 기울이지 않고 의도한 명령을 실행하면 심각한 문제가 발생할 수 있습니다. ~을 위한 로컬 노드, 특히 슈퍼유저 권한으로 연결하는 경우 더욱 그렇습니다.
따라서 터널의 기능을 확인한 후 원격 서버에서 명령 실행을 금지하는 -N 스위치를 사용하여 터널을 시작해야 합니다. 예를 들면 다음과 같습니다.
SSH -N -L -g 3389:192.168.0.105:3389 [이메일 보호됨]
물론, 서버에 연결하기 위해 슈퍼유저 계정을 사용해서는 안 됩니다. 이러한 목적을 위해서는 일반 계정을 만드는 것이 가장 좋습니다.
Windows의 SSH 터널
기사 전반에 걸쳐 Linux 시스템의 예를 사용하여 SSH 터널을 살펴봤고 Windows 사용자이러한 기회를 이용할 수 없다는 인상을 받을 수도 있습니다. 그러나 이는 사실이 아닙니다. 터널 생성을 지원하는 Windows용 SSH 클라이언트가 많이 있습니다. 우리는 그중 가장 인기있는 PuTTY를 고려할 것입니다. Windows에서 SSH 서버를 실행할 수도 있지만 이를 위해서는 특정 자격이 필요하며 항상 달성할 수 있는 것은 아닙니다. 안정적인 작동, 따라서 우리는 이 옵션을 고려하지 않을 것입니다.
PuTTY를 열고 트리 왼쪽에 있는 연결 - SSH - 터널:
다음 창이 우리 앞에 열리고 터널의 주요 설정이 하단에 집중되어 있으며 빨간색 프레임으로 강조 표시되어 있습니다. 소스 포트- 항상 로컬 인터페이스(127.0.0.1)에 있는 진입점의 포트를 나타냅니다. 목적지- 방송, 즉 여기서 패킷은 종료 지점에서 전송됩니다. 라디오 스위치 로컬 - 원격 - 동적터널 유형을 설정하며 키와 유사합니다. -엘,-아르 자형그리고 -디.
필수 필드를 모두 입력한 후 버튼을 사용하여 터널을 추가할 수 있습니다. 추가하다. 외부 호스트가 로컬 진입점 소켓에 액세스하도록 허용하려면 확인란을 선택하세요. 로컬 포트는 다른 호스트의 연결을 허용합니다.. 이 경우 다음 항목에 대한 액세스도 제한해야 합니다. 열린 포트 Windows 방화벽이나 타사 네트워크 필터를 사용합니다.
우리가 연결하는 서버는 다른 섹션에 지정되어 있습니다. 세션 PuTTY를 사용해 본 적이 있는 사람이라면 누구나 익숙할 것입니다. 나중에 사용할 수 있도록 세션 매개변수를 저장할 수 있습니다.
보시다시피 SSH는 관리자에게 보안을 위한 유연하고 강력한 도구를 제공합니다. 원격 액세스포트를 열거나 VPN 채널을 구성할 필요가 없습니다. 우리는 이 자료이 도구는 귀하에게 유용할 것이며 겉보기에 친숙해 보이는 도구의 새로운 기능을 익힐 수 있게 해줄 것입니다.
태그:
SSH-터널링은 암호화된 연결을 통해 암호화되지 않은 트래픽을 전송해야 하는 경우뿐만 아니라 네트워크의 리소스에 액세스할 수 없지만 액세스가 필요한 경우에도 도움이 될 수 있습니다.
몇 가지 옵션을 만들고 설정하는 방법을 살펴보겠습니다.
이제 서버가 생겼습니다. 서버를 호출해 보겠습니다. 호스트-1. 그에게 우리는 전체 권한단지 SSH- 하지만 열어야 해 수코양이, 포트 8082에서 작동 - 우리가 통과할 수 없습니다.
우리는 설정과 함께 옵션을 고려할 것입니다 윈도우그리고 퍼티.
열리는 SSH-에 연결 필요한 서버에, 로그인해 보겠습니다.
우리는 다음 매개변수를 지정합니다:
소스 포트: 시스템에서 사용되지 않는 포트입니다.
대상 포트: 127.0.0.1:8082
딸깍 하는 소리 추가하다, 그 다음에 적용하다.
브라우저 설정으로 이동하여 프록시 매개변수를 설정하세요.
이제 남은 것은 브라우저에서 http://localhost:3002 페이지를 여는 것뿐입니다. 그러면 해당 페이지로 이동합니다. 수코양이서버에서 호스트-1.
터널이 작동하지 않는 경우 서버에서 패킷 전달이 활성화되어 있는지 확인하십시오. /etc/ssh/sshd_config 파일에서 다음 행을 찾아 주석 처리를 제거합니다.
AllowTcpForwarding 예
SSHd를 다시 시작합니다.
# service sshd restart sshd 중지 중: [ 확인 ] sshd 시작 중: [ 확인 ]
또 다른 예 - 우리도 마찬가지입니다 외부 서버, 인터넷의 모든 리소스에 정상적으로 액세스할 수 있습니다. 하지만 직장에서는 접근이 가능하고 폐쇄되어 있습니다.
비슷한 작업을 수행하지만 약간의 차이가 있습니다. 설정 퍼티:
소스 포트 - 그대로 두고 대신 현지의- 선택하다 동적. 딸깍 하는 소리 추가하다, 적용하다.
브라우저 설정으로 이동해 보겠습니다.
여기서 프록시 유형은 HTTP가 아니라 SOCKS라는 점에 유의하세요.
즐겨찾는 사이트에 액세스해 보세요.
그리고 더 흥미로운 사례입니다.
우리는 같은 것을 가지고 있습니다 호스트-1. 그 외에도 두 번째 서버가 있습니다. 호스트-2. 게다가, 우리는 다음과 같은 기계를 가지고 있습니다. 윈도우, 리소스에 대한 액세스 권한을 부여받아야 함 팀시티서버에서 호스트-1포트 8111에서. 이 경우 다음에서 액세스합니다. 윈도우-서버용 머신만 있습니다. 호스트-2, 포트 22에서만 가능합니다.
우선, 우리는 사이의 터널을 올립니다. 호스트-1그리고 호스트-2. 우리는 다음을 수행합니다 호스트-1:
$ ssh -f -N -R 호스트-2:8082:localhost:8111 사용자 이름@host-2
그래서 우리는 터널을 엽니다. 호스트-1) 포트 8111을 보고 반대편에는 머신이 있습니다. 호스트-2, 포트 8082가 열리고 들어오는 연결을 기다립니다. 포트 8082에서 패킷을 수신할 때(lo0 인터페이스를 통해서만 중요함) - 해당 패킷을 머신으로 리디렉션합니다. 호스트-1포트 8111.
lo0 인터페이스에 관해서. 설치시 SSH-tunnel, 머신의 외부 IP를 지정하는 경우에도 연결은 localhost에서만 발생합니다. 127.0.0.1 .
살펴 보자 호스트-2:
$ netstat -anp | grep 8082 tcp 0 0 127.0.0.1:8082 0.0.0.0:* 듣기 -
이를 변경하려면 sshd 데몬 구성 파일(/etc/ssh/sshd_config)을 편집하고 매개변수를 변경해야 합니다.
#GatewayPorts 아니요
하지만 지금은 그렇게 하지 않을 것입니다. 이것은 단지 메모일 뿐입니다.
계속합시다. 설정으로 넘어가자 퍼티우리의 윈도우-자동차. 여기에서는 모든 것이 간단합니다. 이 기사의 예제 1을 사용하고 포트를 원하는 포트로 변경하기만 하면 됩니다(스크린샷에서는 거기에 있습니다). 연결하자 퍼티호스트에게 호스트-2, 설정 터널. 브라우저에서 설정 변경 대리— 필요한 것을 얻으려면 http://localhost:3002 주소를 지정하십시오.
SSH패킷 손실에 매우 민감하므로 터널이 자주 삭제될 수 있습니다.
이를 방지하려면 sshd 설정 파일 - /etc/ssh/sshd_config의 매개변수를 사용하여 재생할 수 있습니다.
#TCPKeepAlive 예 #ServerAliveInterval #ServerAliveCountMax
또는 autossh 유틸리티를 사용하십시오.