
나는 다음과 같은 구성을 가지고 있습니다 :
LAN 01: 192.168.16.0/24 (LAN for internal servers)
LAN 02: 192.168.67.0/24 (LAN for workstations)
WAN: X.X.X.X
그런 다음:
PFSENSE LAN IP: 192.168.16.1
PFSENSE LAN IP: 192.168.67.1 (it's a virtual IP)
랜 01그리고랜 02물리적으로 연결되어 있습니다(즉, 동일한 스위치에 있습니다. 별도의 LAN이나 최소한 VLAN을 사용해야 한다는 것을 알고 있지만 지금은 이 구성을 쉽게 변경할 수 없습니다).
컴퓨터가 있는 곳에서 작동하는 PFSENSE 설치(2.2)가 있습니다.랜 02DHCP 서버에서 IP 주소를 가져오고 PFSENSE를 기본 게이트웨이로 사용합니다.
내 문제는 다음과 같습니다.
내가 컴퓨터에 앉아 있으면랜 02그리고 나는 다음 위치에 있는 서버에 ssh(또는 해당 문제에 대한 다른 영구 프로토콜)를 연결합니다.랜 01이와 같이:
$ ssh -l myself 192.168.16.25
저는 문제없이 연결합니다. 연결은 20~30초 정도 지속되다가 지속적으로 끊어집니다.
그래서 내 질문은 다음과 같습니다연결이 끊어지지 않도록 하려면 어떻게 해야 합니까?
양쪽에서 tcpdump를 수행했는데 어느 시점에서 패킷이 복제되기 시작했습니다. 다음과 같습니다:
도움이 될 것이라고 생각한 이 옵션을 활성화했지만 그렇지 않았습니다.
LINUX FIREWALL(iptables)을 사용하면 이와 똑같은 구성이 완벽하게 작동한다는 점을 언급하고 싶습니다.
어떤 아이디어가 있나요?
답변1
캡처 결과 하나는 192.168.16.0이고 다른 하나는 192.168.67.0인 것으로 나타나므로 LAN1과 LAN2 목록이 모두 192.168.1.0/24로 잘못되었다고 추측합니다. 둘 다 /24가 되기를 바랍니다.
여기서는 정적 경로 필터링 옵션을 적용할 수 없습니다.
네트워크가 겹치거나(둘 다 /24 마스크가 아니고 일부 호스트에서는 /16일 수도 있음) 영향을 받는 시스템 중 하나가 두 네트워크에 이중 홈이 있어 비대칭 라우팅이 발생하는 것 같습니다.
답변2
나는 매우 비슷한 문제가 있었고 문제는 본질적으로 비대칭 라우팅의 변형이었습니다.
내 토폴로지에는 2개의 LAN 인터페이스(둘 다 /24이지만 확실히 다른 서브넷)가 있는 PFSENSE 상자가 있습니다. 그런 다음 두 인터페이스를 서로 다른 VLAN의 나머지 네트워크에 연결하는 L2\L3 스위치가 있습니다. 또한 이 스위치에는 유선 사용자와 모든 무선 사용자가 포함된 세그먼트가 있습니다. 유선 사용자는 하나의 서브넷\VLAN에 있고 무선은 다른 서브넷에 있으며, 이 두 서브넷은 모두 PFSENSE 상자에 존재합니다. 모든 엔드포인트는 해당 서브넷의 PFSENSE IP를 DG로 사용합니다. 마지막으로 스위치에는 앞서 언급한 두 서브넷 모두에 IP가 있습니다.
내 문제는 무선을 통해 연결하고 SSH로 스위치에 연결하면 제대로 연결되었다가 20~30초 안에 연결이 끊어진다는 것이었습니다. 이미 알고 계시겠지만, 스위치는 내 컴퓨터와 동일한 서브넷에 IP를 갖고 있기 때문에 스위치에서 반환되는 패킷은 내 컴퓨터에서 오는 패킷과 동일한 경로를 따르지 않고 내 컴퓨터로 직접 이동합니다. 스위치는 기본적으로 PFSENSE 상자를 우회합니다.
많은 상황에서 이는 특히 비상태 저장 중개자 및/또는 UDP 세션에 대해 실제로 잘 작동할 수 있습니다. 그러나 PFSENSE 상자는 상태 저장 장치이므로 몇 초 후에 PFSENSE는 TCP OPEN에 대한 응답을 확인하지 못하고 결국 상태를 종료합니다. 확인하려면 PFSENSE의 TCP OPEN 시간 초과 값(시스템 --> 고급 --> 상태 시간 초과)을 조정한 다음 SSH 세션이 삭제되는 데 걸리는 시간이 설정한 값을 따르는지 관찰할 수 있습니다. 이 값의 기본값은 예상대로 30초입니다. 스위치(BAM)에서 관련 IP를 제거하면 문제가 해결되었습니다.
OP의 설명된 토폴로지에서 구체적으로 언급되지는 않았지만 관련 엔드포인트 간에 스위치(또는 유사한)가 있을 수 있다고 생각됩니다. 아닐 수도 있지만 만약 그렇다면 그것은 내가 여기서 겪었던 것과 같은 문제일 수 있습니다. 또는 OP의 topo에 있는 서버가 이중 홈인 경우 이 문제가 발생합니다.