s2s VPN 연결을 통해 단방향 연결만 할 수 있는 경우 어떤 하위 시스템이 책임을 지게 됩니까?

s2s VPN 연결을 통해 단방향 연결만 할 수 있는 경우 어떤 하위 시스템이 책임을 지게 됩니까?

다음 s2s VPN(pfSense에서) 연결을 구성했는데 제대로 작동합니다.

여기에 이미지 설명을 입력하세요.

안타깝게도 클라이언트에서 서버로만 연결할 수 있고(ping, netcat, ssh) 다시 연결할 수는 없습니다.

정상적으로 ssh를 할 수 있다면 방화벽에는 문제가 없겠죠? 패키지가 양방향으로 배송되기 때문에?

명령줄 도구를 사용하여 문제를 진단하는 방법은 무엇입니까?


실수를 해서 netcat을 거꾸로 할 수 없었습니다. 하지만 서버에서 클라이언트에 핑을 보내면 패킷 캡처를 통해 클라이언트의 핑 트래픽을 볼 수 있습니다.

또한 명시적인 경로를 추가했습니다.

route add -net 192.168.31.0/24 192.168.27.2 

서버에서.


이것은 서버(.31.1) 또는 해당 네트워크 대응물(.31.155)에서 클라이언트를 ping할 때 클라이언트에 패킷을 덤프할 때 표시되는 내용입니다.

$ tcpdump -n -i ovpnc2 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpnc2, link-type NULL (BSD loopback), capture size 262144 bytes
20:04:44.123925 IP 192.168.27.1 > 192.168.31.1: ICMP echo request, id 14862, seq 0, length 64
20:04:45.133435 IP 192.168.27.1 > 192.168.31.1: ICMP echo request, id 14862, seq 1, length 64
20:04:46.146100 IP 192.168.27.1 > 192.168.31.1: ICMP echo request, id 14862, seq 2, length 64
20:04:49.664935 IP 192.168.27.1 > 192.168.31.155: ICMP echo request, id 1295, seq 0, length 64
20:04:50.663422 IP 192.168.27.1 > 192.168.31.155: ICMP echo request, id 1295, seq 1, length 64
20:04:51.679393 IP 192.168.27.1 > 192.168.31.155: ICMP echo request, id 1295, seq 2, length 64
20:04:52.688367 IP 192.168.27.1 > 192.168.31.155: ICMP echo request, id 1295, seq 3, length 64

클라이언트가 ping 패킷을 보았지만 응답하지 않는 것 같습니다. 그렇죠?

답변1

물론 방화벽은 SYN 플래그가 설정되어 있지만 ACK 플래그가 설정되지 않은 TCP 패킷을 한 방향으로만 전달하여 TCP 연결이 설정되는 방향을 제어할 수 있습니다.

일반적으로 SSH를 사용할 수 있다는 사실은 패킷이SYN 플래그가 전혀 없습니다.또는SYN 및 ACK 플래그가 모두 설정되었습니다.양방향 모두 허용됩니다. TCP 연결을 설정하려면 시스템은 TCP SYN 플래그가 설정되고 ACK 플래그가 설정되지 않은 상태로 패킷을 보내야 하며 방화벽은 이러한 패킷을 다른 패킷과 쉽게 구별할 수 있습니다.

핑은 TCP 패킷이 아닌 ICMP 패킷이므로 방화벽은 이에 대해 다른 규칙을 쉽게 설정할 수 있습니다. 또한 방화벽은 "ping 요청"에 대한 규칙 하나와 "ping 응답"에 대한 또 다른 규칙을 쉽게 설정할 수 있습니다.

관련 정보