풀을 열지 않고 OpenVPN 클라이언트끼리 SSH로 연결하기

client-to-client은 꺼 둔 채 커널이 하나의 흐름을 전달하게 하고, 풀의 나머지는 닫아 두십시오. 서버 규칙 두 개와 목적지 규칙 하나입니다.

한 클라이언트가 다른 클라이언트의 SSH 서비스에 도달해야 하고, 풀의 나머지는 지금처럼 격리된 상태로 남아야 합니다. 솔깃한 스위치는 client-to-client이며, 모두에게 피어 간 접근을 한 번에 켜고 결정을 커널 대신 OpenVPN 에게 넘깁니다. 더 좁은 답은 그 스위치를 끈 채로 두고 서버 자체의 라우팅과 방화벽이 정확히 하나의 흐름을 나르게 합니다.

규칙 문구보다 동작 방식이 더 중요합니다. 두 접근은 패킷을 서로 다른 곳에 두기 때문입니다. 어느 쪽을 골랐는지 알면 아무것도 하지 않는 듯 보이는 규칙과 그것 없이 연결되는 피어를 모두 설명할 수 있습니다.

client-to-client이 패킷을 어디로 옮기는가

client-to-client 이 켜져 있으면 서버는 피어 패킷을 터널 장치로 다시 내보내지 않고 내부에서 전달하므로, 패킷이 커널의 전달 경로에 결코 도달하지 않습니다. 편리하지만 방화벽이 감시해야 할 흐름을 결코 보지 못한다는 뜻이기도 합니다. 옵션을 꺼 두면 서버가 패킷을 같은 인터페이스로 다시 내보내고, 이는 패킷을 netfilter 앞에 둡니다. 같은 인터페이스로 들어와 같은 인터페이스로 나가며, FORWARD 체인이 발언권을 가집니다.

맞바꿈은 분명합니다. 정책 지점 하나를 얻는 대신 지름길이 대신 해 주던 라우팅과 전달을 떠안습니다. 그 작업은 흐름 하나에는 작고 예외를 더할수록 커지므로, 예외를 지금 세어 보십시오. 피어 사이의 정책이 실제로 사는 곳이 규칙 집합이기 때문입니다.

피어 패킷이 실제로 지나는 경로

Linux Community OpenVPN 2.6 서비스, DCO 대신 사용자 공간의 TUN 처리, 서브넷 토폴로지, tun0, 그리고 클라이언트 A가 10.44.0.21, 클라이언트 B가 10.44.0.37 에 있는 10.44.0.0/24 풀을 가정합니다. 서브넷 토폴로지에서는 A가 받은 주소와 넷마스크가 이미 풀을 덮으므로, A는 추가로 밀어 넣은 경로 없이 터널 장치로 패킷을 보냅니다. A의 실제 경로를 가정하지 말고 확인하십시오.

서버에서는 패킷이 B로 주소 지정되어 도착하는데, 이는 로컬 주소가 아니므로 전달됩니다. 그러려면 IPv4 전달이 켜져 있어야 하고, 경로 조회는 패킷을 tun0 을 통해 다시 내보내야 합니다. 따라서 방화벽은 양쪽이 같은 인터페이스인 전달 흐름을 보게 되며, 이것이 대부분의 규칙 집합이 놓치는 세부입니다. 여기서는 출발지 변환이 필요 없고, A의 주소를 그대로 두는 것이 B가 자기 출발지 기반 규칙을 적용하게 해 줍니다.

서버의 규칙 두 개, 이 순서로

허용 전체는 전달, 쌍 예외, 터널 쌍에 대한 기본 드롭이라는 세 규칙이 나릅니다. 허용 규칙은 쌍과 서비스를 지목하므로 풀이 커져도 허용이 유지되며, 터널 간 트래픽에 대한 포괄적 거부보다 앞에 두십시오. 첫 일치가 이기기 때문입니다.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

그 명령들은 예시이며 호스트가 규칙을 영구 보관하는 방식에 속합니다. 실행 중 삽입은 다음 부팅에서 사라집니다. B의 응답과 TCP 핸드셰이크가 두 번째 대칭 허용 없이 돌아오게 하는 것은 상태 기반 규칙입니다.

나중에 확인할 것은 규칙 목록이 아니라 카운터입니다. 한 번도 일치하지 않는 규칙은 동작하는 규칙과 똑같이 보이기 때문입니다. 카운터가 영에 머문다면 패킷은 생각하는 경로로 가지 않습니다.

B가 여전히 허용해야 할 것

SSH 서비스를 돌리는 것은 B이므로, 터널 주소에서 무언가 듣고 있는지와 호스트 자체 방화벽이 출발지를 받아들이는지를 B가 정합니다. 서버의 네트워크 허용은 B의 어떤 계정에 대한 허가도 아니며, 호스트 키 검증과 사용자 인증은 다른 어디서와 마찬가지로 적용됩니다.

먼저 정상 사례로, A에서 B의 터널 주소로 가는 새 SSH 연결이 기대한 호스트 키로 받아들여지는지 시험하십시오. 다음으로 다른 피어나 다른 포트를 시험해 거부되는지 확인하십시오. 조용히 모든 것을 허용하는 허가는 중요한 순간이 오기 전까지 동작하는 허가와 구별되지 않기 때문입니다. 그 시험의 두 절반이 모두 필요하고, 사람들이 건너뛰는 쪽이 두 번째입니다.

할당된 주소, 두 클라이언트의 실제 경로, 서버와 B의 정확한 규칙을 기록하십시오. 게이트웨이로의 성공적인 ping이나 서버의 열린 포트는 이 중 아무것도 증명하지 못합니다. 피어 간 전달이 아직 막혀 있어도 둘 다 참일 수 있기 때문입니다. 재연결 후 주소가 다를 수 있으니, 그 숫자들은 터널이 올라와 있을 때 적으십시오.

관련 글