linux 의 ipconntrack 헷 갈 리 기 쉬 운 문제

마지막 질문conntrack 는 이벤트 메커니즘 이 있어 서 ip 를 주동 적 으로 통보 할 수 있 습 니 다.conntrack 의 일부 사건 은 추적 정보 만 료 삭제 등 사건 을 포함 하여 누구 에 게 알려 줍 니까?물론 모든 관심 있 는 모듈 에 알 렸 습 니 다. 그 중 하 나 는 사용자 상태 프로 세 스 입 니 다. 그러면 사용자 상태 프로 세 스 는 방화벽 에 놓 친 규칙 을 설정 하 는 등 조 치 를 취 할 수 있다 는 것 을 알 게 되 었 습 니 다. 이 알림 체 제 는 관찰자 디자인 모델 을 사 용 했 습 니 다.
Linux ip_conntrack 의 세부 적 인 문 제 는 Linux 의 ipconntrack 은 대량의 상 태 를 가지 고 있 으 며, 모든 상 태 는 일정한 시간 초과 가 있 습 니 다. 이러한 상태 에서 개별 상 태 는 네트워크 프로 토 콜 의 서로 다른 상태 와 매 핑 관 계 를 맺 을 수 있 고, 다른 일 부 는 할 수 없습니다.만약 에 협의 자체 가 상태 가 있다 면 매 핑 관 계 를 구축 하 는 데 편리 하고 반대로 협의 가 상태 가 없 으 면 매 핑 관 계 를 구축 할 수 없다.때로는 무상 태 프로 토 콜 에 대해 ipconntrack 의 상태 시간 초과 가 답답 한 문 제 를 가 져 올 수 있 습 니 다.
    아무튼 리 눅 스 의 ipconntrack 체 제 를 깊이 연구 하면 정말 볼 만 한 것 이 고 방화벽 개발 을 하면 조사 하지 않 을 수 없다.다음은 몇 가지 예 를 들 겠 습 니 다.
