שלום לכולם, שמי סשה, אני מוביל בדיקות עורפיות ב-FunCorp. אנחנו, כמו רבים אחרים, יישמנו ארכיטקטורה מוכוונת שירות. מצד אחד, זה מפשט את העבודה, כי... קל יותר לבדוק כל שירות בנפרד, אך מצד שני, יש צורך לבדוק את האינטראקציה של השירותים זה עם זה, המתרחשת לרוב ברשת.

במאמר זה, אדבר על שני כלי עזר שניתן להשתמש בהם כדי לבדוק תרחישים בסיסיים המתארים את פעולת האפליקציה בנוכחות בעיות רשת.

הדמיית בעיות רשת

בדרך כלל, תוכנה נבדקת על שרתי בדיקה עם חיבור אינטרנט טוב. בסביבות ייצור קשות, ייתכן שהדברים לא יהיו כל כך חלקים, אז לפעמים אתה צריך לבדוק תוכניות בתנאי חיבור גרועים. ב-Linux, כלי השירות יעזור במשימה של הדמיית תנאים כאלה tc.

tc(ראשי תיבות מבקרת תנועה) מאפשר לך להגדיר את השידור של מנות רשת במערכת. לכלי השירות הזה יש יכולות נהדרות, אתה יכול לקרוא עליהם עוד כאן. כאן אתייחס רק לכמה מהם: אנו מעוניינים בתזמון תנועה, שעבורו אנו משתמשים qdisc, ומכיוון שאנחנו צריכים לחקות רשת לא יציבה, נשתמש ב-qdisc ללא classless נטם.

בואו נפעיל שרת הד בשרת (השתמשתי nmap-ncat):

ncat -l 127.0.0.1 12345 -k -c 'xargs -n1 -i echo "Response: {}"'

על מנת להציג בפירוט את כל חותמות הזמן בכל שלב של אינטראקציה בין הלקוח לשרת, כתבתי סקריפט Python פשוט ששולח בקשה מִבְחָן לשרת ההד שלנו.

קוד מקור הלקוח

#!/bin/python

import socket
import time

HOST = '127.0.0.1'
PORT = 12345
BUFFER_SIZE = 1024
MESSAGE = "Testn"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
t1 = time.time()
print "[time before connection: %.5f]" % t1
s.connect((HOST, PORT))
print "[time after connection, before sending: %.5f]" % time.time()
s.send(MESSAGE)
print "[time after sending, before receiving: %.5f]" % time.time()
data = s.recv(BUFFER_SIZE)
print "[time after receiving, before closing: %.5f]" % time.time()
s.close()
t2 = time.time()
print "[time after closing: %.5f]" % t2
print "[total duration: %.5f]" % (t2 - t1)

print data

בואו נשיק אותו ונסתכל על התעבורה בממשק lo ויציאה 12345:

[user@host ~]# python client.py
[time before connection: 1578652979.44837]
[time after connection, before sending: 1578652979.44889]
[time after sending, before receiving: 1578652979.44894]
[time after receiving, before closing: 1578652979.45922]
[time after closing: 1578652979.45928]
[total duration: 0.01091]
Response: Test

מזבלה של תנועה

