이제 디버깅을 위해 무엇을 해야할지 모르겠습니다. 나는 몇 주 동안 이 문제를 해결하려고 노력해 왔지만 무슨 일이 일어나고 있는지 이해할 수 없습니다.
SSH 서버가 관리 서브넷의 연결만 처리하도록 하려고 하는데 이로 인해 모든 서브넷에서 관리 서브넷으로의 트래픽 라우팅이 차단되어서는 안 됩니다.
이것이 설정입니다. Debian 9에 가상 머신이 있습니다. 가상 머신에는 두 개의 인터페이스가 있습니다. eth0은 사용자 서브넷에 있고 eth1은 관리 서브넷에 있습니다. 두 서브넷 모두 pfsense라는 DHCP/DNS 서버를 가지고 있습니다. 호스트 이름이 자동으로 DNS에 추가됩니다.
내 sshd 구성 파일에는 기본적으로 켜져 있고 루트 로그인이 비활성화되어 있으며 ListenAddresseth1 IP로 설정되어 있습니다.
이것은 지금까지 내가 본 동작입니다.
두 인터페이스가 모두 활성화되어 ListenAddress활성화되었습니다.
- pfsense 라우터를 통한 사용자 네트워크의 SSH: 연결이 설정되고 짧은 시간 동안 작동한 후 터미널이 정지되고 시간 초과됩니다. Wireshark에서는 현재 일부 TCP 재전송이 있습니다.
- 관리 네트워크에서 직접 SSH를 사용하면 모든 것이 잘 작동합니다.
- 두 개의 네트워크가 있는 시스템에서 ssh를 사용하면 모든 것이 잘 작동합니다.
- 세 번째 네트워크의 ssh(사용자 네트워크에 대한 액세스를 거부하는 규칙): 모든 것이 잘 작동합니다.
두 인터페이스가 모두 작동 중이고 ListenAddress비활성화되어 있습니다.
- 모든 것이 잘 작동하지만 물론 사용자 네트워크 인터페이스를 통해 SSH를 사용할 수도 있습니다.
인터페이스 eth0이 다운되어 ListenAddress활성화되었습니다.
- 모든 것이 정상입니다
서버에는 의도적으로 방화벽이 없습니다. 호스트 이름 대신 IP 주소를 사용하여 ssh를 사용하지만 두 인터페이스 모두 호스트 이름이 동일하거나 다르더라도 동일한 결과를 얻습니다.
문제가 어디서 오는지 정말 모르겠습니다. 나에게는 pfsense가 될 수 없습니다. 이제 사용자 네트워크에서 관리 네트워크로의 모든 네트워크 트래픽을 허용하기 때문입니다. 하지만 아마도 내가 틀렸을 수도 있습니다. sshd 로그에도 오류가 없습니다.
답변1
문제는 서버에서 보낸 TCP 패킷이 보낸 TCP 패킷과 다른 경로를 사용하고 pfsense가 연결이 아직 설정되지 않았다고 생각하고 설정된 연결 테이블에서 해당 패킷을 제거한 다음 들어오는 연결을 거부한다는 것입니다. 데이터 패킷.
사용자 네트워크의 컴퓨터에서 서버로 전송된 TCP 패킷은 pfsense 라우터로 전송되어 SSH 서버로 전달됩니다. SSH 서버에는 사용자 네트워크의 인터페이스가 있으므로 반환 패킷은 사용자 네트워크의 인터페이스를 통해 컴퓨터로 직접 전송됩니다. 따라서 pfsense는 귀하의 컴퓨터에서 서버로의 패킷만 보고 첫 번째 TCP SYN 프레임이 아직 승인되지 않았으므로 잠시 후에 연결이 끊어진 것으로 판단하고 후속 패킷을 삭제합니다.
pfsense의 빠른 해결 방법은 사용자 네트워크에서 관리 네트워크로 SSH 패킷을 SNAT하는 것입니다. 따라서 ssh 서버는 pfsense를 반환 경로로 사용합니다. 물론 SSH 서버는 실제 소스 주소를 알 수 없습니다.
더 나은 접근 방식은 소스 기반 라우팅을 사용하는 것입니다. 바라보다이 문제예를 들어.