पृष्ठभूमि, लंबे समय से हमें अपने फ़ायरवॉल के साथ समस्याएं हैं जो कभी-कभी HTTP अनुरोधों को आंशिक रूप से लोड किए गए टीसीपी समय तक लटकाए रखती हैं।
फ़ायरवॉल पर ट्रैफ़िक ट्रेस करने के बाद मैंने देखा कि यह केवल कुछ समय स्थितियों के दौरान होता है, उदाहरण के लिए जब वेबसर्वर ने ग्राहक को पेलोड पर अपना दूसरा एसीके भेजे जाने से पहले पूरी प्रतिक्रिया भेजी हो। [SYN, SYN / ACK, ACK] का आदान-प्रदान किया गया है, REQUEST भेजा गया है और ACK'ed और पहला RESPONSE पैकेट प्राप्त हुआ है और ACK'ed है, फिर वेबसर्वर एक शॉट (8 पैकेट) में शेष प्रतिक्रिया निकाय भेजता है अंतिम फिन, PSH सहित) और इससे पहले कि ग्राहक उनमें से किसी को भी ACK'ed कर लेता है, फ़ायरवॉल REJECTS एक RST के साथ वेबसर्वर की ओर जाता है और क्लाइंट को अनंत लटकाए रखता है।
यहाँ फ़ायरवॉल के दोनों ओर से पैकेट के साथ पूरा वायरशर्क ट्रेस है। 192.168.126.161 क्लाइंट का निजी NAT'et IP पता है। 172.16.1.2 वेबसर्वर आईपी (वास्तविक सार्वजनिक आईपी नहीं दिखाना) और 10.1.1.1 फ़ायरवॉल बाहरी आईपी (वास्तविक सार्वजनिक आईपी नहीं दिखाना) है
2105 0.086275 192.168.126.161 172.16.1.2 TCP 37854 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=89375083 TSER=0
2106 0.000066 10.1.1.1 172.16.1.2 TCP 37854 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=89375083 TSER=0
2107 0.002643 172.16.1.2 10.1.1.1 TCP http > 37854 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460
2108 0.007705 172.16.1.2 192.168.126.161 TCP http > 37854 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460
2109 0.006301 192.168.126.161 172.16.1.2 TCP 37854 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0
2110 0.000025 10.1.1.1 172.16.1.2 TCP 37854 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0
2111 0.000007 192.168.126.161 172.16.1.2 HTTP GET /test/style.css HTTP/1.1
2112 0.000015 10.1.1.1 172.16.1.2 HTTP GET /test/style.css HTTP/1.1
2113 0.001536 172.16.1.2 10.1.1.1 TCP http > 37854 [ACK] Seq=1 Ack=111 Win=32658 Len=0
2114 0.000014 172.16.1.2 192.168.126.161 TCP http > 37854 [ACK] Seq=1 Ack=111 Win=32658 Len=0
2115 0.002274 172.16.1.2 10.1.1.1 HTTP HTTP/1.1 200 OK (text/css)
2116 0.000025 172.16.1.2 192.168.126.161 HTTP HTTP/1.1 200 OK (text/css)
2117 0.005689 192.168.126.161 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=1461 Win=8760 Len=0
2118 0.000024 10.1.1.1 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=1461 Win=8760 Len=0
2119 0.001536 172.16.1.2 10.1.1.1 HTTP Continuation or non-HTTP traffic
2120 0.000026 172.16.1.2 192.168.126.161 HTTP Continuation or non-HTTP traffic
2121 0.000007 172.16.1.2 10.1.1.1 HTTP Continuation or non-HTTP traffic
2122 0.000023 172.16.1.2 192.168.126.161 HTTP Continuation or non-HTTP traffic
2123 0.000313 172.16.1.2 10.1.1.1 HTTP Continuation or non-HTTP traffic
2124 0.000030 172.16.1.2 192.168.126.161 HTTP Continuation or non-HTTP traffic
2125 0.000007 172.16.1.2 10.1.1.1 HTTP Continuation or non-HTTP traffic
2126 0.000023 172.16.1.2 192.168.126.161 HTTP Continuation or non-HTTP traffic
2127 0.000009 172.16.1.2 10.1.1.1 HTTP Continuation or non-HTTP traffic
2128 0.000023 172.16.1.2 192.168.126.161 HTTP Continuation or non-HTTP traffic
2129 0.001108 172.16.1.2 10.1.1.1 HTTP Continuation or non-HTTP traffic
2130 0.000035 172.16.1.2 192.168.126.161 HTTP Continuation or non-HTTP traffic
2131 0.000008 172.16.1.2 10.1.1.1 HTTP Continuation or non-HTTP traffic
2132 0.000022 172.16.1.2 192.168.126.161 HTTP Continuation or non-HTTP traffic
2133 0.000007 172.16.1.2 10.1.1.1 HTTP Continuation or non-HTTP traffic
REJECT-->
2134 0.000089 10.1.1.1 172.16.1.2 TCP 37854 > http [RST] Seq=111 Win=0 Len=0
CLIENT FIRST ACK-->
2135 0.002421 192.168.126.161 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=2921 Win=11680 Len=0
2136 0.000033 10.1.1.1 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=2921 Win=11680 Len=0
2137 0.000007 192.168.126.161 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=4381 Win=14600 Len=0
2138 0.000014 10.1.1.1 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=4381 Win=14600 Len=0
2139 0.000008 192.168.126.161 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=5841 Win=17520 Len=0
2140 0.000014 10.1.1.1 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=5841 Win=17520 Len=0
2141 0.000007 192.168.126.161 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=7301 Win=20440 Len=0
2142 0.000013 10.1.1.1 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=7301 Win=20440 Len=0
2143 0.000007 192.168.126.161 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=8761 Win=23360 Len=0
2144 0.000015 10.1.1.1 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=8761 Win=23360 Len=0
2145 0.000007 192.168.126.161 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=10221 Win=26280 Len=0
2146 0.000013 10.1.1.1 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=10221 Win=26280 Len=0
2147 0.001059 192.168.126.161 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=11681 Win=29200 Len=0
2148 0.000018 10.1.1.1 172.16.1.2 TCP 37854 > http [ACK] Seq=111 Ack=11681 Win=29200 Len=0
मैं इस चार्ट के अनुसार पैकेट ट्रैवर्स को खोदता और लॉग करता रहा हूं और ऐसा लगता है कि पिछले आने वाले पैकेट 2133 में कच्चे-PREROUTING, कॉनट्रैक, मैंगले-PREROUTING अतीत हो जाता है लेकिन फिर खो जाता है। मेरे iptables में कोई REJECT नियम नहीं हैं, मैं सभी DROP नियमों को लॉग करता हूं और उनमें से कोई भी नहीं दिखाता है कि पैकेट 2133 कहां खो जाता है।
मैं आने वाले फ़िल्टर पर TRACE के लक्ष्य का उपयोग करना पसंद करूंगा, लेकिन दुर्भाग्य से ubuntu 8.04 को TRACE लक्ष्य के समर्थन के साथ शिप नहीं किया गया है।
इसलिए मेरा मानना है कि कुछ आंतरिक निहित मार्ग / संबंध / प्रबंधन नियम किसी कारण से कनेक्शन को रीसेट करते हैं। हो सकता है कि ट्रैफ़िक कुछ डॉस सुरक्षा को ट्रिगर करता है, लेकिन मुझे पता नहीं है कि कहां कॉन्फ़िगर / विश्लेषण करना है। सबसे निराशाजनक बात यह है कि एक पैकेट खारिज कर दिया जाता है और कुछ भी लॉग नहीं होता है ...
इस फ़ाइल का अनुरोध भी विंडोज़ होस्ट से 100% काम करता है, लेकिन यह कुछ निश्चित लिनक्स होस्टों पर विफल रहता है और 99.9% सभी अनुरोध प्राप्त होते हैं, लेकिन कभी-कभी पैकेटों का समय हमारे फ़ायरवॉल में इस व्यवहार को ट्रिगर करता है।
संपादित करें ठीक है, अब मैंने iptables में बहुत सारे लॉगिंग जोड़ दिए हैं और ऐसा लगता है कि निम्नलिखित होता है (फिर भी न जाने क्यों!)
पैकेट के लिए फ़ायरवॉल को सफलतापूर्वक पार करने के लिए निम्नलिखित कदम उठाए गए हैं, तालिका / चरण संदर्भ यहाँ से
Table 3-3 step
2 raw-pre
conntrack
3 mangle-pre
4 [nat-pre]
5 routing-decision -> destination forward
6 mangle-fwd
7 filter-fwd
8 mangle-post
9 [nat-post]
पैकेट 2133 जो इन चरणों को खारिज कर देता है:
Table 3-1 steps for the incoming FIN,ACK packet 2133
2 raw-pre
conntrack
3 mangle-pre
4 [nat-pre]
5 routing-decision -> destination local
6 mangle-input
7 filter-input
8 local process emits RST -> webserver
Table 3-2 steps for the outgoing RST packet 2134 in response to 2133
1 raw-out
2 routing decision
conntrack
3 mangle-out
reroute-check
4 [nat-out]
5 filter-out
6 mangle-post
7 nat-post
अजीब बात यह है कि अब चरण 5 में पैकेट 2133 के लिए राउटिंग का निर्णय अन्य पैकेटों के रूटिंग निर्णय से अलग है। जब काम करने वाले अनुरोधों का विश्लेषण करते हैं, उदाहरण के लिए, अटक नहीं जाता है, यहां तक कि अंतिम फिन ठीक से रूट हो जाता है। यह कर्नेल में बग की तरह लगता है या यह कि रूटिंग निर्णय किसी तरह से स्टेटफुल होता है।
संपादित करें
एक चीज जो इन समस्याओं का कारण हो सकती है वह है निम्न तथ्य, यातायात फ़ायरवॉल और स्थानीय LAN के बीच रूट किया गया है, इसलिए क्लाइंट LAN L2 के माध्यम से सीधे फ़ायरवॉल से कनेक्ट नहीं है।
+---------------------------+ +------------------+ +------------------------+
| | | Router | ( Lab network ) | |
( Internet ) -- + eth1 eth0 +-------+ +-- ( ) -+ Client 192.168.126.161 |
| 10.1.1.1 192.168.60.254 | | | ( 192.168.126.0/24 ) | |
+---------------------------+ +------------------+ +------------------------+
इस चित्र में, 10.1.1.1 फ़ायरवॉल के बाहरी आईपी पते का प्रतिनिधित्व करता है, अन्य सभी पते उपयोग किए जाने वाले वास्तविक आईपी पते हैं।
यहाँ फ़ायरवॉल पर रूटिंग टेबल है:
Destination Gateway Genmask Flags Metric Ref Use Iface
10.1.1.0 0.0.0.0 255.255.255.240 U 0 0 0 eth1
192.168.126.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.60.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 10.1.1.15 0.0.0.0 UG 0 0 0 eth1
ध्यान दें कि 10.1.1.0 और डिफ़ॉल्ट gw 10.1.1.15 बनाये जाते हैं, बाकी बिल्कुल उपयोग के समान है। मुझे eth0 से लैब नेटवर्क तक पहुंचने के लिए 192.168.126.0/24 रूट को मैन्युअल रूप से जोड़ना पड़ा।
यहां अंतिम पैकेट 2133 के लिए पैकेट ट्रैवर्सल पर कुछ व्यापक लॉग हैं जो स्थानीय होस्ट (जैसे फ़ायरवॉल) में रूट किए जाने के कारण अस्वीकृत हो जाते हैं।
[16406874.374588] raw pre IN=eth1 OUT= MAC=00:02:b3:b9:ff:b5:00:90:1a:10:06:88:08:00 SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=13739 DF PROTO=TCP SPT=80 DPT=53497 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0
[16406874.374625] mangle pre IN=eth1 OUT= MAC=00:02:b3:b9:ff:b5:00:90:1a:10:06:88:08:00 SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=13739 DF PROTO=TCP SPT=80 DPT=53497 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0
[16406874.374667] mangle in IN=eth1 OUT= MAC=00:02:b3:b9:ff:b5:00:90:1a:10:06:88:08:00 SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=13739 DF PROTO=TCP SPT=80 DPT=53497 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0
[16406874.374699] filter in IN=eth1 OUT= MAC=00:02:b3:b9:ff:b5:00:90:1a:10:06:88:08:00 SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=13739 DF PROTO=TCP SPT=80 DPT=53497 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0
[16406874.374780] mangle out IN= OUT=eth1 SRC=10.1.1.1 DST=172.16.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=53497 DPT=80 WINDOW=0 RES=0x00 RST URGP=0
[16406874.374807] mangle post IN= OUT=eth1 SRC=10.1.1.1 DST=172.16.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=53497 DPT=80 WINDOW=0 RES=0x00 RST URGP=0
[16406874.378813] mangle pre IN=eth0 OUT= MAC=00:02:b3:b9:ff:b4:00:90:1a:10:0c:dd:08:00 SRC=192.168.126.161 DST=172.16.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=35424 DF PROTO=TCP SPT=53497 DPT=80 WINDOW=11680 RES=0x00 ACK URGP=0
[16406874.378863] mangle fwd IN=eth0 OUT=eth1 SRC=192.168.126.161 DST=172.16.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=62 ID=35424 DF PROTO=TCP SPT=53497 DPT=80 WINDOW=11680 RES=0x00 ACK URGP=0
एक बार फिर, हमारे fw बाहरी आईपी को 10.1.1.1 के साथ बदल दिया गया है और NAT'ed नेटवर्क के बाहर वेबसर्वर के आईपी को 172.16.1.2 के साथ बदल दिया गया है
EDIT ब्रेकिंग न्यूज़!
ठीक है आखिरी कोशिश आरएसटी पैकेट को ड्रॉप करने की थी, बहुत दिलचस्प है, मैंने एक iptables नियम जोड़ा है जो उन सभी आरएसटी पैकेटों को गिरा देता है जो वेबसर्वर को हमें समस्या होती है जिससे हमें फ़ाइलों का अनुरोध करना पड़ता है। और फिर इसने काम किया जैसे कि ऊपर के लॉग में अंतिम फिन, ACK, PSH पैकेट 2133 गिरा दिया गया है, लेकिन जब से RST गिराया गया है वेबसर्वर के पास सभी ACK के चींटी को प्राप्त करने का समय है, तो अंतिम पैकेट, पैकेट 2133 को एक बार फिर से वापस लेने का फैसला करता है, और अब यह फ़ायरवॉल के माध्यम से चला जाता है क्योंकि अब कंट्रैक मॉड्यूल ने ग्राहक से ACK को वापस आते हुए देखा है और अंतिम पेलोड के साथ अंतिम ACK, अंतिम पैकेट की अनुमति देता है।
तो यह निश्चित रूप से एक समय / खिड़की की समस्या है, यह विशेष फ़ाइल, क्लाइंट से ACK के समय के साथ, वेबरवेयर से अंतिम पैकेट को अस्वीकार करने वाले कंवर्टर में कुछ ट्रिगर करता है।
अब तक, कर्लिंग डॉक के प्रकट होने और पढ़ने से ऐसा कुछ भी नहीं होता है जो इस व्यवहार का कारण बन सकता है, अगला चरण रूटिंग / कन्वर्टर मॉड्यूल के लिए कर्नेल स्रोत कोड को पढ़ना होगा।
समस्या सुलझ गयी
ठीक है, कम से कम अब हम जानते हैं कि वास्तव में क्या होता है और समस्या को हल करने वाला एक समाधान है।
सेर्गेई ने बहुत ही मूल्यवान राज्य की ओर इशारा किया - स्टेट इनवेट मिलान नियम जिसने डिबगिंग में बहुत मदद की, मुझे अब पता चला है कि INVALID पैकेट के लिए एक स्पष्ट नियम के बिना एक iptables सेटअप पूरा नहीं होता है इसलिए कभी-कभी अजीब व्यवहार होता है।
अमान्य पैकेट का कारण क्या है, इसके लिए कॉन्ट्रास्ट मॉड्यूल में लॉगिंग को सक्षम करते समय, यह बहुत स्पष्ट होता है और मुझे इस बारे में संदेह था।
[16659529.322465] nf_ct_tcp: SEQ is over the upper bound (over the window of the receiver) IN= OUT= SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=40874 DF PROTO=TCP SPT=80 DPT=55498 SEQ=658735108 ACK=1194081763 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0
एक बार फिर, 172.16.1.2 बाहरी वेबसर्वर है (जो गलत व्यवहार करता है) और 10.1.1.1 फ़ायरवॉल का बाहरी पता है।
वेबसर्वर प्राप्त विंडो में क्लाइंट की तुलना में तार पर अधिक डेटा को धक्का देता है (यह स्थिति राज्य-पूर्ण है और इसे सत्यापित करता है), ऐसा लगता है कि यह तब होता है जब फिन पैकेट आता है कि प्राप्त खिड़की से कंसट्रक्शन बाहर निकल जाता है क्योंकि वास्तव में बहुत अधिक पार हो गया है पहले।
मेरा मानना है कि यह वेबसर्वर पर नेटवर्क कार्ड में गलत टीसीपी लोडिंग के कारण हो सकता है। जब मैंने इसका विश्लेषण करना शुरू किया तो मैंने वेबसर्वर पर कब्जा कर लिया और tcpdump / wirehark के निशान के अनुसार जंबो फ्रेम को कर्नेल में टीसीपी परत द्वारा लिखा गया था जो तब नेटवर्क कार्ड द्वारा MTU = 1500 के साथ छोटे फ्रेम में विभाजित किया गया था। इसलिए स्पष्ट रूप से इसे वेबसर्वर में एड्रैस करने की जरूरत है क्योंकि यह रिसीवर के डेटा को उसकी प्राप्त विंडो में भेजने से अधिक टीसीपी व्यवहार को सही नहीं करता है।
पॉलीओनोमियल और सेर्गेई दोनों ने मूल्यवान इनपुट प्रदान किया, लेकिन सेर्गेई ने पैकेट ट्रैवर्सल के बारे में मुझे कॉनट्रैक / एनएटी मॉड्यूल के सटीक व्यवहार की ओर इशारा किया।