[user@host ~]# tcpdump -i lo -nn port 12345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
10:42:59.448601 IP 127.0.0.1.54054 > 127.0.0.1.12345: Flags [S], seq 3383332866, win 43690, options [mss 65495,sackOK,TS val 606325685 ecr 0,nop,wscale 7], length 0
10:42:59.448612 IP 127.0.0.1.12345 > 127.0.0.1.54054: Flags [S.], seq 2584700178, ack 3383332867, win 43690, options [mss 65495,sackOK,TS val 606325685 ecr 606325685,nop,wscale 7], length 0
10:42:59.448622 IP 127.0.0.1.54054 > 127.0.0.1.12345: Flags [.], ack 1, win 342, options [nop,nop,TS val 606325685 ecr 606325685], length 0
10:42:59.448923 IP 127.0.0.1.54054 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 606325685 ecr 606325685], length 5
10:42:59.448930 IP 127.0.0.1.12345 > 127.0.0.1.54054: Flags [.], ack 6, win 342, options [nop,nop,TS val 606325685 ecr 606325685], length 0
10:42:59.459118 IP 127.0.0.1.12345 > 127.0.0.1.54054: Flags [P.], seq 1:15, ack 6, win 342, options [nop,nop,TS val 606325696 ecr 606325685], length 14
10:42:59.459213 IP 127.0.0.1.54054 > 127.0.0.1.12345: Flags [.], ack 15, win 342, options [nop,nop,TS val 606325696 ecr 606325696], length 0
10:42:59.459268 IP 127.0.0.1.54054 > 127.0.0.1.12345: Flags [F.], seq 6, ack 15, win 342, options [nop,nop,TS val 606325696 ecr 606325696], length 0
10:42:59.460184 IP 127.0.0.1.12345 > 127.0.0.1.54054: Flags [F.], seq 15, ack 7, win 342, options [nop,nop,TS val 606325697 ecr 606325696], length 0
10:42:59.460196 IP 127.0.0.1.54054 > 127.0.0.1.12345: Flags [.], ack 16, win 342, options [nop,nop,TS val 606325697 ecr 606325697], length 0

הכל סטנדרטי: לחיצת יד תלת כיוונית, PSH/ACK ו-ACK בתגובה פעמיים - זוהי חילופי הבקשה והתגובה בין הלקוח לשרת, ו-FIN/ACK ו-ACK פעמיים - השלמת החיבור.

עיכוב מנות

עכשיו בואו נגדיר את ההשהיה ל-500 מילישניות:

tc qdisc add dev lo root netem delay 500ms

אנו מפעילים את הלקוח ורואים שהסקריפט פועל כעת למשך 2 שניות:

[user@host ~]# ./client.py
[time before connection: 1578662612.71044]
[time after connection, before sending: 1578662613.71059]
[time after sending, before receiving: 1578662613.71065]
[time after receiving, before closing: 1578662614.72011]
[time after closing: 1578662614.72019]
[total duration: 2.00974]
Response: Test

מה יש בתנועה? בואו נראה:

מזבלה של תנועה

13:23:33.210520 IP 127.0.0.1.58694 > 127.0.0.1.12345: Flags [S], seq 1720950927, win 43690, options [mss 65495,sackOK,TS val 615958947 ecr 0,nop,wscale 7], length 0
13:23:33.710554 IP 127.0.0.1.12345 > 127.0.0.1.58694: Flags [S.], seq 1801168125, ack 1720950928, win 43690, options [mss 65495,sackOK,TS val 615959447 ecr 615958947,nop,wscale 7], length 0
13:23:34.210590 IP 127.0.0.1.58694 > 127.0.0.1.12345: Flags [.], ack 1, win 342, options [nop,nop,TS val 615959947 ecr 615959447], length 0
13:23:34.210657 IP 127.0.0.1.58694 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 615959947 ecr 615959447], length 5
13:23:34.710680 IP 127.0.0.1.12345 > 127.0.0.1.58694: Flags [.], ack 6, win 342, options [nop,nop,TS val 615960447 ecr 615959947], length 0
13:23:34.719371 IP 127.0.0.1.12345 > 127.0.0.1.58694: Flags [P.], seq 1:15, ack 6, win 342, options [nop,nop,TS val 615960456 ecr 615959947], length 14
13:23:35.220106 IP 127.0.0.1.58694 > 127.0.0.1.12345: Flags [.], ack 15, win 342, options [nop,nop,TS val 615960957 ecr 615960456], length 0
13:23:35.220188 IP 127.0.0.1.58694 > 127.0.0.1.12345: Flags [F.], seq 6, ack 15, win 342, options [nop,nop,TS val 615960957 ecr 615960456], length 0
13:23:35.720994 IP 127.0.0.1.12345 > 127.0.0.1.58694: Flags [F.], seq 15, ack 7, win 342, options [nop,nop,TS val 615961457 ecr 615960957], length 0
13:23:36.221025 IP 127.0.0.1.58694 > 127.0.0.1.12345: Flags [.], ack 16, win 342, options [nop,nop,TS val 615961957 ecr 615961457], length 0

