IP fragmentation될때 패킷의 순서가 뒤바뀌는 현상...
글쓴이: albamc / 작성시간: 금, 2004/11/26 - 4:47오후
안녕하세요...
제목이 좀 애매모호한데 ... 자세히 설명을 드리면...
MTU가 1500인 network에서 1500 byte의 packet을 전송하면
IP에서 패킷이 fragmentation되어
IP 헤더와 1480byte인 패킷과 20byte인 패킷 두개로
나뉘어서 전송되게 됩니다.
kernel 2.4.18에서 전송한 결과 20byte패킷이 먼저 전송되고
1480 byte 패킷이 전송되며
kernel 2.6.5-358 (fedora core2) 에서는 1480 패킷이 전송되고
20byte 패킷이 전송되네요.
kernel 2.4.18의 경우에도 문제가 없어야 하지만
패킷이 외부로 전송될 경우 NAT에서 처리를 못하는듯 보입니다.
kernel 2.4대에서 이 문제를 해결하려면 어찌해야 할지 모르겠어서
질문 올립니다...
Forums:
Re: IP fragmentation될때 패킷의 순서가 뒤바뀌는 현상...
지극히 정상입니다.
다 받은 다음 처리하시면 될듯.
음... 문제는 이렇게 순서가 바뀐 패킷의 경우 방화벽을 통과하지 못하더
음... 문제는 이렇게 순서가 바뀐 패킷의 경우 방화벽을 통과하지 못하더군요.
그래서 질문을 올렸던 것이구요.
NAT는 제가 손댈수 없는 상황이거든요.
물론 순서를 바꿔 보내는것도 정상입니다...
커널 2.4에서는 뒤집어서 보내는데 그 부분의 주석에서
그렇게 보내는것이 받는쪽에서 효율적이기 때문에 그런다더군요.
커널 2.6에서는 순서대로 보냅니다...
그럼 좋은 하루 되시구요 ~
[quote="Anonymous"]음... 문제는 이렇게 순서가 바뀐 패
방화벽이 좀 이상하군요.
정책상 fragmented packet 을 통과 안 시키면 안 시키지 순서 바뀌었다고 drop 시키는 것은 또 뭐죠?
그렇다면 다 받은 뒤 순서를 바꿔 볼 수도 있겠네요.
근데 과연 순서대로 보냈다고 순서대로 다 받을까요?
IP protocol은 순서를 보장하지 않습니다.
[quote="경"][quote="Anonymous"]음... 문제는 이
예전에 비슷한 경험을 한 적이 있습니다.
재미있는것은 리눅스만 이러한 현상을 보이며
버전에 따라 또 그 형태가 다르다는 것입니다.
*BSD에선 이러한 증상이 없었습니다.
그러므로 서버의 커널 버전을 변경해보는 것이 좋을듯 싶습니다.
그리고 Fragmentation 된 패킷의 마지막 패킷이 먼저 전송될 경우
방화벽에서 해당 패킷을 block 시키는 것이 당연합니다.
방화벽 입장에선 첫번째 Fragmentation 패킷을 수신해야
나머지 패킷들에 대한 정보를 얻을 수 있기 때문이지요.
일반적으로 호스트의 경우 Fragmentaion 된 패킷을 모두 수신하고
재조합을 거친 후 정상적일 경우 상위 프로토콜로 전송합니다.
그러나 대부분의 방화벽의 경우 바로 forwarding을 합니다. 대신
fragmentation session을 생성하여
나머지 패킷들에 대한 정보를 방화벽 내에 갖고 있는 형태를 취합니다.
不狂不及
[quote]그리고 Fragmentation 된 패킷의 마지막 패킷이
그렇지 않습니다.
이미 얘기 했듯이 routing 된 패킷이 순서대로 온다는 보장이 없습니다.
offset 0이 아닌 fragmented packet 은그냥 통과 시켜도 상관 없는 것이
방화벽이 offset 이 0인 것만 보고 drop을 시키면 host에서 reassembly
할 수 없기 때문입니다. 방화벽에서 갖고 있다가 첫째 fragment가 왔을 때
모든 fragment에 적용할 수도 있겠지만 비효율적인 것 같습니다.
block 이란 의미가 잠시 방화벽이 갖고 있는 다는 얘기 였습니까?
그렇다면 말이 되지요. 그러나 위에서 얘기 했듯이 그냥 통과 시키는 것이
성능상 나을 듯 합니다. 방화벽이 header말고 data 까지 본다면 물론
조합해서 다 봐야 겠지요.
[quote="경"][quote]그리고 Fragmentation 된
IPFilter의 경우 Frag offset이 0이 아닌 경우
frag session을 검사합니다.
frag offset이 0이고 MF이 1인 경우, 즉, 첫번째 fragmentation pkt은
룰 검사를 수행하고 pass 룰일 경우 frag session을 생성합니다.
offset이 0이 아닌경우 frag session에 등록된 패킷인 경우만 통과시킵니다.
Src & Dst IP, IPID와 Offset, len 등을 참고합니다.
방화벽에서 재조합을 지원하는 경우는 드문 일입니다.
대신 fragmentation session를 지원하지요.
(PF는 옵션 형태로 재조합 후 룰 검사를 수행하는 기능이 있는걸로 압니다.)
그러므로 frag된 마지막 패킷이 먼저 도착할 경우
frag 세션에 없는 패킷으로 판단되므로 block 됩니다.
물론 IP Offset이 0 이 아닌 경우 그냥 통과시키고
첫번째 frag 패킷만으로 룰 검사를 수행하게 할 수도 있습니다.
그러나 보안 문제로 대부분 허용하지 않고 있습니다.
不狂不及
[quote]IPFilter의 경우 Frag offset이 0이 아닌
fragment cache 를 얘기하는 것 같군요.
openbsd 2.8 ipfr_lookup에서 제가 확인한 결과는 src, dst, ipid, tos입니다.
제가 해석한 대로라면 이 말은 모순됩니다.
방화벽에서 재조합은 지원하는 것이 드물다는 것은 제가 말한 대로입니다.
이것을 확인하는 것은 간단합니다. hping 같은 유틸에서 offset 을 주어서
패킷을 한 번 보내 보세요. 제가 생각할 때 RFC를 잘 해석했다면 받아야 합
니다. ipfilter에서 fragments 막는 rule이 분명히 들어있지 않다면요.
ipfilter 소스 어디에서 drop 시키는 지 확인해 줄 수 있는지요?
필터가 fragmented 패킷을 drop 시키면 문제가 굉장히 커질 여지가 많습니다.
RFC에 의하면 분명 routing 된 패킷이 순서대로 온다고 보장하지 않습니다.
마지막 패킷이 먼저 도착했을 때 drop 시키 버리면 온전한 datagram을 받을
수 없기 때문에 보낸 쪽에서는 전체 패킷을 다시 보내야 하는 것입니다.
댓글 달기