예 를 들다
예 1: UDP 의 경우 그 자체 가 상태 가 없고 연결 을 만 들 필요 가 없고 확인 할 필요 가 없 으 며 순 전 히 데이터 보고 프로 토 콜 이기 때문에 ipconntrack 은 경험 치 를 사용 하여 각 상태의 시간 초과 시간 을 설정 합 니 다. 그러나 쌍방 이 한 동안 가방 을 보 내지 않 았 다 면 초기 수신 단 이 패 킷 을 다시 시작 할 때 방화벽 에 있 는 ctstate 기반 여과 규칙 에 영향 을 줄 것 입 니 다. 구체 적 으로 는 을 참조 하 십시오.
예 2: UDP 의 경우 Linux 방화벽 에 NAT 를 사용 하면 데이터 통신 기간 에 NAT 규칙 이 삭제 되 거나 수정 되 더 라 도 이 데이터 흐름 은 규칙 을 사용 하지 않 거나 새로운 규칙 을 사용 하지 않 는 오래된 NAT 규칙 을 사용 합 니 다.
예 3: 초기 커 널 에 ip 불 러 오기conntrack 모듈, 그리고 ping 이 통 하 는 주 소 는 / proc / net / ip 에 있 습 니 다.conntrack 에 서 는 이 연결 의 추적 정 보 를 볼 수 없 으 며, ping 은 전혀 접근 할 수 없 는 주소 로 오히려 반대 방향 으로 UNREPLY 의 추적 정 보 를 볼 수 있 습 니 다.주의해 야 할 것 은 적어도 2.6.32 커 널 에 서 는 이 문제 가 존재 하지 않 고 2.6.9 커 널 에 존재 한 다 는 점 이다. 구체 적 으로 어떤 버 전이 수정 되 었 는 지 커 널 의 ChangeLog 를 자세히 보지 않 았 다.
예 4: TCP 의 경우 하나의 연결 만 끊 기 면 / proc / net / ipconntrack 에서 이 연결 에 대한 추적 정 보 는 UDP 처럼 보존 되 지 않 고 곧 삭 제 됩 니 다.
이상 의 문제 에 대한 해석
예 1 의 해석: 이것 은 할 말 이 없다. 근본 적 인 원인 은 UDP 자체 가 상태 가 없고 ip 이다.conntrack 은 established 상 태 를 UDP 연결 에 강 요 했 습 니 다. 이른바 ipconntrack 의 established 상 태 는 모든 협의 에 대해 돌아 가 는 흐름 이 있다 고 말 합 니 다. 물론 UDP 에 대해 서 는 더욱 그렇습니다.TCP 에 있어 ipconntrack 은 syn 상태 가 아 닌 데 이 터 를 모두 establid 상태 로 비 추 었 습 니 다 (TCP 의 establid 상태 가 아 닌 것 을 주의 하 십시오). 이것 도 상기 정의 에 부합 합 니 다.ip 에서conntrack 처리 입구 의 마지막:
setreply 는 정말 ct 의 상태 위 치 를 수정 할 것 이 고 setreply ipconntrack_in 의 resolvenormal_ct 호출 중 설정 되 어 있 습 니 다.
이 로 인해 IPCT_ESTABLISHED 상 태 는 구체 적 인 협의 와 무관 합 니 다. TCP 의 경우 모든 SYN 뒤의 가방 은 IP 입 니 다.CT_ESTABLISHED 상태.그러나 TCP 자체 가 연결 을 감시 할 수 있 는 상 태 를 가지 고 있 기 때문에 close - wait 등 은 ipconntrack 에 또 일부 하위 상태 가 있 습 니 다. 이것 은 적당 한 시기 에 ip 를 방출 하 는 데 사 용 됩 니 다.conntrack 데이터 구조, 따라서 TCP 의 ip 만 있 으 면conntrack 의 time - wait 서브 상태 만 료, ipconntrack 데이터 구 조 는 즉시 방출 됩 니 다. 이 모든 것 은 TCP 가 프로 토 콜 상 태 를 ip 로 매 핑 했 기 때 문 입 니 다.conntrack 의 하위 상태, 이 하위 상 태 는 언제 tcp 흐름 이 끝 났 는 지 알 고 있 습 니 다.그러나 이 모든 것 은 UDP 와 ICMP 에 있어 서 이렇게 운 이 좋 지 않 습 니 다. 이들 은 하위 상태 가 아니 라 대담 한 ip 만 사용 할 수 있 습 니 다.conntrack 상태.
예 2 의 설명: Linux 의 iptables / netfilter 가 실현 하 는 NAT 는 상태 NAT 입 니 다. 하나의 스 트림 의 헤드 백 에 만 NAT 표를 조회 하고 검색 결 과 를 이 스 트림 에 속 하 는 ip 에 설정 합 니 다.conntrack 데이터 구조 에서 하나의 스 트림 패키지 이후 의 모든 패 킷 은 이 결 과 를 사용 합 니 다.게다가 UDP 상태 없 음, ipconntrack 은 estables 상태 가 만 료 될 때 까지 기다 리 지 않 으 면 방출 할 수 없습니다. (사실 UDP 흐름 이 언제 끝 날 지 모 르 고 estables 의 만 료 시간 도 경험 치 입 니 다) ipconntrack 데이터 구 조 는 이 데이터 구 조 를 방출 하지 않 는 이상 헤드 백 에 저 장 된 NAT 결과 가 계속 유효 하기 때문에 이러한 문제 가 발생 할 수 있 습 니 다.ICMP 에 있어 서 는 특이 하고 커 널 버 전이 다 르 며 이것 이 예 3 의 상황 이다.
예 3 의 해석: 2.6.9 의 커 널 에서 icmp패 킷 은 다음 과 같 습 니 다:
이 함 수 는 ipconntrack_in 반전.실제로 모든 프로 토 콜 에 이러한 리 셋 함수 가 있 는데 이름 은 packet 이 고 이 리 셋 함수 처리 와 프로 토 콜 과 관련 된 내용 입 니 다. 예 를 들 어 TCP 에 있어 서 는 처리 서브 상태 입 니 다.
    위의 코드 분석 을 보고 우 리 는 ping 이 통 하 는 주소 에 대해 알 게 되 었 습 니 다. 가방 이 빨리 도착 하기 때문에 ip 를 제거 할 수 있 습 니 다.conntrack 데이터 구조, 그러나 인용 계수 가 점차 줄 어 든 후 0 이 되 지 않 아 방출 되 지 않 으 면 filter 표 의 - state 판단 에 영향 을 주지 않 습 니 다. 그러나 관련 skb 가 커 널 을 떠 나 면 skb 를 방출 하여 1 후의 ip 을 점차 줄 입 니 다.conntrack 인용 계수 가 0 으로 풀 려 났 습 니 다. 연결 추적 데이터 구조 가 곧 풀 려 났 습 니 다. 이것 이 바로 저 버 전 (2.6.9 포함) 커 널 의 방법 입 니 다. 따라서 ping 이 통 할 때 연결 추적 정보 가 빨리 풀 려 나 기 어렵 습 니 다. / proc / net / ipconntrack 에서 이 를 보 았 습 니 다. ping 이 도달 할 수 없 는 주 소 를 가지 고 있 을 때 가방 을 되 돌려 주지 않 았 기 때문에 연결 추적 정 보 는 오히려 보 여 집 니 다. 가방 을 되 돌려 주 는 상 태 는 NOREPLEY 이지 만.
    지금 생각해 보면 리 눅 스 커 널 이 ICMP 를 UDP 처럼 대하 지 않 는 이 유 는 무엇 일 까? 그들 은 모두 같은 부류 이기 때문에 IP 위 에 직접 운전 하고 연결 되 지 않 으 며 확인 되 지 않 으 며 상태 가 없 는데 왜 다 를 까?UDP 는 어쨌든 양 방향 또는 단 방향 통신 을 나타 내 는데 ICMP 는 하나의 소식 을 전달 하 는 것 일 뿐 입 니 다. 일반적으로 ICMP 가 장시간 통신 흐름 을 차지 하지 않 고 왔 다 갔다 하 는 것 과 같은 것 이 있 습 니 다. 이것 이 바로 그들의 본질 적 인 차이 입 니 다. 그래서 ICMP 에 대해 한 번 왔 다 갔다 하면 연결 추적 정보 도 삭 제 됩 니 다.이것 은 매우 합 리 적 이 고 나 쁘 지 않 은 것 같 지만 긴 ping 에 대한 처 리 를 보 세 요. 긴 ping, ipconntrack 은 연결 추적 을 계속 삭제 하고 새로운 연결 추적 을 만 들 려 고 합 니 다. 이렇게 반복 하면 대량의 CPU 자원 을 소모 합 니 다. 보아하니 ipconntrack 은 ICMP 의 방법 은 정적 공간의 최적화 에 유리 합 니 다. 즉, 메모리 공간의 점용 을 최소 화 했 지만 CPU 시간의 점용 을 최대 화 했 습 니 다. 메모리 가 이렇게 저렴 한 오늘날 에 의미 가 있 습 니까?어쨌든 높 은 버 전이 반대 방향 으로 바 뀌 었 다 는 점 에서 높 은 버 전의 커 널 은 또 다른 최적화 를 제시 했다. 그것 은 바로 CPU 시간 에 대한 최적화 이 고 결국은 UDP 와 같은 처리 방식 으로 분류 되 어 ICMP 시간 초과 시간 을 설정 했다.
    적어도 2.6.32 버 전의 커 널 에서 ipconntrack 은 더 이상 2.6.9 커 널 과 같이 ICMP 를 처리 하지 않 고 UDP 와 같이 처리 합 니 다.