ניתן לראות שהפיגור הצפוי של חצי שנייה הופיע באינטראקציה בין הלקוח לשרת. המערכת מתנהגת בצורה הרבה יותר מעניינת אם הפיגור גדול יותר: הקרנל מתחיל לשלוח מחדש כמה מנות TCP. בואו נשנה את ההשהיה לשנייה אחת ונסתכל על התעבורה (אני לא אראה את הפלט של הלקוח, יש את ה-1 שניות הצפויות לכל משך הזמן הכולל):

tc qdisc change dev lo root netem delay 1s

מזבלה של תנועה

13:29:07.709981 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [S], seq 283338334, win 43690, options [mss 65495,sackOK,TS val 616292946 ecr 0,nop,wscale 7], length 0
13:29:08.710018 IP 127.0.0.1.12345 > 127.0.0.1.39306: Flags [S.], seq 3514208179, ack 283338335, win 43690, options [mss 65495,sackOK,TS val 616293946 ecr 616292946,nop,wscale 7], length 0
13:29:08.711094 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [S], seq 283338334, win 43690, options [mss 65495,sackOK,TS val 616293948 ecr 0,nop,wscale 7], length 0
13:29:09.710048 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [.], ack 1, win 342, options [nop,nop,TS val 616294946 ecr 616293946], length 0
13:29:09.710152 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 616294947 ecr 616293946], length 5
13:29:09.711120 IP 127.0.0.1.12345 > 127.0.0.1.39306: Flags [S.], seq 3514208179, ack 283338335, win 43690, options [mss 65495,sackOK,TS val 616294948 ecr 616292946,nop,wscale 7], length 0
13:29:10.710173 IP 127.0.0.1.12345 > 127.0.0.1.39306: Flags [.], ack 6, win 342, options [nop,nop,TS val 616295947 ecr 616294947], length 0
13:29:10.711140 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [.], ack 1, win 342, options [nop,nop,TS val 616295948 ecr 616293946], length 0
13:29:10.714782 IP 127.0.0.1.12345 > 127.0.0.1.39306: Flags [P.], seq 1:15, ack 6, win 342, options [nop,nop,TS val 616295951 ecr 616294947], length 14
13:29:11.714819 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [.], ack 15, win 342, options [nop,nop,TS val 616296951 ecr 616295951], length 0
13:29:11.714893 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [F.], seq 6, ack 15, win 342, options [nop,nop,TS val 616296951 ecr 616295951], length 0
13:29:12.715562 IP 127.0.0.1.12345 > 127.0.0.1.39306: Flags [F.], seq 15, ack 7, win 342, options [nop,nop,TS val 616297952 ecr 616296951], length 0
13:29:13.715596 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [.], ack 16, win 342, options [nop,nop,TS val 616298952 ecr 616297952], length 0

ניתן לראות שהלקוח שלח חבילת SYN פעמיים, והשרת שלח SYN/ACK פעמיים.

בנוסף לערך קבוע, ניתן להגדיר את ההשהיה לסטייה, פונקציית הפצה ומתאם (עם הערך של החבילה הקודמת). זה נעשה באופן הבא:

tc qdisc change dev lo root netem delay 500ms 400ms 50 distribution normal

כאן קבענו את ההשהיה בין 100 ל-900 מילישניות, הערכים ייבחרו לפי התפלגות נורמלית ותהיה מתאם של 50% עם ערך ההשהיה של החבילה הקודמת.

