পটভূমি, দীর্ঘদিন ধরে আমাদের ফায়ারওয়াল নিয়ে আমাদের সমস্যা ছিল যা কখনও কখনও এইচটিটিপি অনুরোধগুলিকে টিসিপি সময় শেষ না হওয়া পর্যন্ত আংশিকভাবে লোড করে রাখে।
ফায়ারওয়ালে ট্র্যাফিক ট্র্যাক করার পরে আমি লক্ষ্য করেছি যে এটি কেবলমাত্র নির্দিষ্ট সময়কালের মধ্যে ঘটে থাকে, যেমন যখন ক্লায়েন্টটি পেলোডে ক্লায়েন্টের দ্বিতীয় এসিকে প্রেরণের আগে ওয়েবসভার পুরো প্রতিক্রিয়াটি প্রেরণ করে। [SYN, SYN / ACK, ACK] বিনিময় করা হয়েছে, অনুরোধটি প্রেরণ করা হয়েছে এবং ACK'ed এবং প্রথম RESPONSE প্যাকেটটি পেয়েছে এবং ACK'ed, তারপরে ওয়েবসার্কর বাকী অংশটি একটি শটে প্রেরণ করে (8 টি প্যাকেট) সর্বশেষ এফআইএন, পিএসএইচ সহ) এবং ক্লায়েন্টটি তাদের যে কোনও একটি করার আগে ফায়ারওয়াল ওয়েবসারভারের দিকে আরএসটি দিয়ে প্রত্যাখ্যান করে এবং ক্লায়েন্টকে অসীম ঝুলিয়ে রাখে।
ফায়ারওয়ালের উভয় দিকের প্যাকেট সহ পুরো ওয়্যারশার্ক ট্রেস এখানে। 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 কাঁচা-প্রেরোটিং, কনট্র্যাক, ম্যাঙ্গেল-প্রিটারিং পেয়েছে তবে তার পরে হারিয়ে গেছে। আমার আইপেটেবলগুলিতে আমার কোনও প্রত্যাখ্যানের নিয়ম নেই, আমি সমস্ত ড্রপ বিধি লগ করেছি এবং 21213 প্যাকেটটি কোথায় হারিয়ে যায় সেগুলির কোনওটিই দেখায় না।
আমি আগত ফিল্টারে ট্র্যাক লক্ষ্যটি ব্যবহার করতে পছন্দ করব তবে দুর্ভাগ্যক্রমে উবুন্টু 8.04 ট্র্যাক টার্গেটের জন্য সমর্থন সহ প্রেরণ করা হয়নি।
সুতরাং আমি বিশ্বাস করি যে কিছু অভ্যন্তরীণ অন্তর্নিহিত রুটিং / কনট্র্যাক / ম্যাংলিং বিধি প্রয়োগ করে যে কোনও কারণে সংযোগটি পুনরায় সেট করে। ট্র্যাফিক কিছু ডস সুরক্ষা ট্রিগার করতে পারে, তবে এটি কোথায় কনফিগার / বিশ্লেষণ করবেন তা আমার কোনও ধারণা নেই। সবচেয়ে হতাশার বিষয় হ'ল একটি প্যাকেট প্রত্যাখ্যান করা হয় এবং কিছুই লগ হয় না ...
উইন্ডোজ হোস্টগুলি থেকে এই ফাইলটি অনুরোধ করা 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
আশ্চর্যের বিষয়টি হ'ল পঞ্চম ধাপে 2133 প্যাকেটের জন্য রাউটিংয়ের সিদ্ধান্তটি অন্যান্য প্যাকেটের রাউটিং সিদ্ধান্তের চেয়ে আলাদা। যে অনুরোধগুলি কার্যকর হয় তা বিশ্লেষণ করার সময়, যেমন আটকে যায় না, এমনকি সর্বশেষ এফআইএন সঠিকভাবে রুট হয়ে যায়। এটি কার্নেলের ত্রুটির মতো মনে হয় বা রাউটিংয়ের সিদ্ধান্তটি কোনওভাবেই রাষ্ট্রীয়।
সম্পাদনা
এই সমস্যাগুলির কারণ হতে পারে এমন একটি বিষয় হ'ল নিম্নলিখিত সত্য, ট্র্যাফিকটি ফায়ারওয়াল এবং স্থানীয় ল্যানের মধ্যে রুট করা হয়, তাই ক্লায়েন্ট ল্যান সরাসরি এল 2 এর মাধ্যমে ফায়ারওয়ালের সাথে সংযুক্ত থাকে না।
+---------------------------+ +------------------+ +------------------------+
| | | 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 আপ তৈরি করা হয়েছে, বাকী ব্যবহারের মতো হ'ল। আমি এথ0 (192.168.60.254) থেকে ল্যাব নেটওয়ার্কে পৌঁছানোর জন্য আমাকে 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 দ্বারা প্রতিস্থাপন করা হয়েছে
এডিট ব্রেকিং নিউজ!
ঠিক আছে শেষ চেষ্টাটি আরএসটি প্যাকেটটি ছুঁড়ে ফেলার ছিল, খুব আকর্ষণীয়, আমি একটি iptables নিয়ম যুক্ত করেছিলাম যা ওয়েব আরভারের জন্য নির্ধারিত সমস্ত আরএসটি প্যাকেটগুলি ফেলে দেয় যা থেকে আমাদের ফাইলগুলির অনুরোধ করতে সমস্যা হয়। এবং তারপরে এটি কাজ করেছে যেমন উপরের লগটিতে শেষ এফআইএন, এসিকে, পিএসএইচ প্যাকেটটি বাদ পড়েছে, তবে আরএসটি বাদ হওয়ায় ওয়েবসভারের কাছে সমস্ত এসি-এর পিপড়া পাওয়ার সময় রয়েছে, তারপরে শেষ প্যাকেটটি পুনরায় স্থান দেওয়ার সিদ্ধান্ত নিয়েছে, প্যাকেটটি আবার 2133, কনট্রাক মডিউলটি এখন এসিকে ক্লায়েন্টের কাছ থেকে ফিরে আসতে দেখেছে এবং শেষ এসিকে, চূড়ান্ত পেইডের সাথে এফআইএন প্যাকেটটিকে অনুমতি দেয় বলে এখন এটি ফায়ারওয়ালের মধ্য দিয়ে যায়।
সুতরাং এটি অবশ্যই একটি সময় / উইন্ডো সমস্যা, এই নির্দিষ্ট ফাইলটি, ক্লায়েন্টের কাছ থেকে এসকে'র টাইমিংয়ের সাথে, কনট্র্যাকের মধ্যে এমন কিছু ট্রিগার করে যা ওয়েব সার্ভার থেকে চূড়ান্ত প্যাকেট প্রত্যাখ্যান করে।
এখনও অবধি, গুগল করা এবং কার্নেল ডকটির পড়াটি এমন কোনও কিছুই প্রকাশ করে না যা এই আচরণের কারণ হতে পারে, পরবর্তী পদক্ষেপটি রাউটিং / কনট্র্যাক মডিউলটির জন্য কার্নেল উত্স কোডটি পড়তে হবে।
সমস্যা সমাধান
ভাল, কমপক্ষে এখন আমরা ঠিক কী ঘটে তা জানি এবং একটি সমাধান রয়েছে যা সমস্যার সমাধান করে।
সের্গেই অত্যন্ত মূল্যবান -m রাষ্ট্র - স্টেট ইনভাল্ড ম্যাচিং নিয়মের দিকে ইঙ্গিত করেছিলেন যা ডিবাগিংয়ে অনেকটা সহায়তা করেছিল, আমি এখন বুঝতে পেরেছি যে ইনভালাইড প্যাকেটের সুস্পষ্ট নিয়ম ছাড়াই একটি আইপ্যাবটেলস সেটআপ পুরোপুরি পুরোপুরি সম্পন্ন হয় না তাই মাঝে মধ্যে অদ্ভুত আচরণ ঘটে বলে মনে হয়।
অকার্যকর প্যাকেটের কারণ কী, এর জন্য কনট্র্যাক মডিউলে লগিং সক্ষম করার সময় কী ঘটেছিল তা বেশ প্রকট হয় এবং এ সম্পর্কে আমার সন্দেহ ছিল।
[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 / wireshark অনুসারে জাম্বো ফ্রেমগুলি কার্নেলের মধ্যে TCP স্তর দ্বারা লেখা ছিল যা নেটওয়ার্ক কার্ড দ্বারা এমটিইউ = 1500 দিয়ে ছোট ফ্রেমে ভাগ করা হয়েছিল। সুতরাং স্পষ্টতই এটি ওয়েবসভারে অ্যাড্রেস করা দরকার যেহেতু রিসিভারের উইন্ডোতে প্রাপ্তিগুলির বিজ্ঞাপনগুলির চেয়ে বেশি ডেটা প্রেরণ করা টিসিপি আচরণটি সঠিক নয়।
পলিনোমিয়াল এবং সার্জি উভয়ই মূল্যবান ইনপুট সরবরাহ করেছিল তবে সের্গেই আমাকে প্যাকেট ট্র্যাভারসাল সম্পর্কিত কনট্র্যাক / এনএটি মডিউলটির সঠিক আচরণের দিকে লক্ষ্য করেছিলেন।