예 4 의 해석: 예 1 의 해석 을 통 해 나 는 이것 이 이미 이해 하기 어렵 지 않다 고 생각한다.
리 눅 스 ip 정리conntrack 메커니즘 은 상 태 를 바탕 으로 하 는 설정 전략의 초석 입 니 다. 상 태 는 경험 측정 의 시간 초과 시간 을 바탕 으로 합 니 다. 이 시간 이 지나 면 해당 하 는 연결 추적 정 보 를 삭제 합 니 다.이른바 리 눅 스 의 '상태 기반' 이다.그러나 네트워크 프로 토 콜 의 상태 가 반드시 ip 와 같 을 수 있 는 것 은 아니다.conntrack 의 상 태 는 일일이 맞 출 수 있 기 때문에 ipconntrack 은 상태의 의 미 를 스스로 정의 해 야 합 니 다.
    본질 적 으로 ipconntrack 은 두 가지 프로 토 콜 에 대응 해 야 합 니 다. 하 나 는 연결 이 있 는 프로 토 콜 이 고 하 나 는 연결 이 없 는 프로 토 콜 입 니 다.연 결 된 프로 토 콜 에 대해 서 는 프로 토 콜 자체 가 언제 연결 을 철거 할 지 알 고 있 기 때문에 ipconntrack 도 언제 ip 를 삭제 할 지 알 수 있 습 니 다.conntrack 데이터 구조, 그러나 연결 되 지 않 은 프로 토 콜 에 대해 프로 토 콜 자체 가 언제 하나의 흐름 을 끝 낼 지 모 르 기 때문에 ipconntrack 도 경험 치 에 따라 추산 할 수 밖 에 없다.특히 주의해 야 할 것 은 ip 때문에conntrack 은 전 과정 에 모니터링 이 없 기 때문에 TCP 와 같은 연 결 된 프로 토 콜 에 있어 서 특정한 상태 가 변 하지 않 을 때 ipconntrack 은 이 상 태 를 언제 떠 날 지 알 수 없 기 때문에 TCP 와 같은 상태 있 는 프로 토 콜 에 있어 특정한 프로 토 콜 상태 (ip conntrack 서브 상태) 에서 그 행 위 는 상태 가 없 는 UDP 와 같은 프로 토 콜 과 똑 같 습 니 다. 예 를 들 어 TCP 의 established 설정 이 5 일 이면 충분 하지만 5 일이 넘 으 면 데 이 터 를 전송 하지 않 습 니 다.그리고 반대 방향 으로 데 이 터 를 주동 적 으로 전송 하 는 경우 도 존재 한다.