אולי שמתם לב לזה בפקודה הראשונה שהשתמשתי בה להוסיףואז שינוי. המשמעות של הפקודות הללו ברורה, אז אני רק אוסיף שיש עוד דל, שבו ניתן להשתמש כדי להסיר את התצורה.

אובדן מנות

כעת ננסה לבצע אובדן מנות. כפי שניתן לראות מהתיעוד, ניתן לעשות זאת בשלוש דרכים: איבוד מנות באופן אקראי בהסתברות מסוימת, שימוש בשרשרת מרקוב של 2, 3 או 4 מצבים לחישוב אובדן מנות, או שימוש במודל אליוט-גילברט. במאמר אשקול את השיטה הראשונה (הפשוטה והברורה ביותר), ותוכלו לקרוא על אחרות כאן.

בוא נעשה אובדן של 50% מהמנות עם מתאם של 25%:

tc qdisc add dev lo root netem loss 50% 25%

למרבה הצער, tcpdump לא יוכל להראות לנו בבירור את אובדן החבילות, אנחנו רק נניח שזה באמת עובד. וזמן הריצה המוגדל והלא יציב של הסקריפט יעזור לנו לאמת זאת. client.py (ניתן להשלים באופן מיידי, או אולי תוך 20 שניות), כמו גם מספר מוגבר של מנות משודרות מחדש:

[user@host ~]# netstat -s | grep retransmited; sleep 10; netstat -s | grep retransmited
    17147 segments retransmited
    17185 segments retransmited

הוספת רעש לחבילות

בנוסף לאובדן מנות, אתה יכול לדמות נזק למנות: רעש יופיע במיקום מנות אקראי. בואו נעשה נזק למנות עם הסתברות של 50% וללא קורלציה:

tc qdisc change dev lo root netem corrupt 50%

אנחנו מריצים את סקריפט הלקוח (שום דבר מעניין שם, אבל זה לקח 2 שניות להשלים), תסתכל על התעבורה:

מזבלה של תנועה

[user@host ~]# tcpdump -i lo -nn port 12345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
10:20:54.812434 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [S], seq 2023663770, win 43690, options [mss 65495,sackOK,TS val 1037001049 ecr 0,nop,wscale 7], length 0
10:20:54.812449 IP 127.0.0.1.12345 > 127.0.0.1.43666: Flags [S.], seq 2104268044, ack 2023663771, win 43690, options [mss 65495,sackOK,TS val 1037001049 ecr 1037001049,nop,wscale 7], length 0
10:20:54.812458 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [.], ack 1, win 342, options [nop,nop,TS val 1037001049 ecr 1037001049], length 0
10:20:54.812509 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 1037001049 ecr 1037001049], length 5
10:20:55.013093 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 1037001250 ecr 1037001049], length 5
10:20:55.013122 IP 127.0.0.1.12345 > 127.0.0.1.43666: Flags [.], ack 6, win 342, options [nop,nop,TS val 1037001250 ecr 1037001250], length 0
10:20:55.014681 IP 127.0.0.1.12345 > 127.0.0.1.43666: Flags [P.], seq 1:15, ack 6, win 342, options [nop,nop,TS val 1037001251 ecr 1037001250], length 14
10:20:55.014745 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [.], ack 15, win 340, options [nop,nop,TS val 1037001251 ecr 1037001251], length 0
10:20:55.014823 IP 127.0.0.1.43666 > 127.0.0.5.12345: Flags [F.], seq 2023663776, ack 2104268059, win 342, options [nop,nop,TS val 1037001251 ecr 1037001251], length 0
10:20:55.214088 IP 127.0.0.1.12345 > 127.0.0.1.43666: Flags [P.], seq 1:15, ack 6, win 342, options [nop,unknown-65 0x0a3dcf62eb3d,[bad opt]>
10:20:55.416087 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [F.], seq 6, ack 15, win 342, options [nop,nop,TS val 1037001653 ecr 1037001251], length 0
10:20:55.416804 IP 127.0.0.1.12345 > 127.0.0.1.43666: Flags [F.], seq 15, ack 7, win 342, options [nop,nop,TS val 1037001653 ecr 1037001653], length 0
10:20:55.416818 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [.], ack 16, win 343, options [nop,nop,TS val 1037001653 ecr 1037001653], length 0
10:20:56.147086 IP 127.0.0.1.12345 > 127.0.0.1.43666: Flags [F.], seq 15, ack 7, win 342, options [nop,nop,TS val 1037002384 ecr 1037001653], length 0
10:20:56.147101 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [.], ack 16, win 342, options [nop,nop,TS val 1037002384 ecr 1037001653], length 0

ניתן לראות שחלק מהמנות נשלחו שוב ושוב ויש חבילה אחת עם מטא נתונים שבורים: אפשרויות [nop,unknown-65 0x0a3dcf62eb3d,[bad opt]>. אבל העיקר שבסופו של דבר הכל עבד כמו שצריך - TCP התמודדה עם המשימה שלה.

שכפול מנות

עם מה עוד אפשר לעשות נטם? לדוגמה, הדמיית מצב הפוך של אובדן מנות - שכפול מנות. פקודה זו לוקחת גם 2 ארגומנטים: הסתברות ומתאם.

tc qdisc change dev lo root netem duplicate 50% 25%

שינוי סדר החבילות

אפשר לערבב את השקיות בשתי דרכים.

בראשון, חלק מהמנות נשלחות מיד, השאר באיחור מוגדר. דוגמה מהתיעוד:

tc qdisc change dev lo root netem delay 10ms reorder 25% 50%

בהסתברות של 25% (ומתאם של 50%) החבילה תישלח מיד, השאר יישלחו באיחור של 10 מילישניות.

השיטה השנייה היא כאשר כל חבילה N נשלחת באופן מיידי בהסתברות (ומתאם) נתונה, והשאר בהשהיה נתונה. דוגמה מהתיעוד:

tc qdisc change dev lo root netem delay 10ms reorder 25% 50% gap 5

לכל חבילה חמישית יש סיכוי של 25% להישלח ללא דיחוי.

שינוי רוחב פס

בדרך כלל בכל מקום אליו הם מתייחסים TBF, אבל בעזרת העזרה נטם אתה יכול גם לשנות את רוחב הפס של הממשק:

tc qdisc change dev lo root netem rate 56kbit

הצוות הזה יעשה טרקים מסביב localhost כואב כמו גלישה באינטרנט באמצעות מודם בחיוג. בנוסף להגדרת קצב הסיביות, ניתן גם לחקות את מודל פרוטוקול שכבת הקישור: הגדר את התקורה עבור החבילה, את גודל התא ואת התקורה עבור התא. לדוגמה, ניתן לדמות זאת כַּספּוֹמָט וקצב סיביות 56 kbit/sek:

tc qdisc change dev lo root netem rate 56kbit 0 48 5

הדמיית פסק זמן לחיבור

נקודה חשובה נוספת בתוכנית הבדיקה בעת קבלת תוכנה היא פסקי זמן. זה חשוב מכיוון שבמערכות מבוזרות, כאשר אחד השירותים מושבת, האחרים חייבים ליפול בזמן לאחרים או להחזיר שגיאה ללקוח, ובשום מקרה אסור להם פשוט להיתקע, להמתין לתגובה או לחיבור להקים.

ישנן מספר דרכים לעשות זאת: למשל, להשתמש ב-mock שלא מגיב, או להתחבר לתהליך באמצעות debugger, לשים נקודת עצירה במקום הנכון ולעצור את התהליך (זו כנראה הדרך המעוותת ביותר). אבל אחד הברורים ביותר הוא יציאות חומת אש או מארחים. זה יעזור לנו בזה iptables.

לצורך הדגמה, אנו נוציא חומת אש 12345 ונפעיל את סקריפט הלקוח שלנו. אתה יכול חומת אש מנות יוצאות ליציאה זו אצל השולח או מנות נכנסות במקלט. בדוגמאות שלי, מנות נכנסות יהיו חומת אש (אנו משתמשים ב- INPUT בשרשרת ובאופציה --dport). מנות כאלה יכולות להיות DROP, REJECT או REJECT עם דגל TCP RST, או עם מארח ICMP שאי אפשר להגיע אליו (למעשה, התנהגות ברירת המחדל היא icmp-port-unreachable, ויש גם אפשרות לשלוח תשובה icmp-net-unreachable, icmp-proto-unreachable, icmp-net-אסור и icmp-host-איסור).

DROP

אם יש כלל עם DROP, מנות פשוט "ייעלמו".

iptables -A INPUT -p tcp --dport 12345 -j DROP

אנחנו מפעילים את הלקוח ורואים שהוא קופא בשלב החיבור לשרת. בואו נסתכל על התנועה:
מזבלה של תנועה

[user@host ~]# tcpdump -i lo -nn port 12345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
08:28:20.213506 IP 127.0.0.1.32856 > 127.0.0.1.12345: Flags [S], seq 3019694933, win 43690, options [mss 65495,sackOK,TS val 1203046450 ecr 0,nop,wscale 7], length 0
08:28:21.215086 IP 127.0.0.1.32856 > 127.0.0.1.12345: Flags [S], seq 3019694933, win 43690, options [mss 65495,sackOK,TS val 1203047452 ecr 0,nop,wscale 7], length 0
08:28:23.219092 IP 127.0.0.1.32856 > 127.0.0.1.12345: Flags [S], seq 3019694933, win 43690, options [mss 65495,sackOK,TS val 1203049456 ecr 0,nop,wscale 7], length 0
08:28:27.227087 IP 127.0.0.1.32856 > 127.0.0.1.12345: Flags [S], seq 3019694933, win 43690, options [mss 65495,sackOK,TS val 1203053464 ecr 0,nop,wscale 7], length 0
08:28:35.235102 IP 127.0.0.1.32856 > 127.0.0.1.12345: Flags [S], seq 3019694933, win 43690, options [mss 65495,sackOK,TS val 1203061472 ecr 0,nop,wscale 7], length 0

ניתן לראות שהלקוח שולח מנות SYN עם פסק זמן הולך וגדל באופן אקספוננציאלי. אז מצאנו באג קטן בלקוח: אתה צריך להשתמש בשיטה settimeout()כדי להגביל את הזמן שבמהלכו הלקוח ינסה להתחבר לשרת.

אנו מסירים מיד את הכלל:

iptables -D INPUT -p tcp --dport 12345 -j DROP

אתה יכול למחוק את כל הכללים בבת אחת:

iptables -F

אם אתה משתמש ב-Docker ואתה צריך לעשות חומת אש לכל התעבורה שעוברת לקונטיינר, אתה יכול לעשות זאת באופן הבא:

iptables -I DOCKER-USER -p tcp -d CONTAINER_IP -j DROP

דחה

עכשיו בואו נוסיף כלל דומה, אבל עם דחייה:

iptables -A INPUT -p tcp --dport 12345 -j REJECT

הלקוח יוצא לאחר שנייה עם שגיאה [שגיאה 111] החיבור סירבה. בואו נסתכל על תעבורת ICMP:

[user@host ~]# tcpdump -i lo -nn icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
08:45:32.871414 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 tcp port 12345 unreachable, length 68
08:45:33.873097 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 tcp port 12345 unreachable, length 68

ניתן לראות שהלקוח קיבל פעמיים לא ניתן להגיע לנמל ואז הסתיים בשגיאה.

דחה עם tcp-reset

בואו ננסה להוסיף את האפשרות --reject-with tcp-reset:

iptables -A INPUT -p tcp --dport 12345 -j REJECT --reject-with tcp-reset

במקרה זה, הלקוח יוצא מיד עם שגיאה, מכיוון שהבקשה הראשונה קיבלה חבילת RST:

[user@host ~]# tcpdump -i lo -nn port 12345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
09:02:52.766175 IP 127.0.0.1.60658 > 127.0.0.1.12345: Flags [S], seq 1889460883, win 43690, options [mss 65495,sackOK,TS val 1205119003 ecr 0,nop,wscale 7], length 0
09:02:52.766184 IP 127.0.0.1.12345 > 127.0.0.1.60658: Flags [R.], seq 0, ack 1889460884, win 0, length 0

דחה עם icmp-host-unreachable

בואו ננסה אפשרות אחרת לשימוש ב-REJECT:

iptables -A INPUT -p tcp --dport 12345 -j REJECT --reject-with icmp-host-unreachable

הלקוח יוצא לאחר שנייה עם שגיאה [שגיאה 113] אין מסלול לארח, אנו רואים בתעבורת ICMP מארח ICMP 127.0.0.1 לא ניתן להשגה.

אתה יכול גם לנסות את הפרמטרים האחרים של REJECT, ואני אתמקד באלה :)

הדמיית פסק זמן של בקשה

מצב נוסף הוא כאשר הלקוח הצליח להתחבר לשרת, אך אינו יכול לשלוח אליו בקשה. איך לסנן מנות כך שהסינון לא יתחיל מיד? אם תסתכל על התעבורה של תקשורת כלשהי בין הלקוח לשרת, תבחין כי בעת יצירת חיבור, נעשה שימוש רק בדגלי SYN ו-ACK, אך בעת החלפת נתונים, חבילת הבקשות האחרונה תכיל את דגל PSH. זה מותקן אוטומטית כדי למנוע חציצה. אתה יכול להשתמש במידע זה כדי ליצור מסנן: הוא יאפשר את כל החבילות מלבד אלה המכילות את דגל ה-PSH. לפיכך, החיבור ייווצר, אך הלקוח לא יוכל לשלוח נתונים לשרת.

DROP

עבור DROP הפקודה תיראה כך:

iptables -A INPUT -p tcp --tcp-flags PSH PSH --dport 12345 -j DROP

הפעל את הלקוח וצפה בתנועה:

מזבלה של תנועה

[user@host ~]# tcpdump -i lo -nn port 12345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
10:02:47.549498 IP 127.0.0.1.49594 > 127.0.0.1.12345: Flags [S], seq 2166014137, win 43690, options [mss 65495,sackOK,TS val 1208713786 ecr 0,nop,wscale 7], length 0
10:02:47.549510 IP 127.0.0.1.12345 > 127.0.0.1.49594: Flags [S.], seq 2341799088, ack 2166014138, win 43690, options [mss 65495,sackOK,TS val 1208713786 ecr 1208713786,nop,wscale 7], length 0
10:02:47.549520 IP 127.0.0.1.49594 > 127.0.0.1.12345: Flags [.], ack 1, win 342, options [nop,nop,TS val 1208713786 ecr 1208713786], length 0
10:02:47.549568 IP 127.0.0.1.49594 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 1208713786 ecr 1208713786], length 5
10:02:47.750084 IP 127.0.0.1.49594 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 1208713987 ecr 1208713786], length 5
10:02:47.951088 IP 127.0.0.1.49594 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 1208714188 ecr 1208713786], length 5
10:02:48.354089 IP 127.0.0.1.49594 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 1208714591 ecr 1208713786], length 5

אנו רואים שהחיבור נוצר והלקוח לא יכול לשלוח נתונים לשרת.

דחה

במקרה זה ההתנהגות תהיה זהה: הלקוח לא יוכל לשלוח את הבקשה, אלא יקבל יציאת tcp 127.0.0.1 ICMP 12345 לא ניתנת להשגה ולהגדיל את הזמן בין הגשת בקשה מחדש באופן אקספוננציאלי. הפקודה נראית כך:

iptables -A INPUT -p tcp --tcp-flags PSH PSH --dport 12345 -j REJECT

דחה עם tcp-reset

הפקודה נראית כך:

iptables -A INPUT -p tcp --tcp-flags PSH PSH --dport 12345 -j REJECT --reject-with tcp-reset

אנחנו כבר יודעים את זה בעת השימוש --reject-with tcp-reset הלקוח יקבל חבילת RST בתגובה, כך שניתן לחזות את ההתנהגות: קבלת חבילת RST בזמן שהחיבור נוצר פירושה שהשקע נסגר באופן בלתי צפוי בצד השני, מה שאומר שהלקוח צריך לקבל חיבור איפוס על ידי עמיתים. בוא נריץ את התסריט שלנו ונוודא את זה. וכך תיראה התנועה:

מזבלה של תנועה

[user@host ~]# tcpdump -i lo -nn port 12345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
10:22:14.186269 IP 127.0.0.1.52536 > 127.0.0.1.12345: Flags [S], seq 2615137531, win 43690, options [mss 65495,sackOK,TS val 1209880423 ecr 0,nop,wscale 7], length 0
10:22:14.186284 IP 127.0.0.1.12345 > 127.0.0.1.52536: Flags [S.], seq 3999904809, ack 2615137532, win 43690, options [mss 65495,sackOK,TS val 1209880423 ecr 1209880423,nop,wscale 7], length 0
10:22:14.186293 IP 127.0.0.1.52536 > 127.0.0.1.12345: Flags [.], ack 1, win 342, options [nop,nop,TS val 1209880423 ecr 1209880423], length 0
10:22:14.186338 IP 127.0.0.1.52536 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 1209880423 ecr 1209880423], length 5
10:22:14.186344 IP 127.0.0.1.12345 > 127.0.0.1.52536: Flags [R], seq 3999904810, win 0, length 0

דחה עם icmp-host-unreachable

אני חושב שזה כבר ברור לכולם איך תיראה הפקודה :) התנהגות הלקוח במקרה זה תהיה מעט שונה מזו עם REJECT פשוט: הלקוח לא יגדיל את הזמן הקצוב בין ניסיונות לשלוח מחדש את החבילה.

[user@host ~]# tcpdump -i lo -nn icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
10:29:56.149202 IP 127.0.0.1 > 127.0.0.1: ICMP host 127.0.0.1 unreachable, length 65
10:29:56.349107 IP 127.0.0.1 > 127.0.0.1: ICMP host 127.0.0.1 unreachable, length 65
10:29:56.549117 IP 127.0.0.1 > 127.0.0.1: ICMP host 127.0.0.1 unreachable, length 65
10:29:56.750125 IP 127.0.0.1 > 127.0.0.1: ICMP host 127.0.0.1 unreachable, length 65
10:29:56.951130 IP 127.0.0.1 > 127.0.0.1: ICMP host 127.0.0.1 unreachable, length 65
10:29:57.152107 IP 127.0.0.1 > 127.0.0.1: ICMP host 127.0.0.1 unreachable, length 65
10:29:57.353115 IP 127.0.0.1 > 127.0.0.1: ICMP host 127.0.0.1 unreachable, length 65

פלט

אין צורך לכתוב דמה כדי לבדוק את האינטראקציה של שירות עם לקוח או שרת תלויים; לפעמים זה מספיק להשתמש בכלי עזר סטנדרטיים שנמצאים בלינוקס.

לכלי השירות הנידונים במאמר יש אפילו יותר יכולות ממה שתוארו, כך שתוכל להמציא כמה מהאפשרויות שלך לשימוש בהם. באופן אישי, תמיד יש לי מספיק ממה שכתבתי עליו (למעשה, אפילו פחות). אם אתה משתמש בכלי שירות אלה או דומים בבדיקות בחברה שלך, אנא כתוב כיצד בדיוק. אם לא, אז אני מקווה שהתוכנה שלך תשתפר אם תחליט לבדוק אותה בתנאים של בעיות רשת באמצעות השיטות המוצעות.

מקור: www.habr.com