Hello semua, nama saya Sasha, saya mengetuai ujian bahagian belakang di FunCorp. Kami, seperti ramai yang lain, telah melaksanakan seni bina berorientasikan perkhidmatan. Di satu pihak, ini memudahkan kerja, kerana... Adalah lebih mudah untuk menguji setiap perkhidmatan secara berasingan, tetapi sebaliknya, terdapat keperluan untuk menguji interaksi perkhidmatan antara satu sama lain, yang sering berlaku melalui rangkaian.
Dalam artikel ini, saya akan bercakap tentang dua utiliti yang boleh digunakan untuk menyemak senario asas yang menerangkan pengendalian aplikasi dengan kehadiran masalah rangkaian.
Mensimulasikan masalah rangkaian
Biasanya, perisian diuji pada pelayan ujian dengan sambungan Internet yang baik. Dalam persekitaran pengeluaran yang keras, perkara mungkin tidak begitu lancar, jadi kadangkala anda perlu menguji program dalam keadaan sambungan yang lemah. Di Linux, utiliti akan membantu dengan tugas mensimulasikan keadaan sedemikian tc.
tc(abbr. daripada Kawalan Lalu Lintas) membolehkan anda mengkonfigurasi penghantaran paket rangkaian dalam sistem. Utiliti ini mempunyai keupayaan yang hebat, anda boleh membaca lebih lanjut mengenainya . Di sini saya akan mempertimbangkan hanya beberapa daripadanya: kami berminat dengan penjadualan lalu lintas, yang kami gunakan qdisc, dan kerana kita perlu meniru rangkaian yang tidak stabil, kita akan menggunakan qdisc tanpa kelas .
Mari kita lancarkan pelayan gema pada pelayan (saya menggunakan ):
ncat -l 127.0.0.1 12345 -k -c 'xargs -n1 -i echo "Response: {}"'
Untuk memaparkan secara terperinci semua cap masa pada setiap langkah interaksi antara pelanggan dan pelayan, saya menulis skrip Python mudah yang menghantar permintaan ujian ke pelayan gema kami.
Kod sumber pelanggan
#!/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
Mari kita lancarkan dan lihat trafik pada antara muka lo dan port 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
Tempat pembuangan trafik
[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
Semuanya adalah standard: jabat tangan tiga hala, PSH/ACK dan ACK sebagai tindak balas dua kali - ini ialah pertukaran permintaan dan tindak balas antara pelanggan dan pelayan, dan FIN/ACK dan ACK dua kali - melengkapkan sambungan.
Kelewatan paket
Sekarang mari kita tetapkan kelewatan kepada 500 milisaat:
tc qdisc add dev lo root netem delay 500ms
Kami melancarkan klien dan melihat bahawa skrip kini berjalan selama 2 saat:
[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
Apa yang ada dalam lalu lintas? Mari lihat:
Tempat pembuangan trafik
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
Anda dapat melihat bahawa lag yang dijangkakan selama setengah saat telah muncul dalam interaksi antara pelanggan dan pelayan. Sistem berkelakuan lebih menarik jika lag lebih besar: kernel mula menghantar semula beberapa paket TCP. Mari tukar kelewatan kepada 1 saat dan lihat trafik (saya tidak akan menunjukkan output pelanggan, terdapat jangkaan 4 saat dalam jumlah tempoh):
tc qdisc change dev lo root netem delay 1s
Tempat pembuangan trafik
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
Ia boleh dilihat bahawa pelanggan menghantar paket SYN dua kali, dan pelayan menghantar SYN/ACK dua kali.
Sebagai tambahan kepada nilai malar, kelewatan boleh ditetapkan kepada sisihan, fungsi pengedaran dan korelasi (dengan nilai untuk paket sebelumnya). Ini dilakukan seperti berikut:
tc qdisc change dev lo root netem delay 500ms 400ms 50 distribution normal
Di sini kami telah menetapkan kelewatan antara 100 dan 900 milisaat, nilai akan dipilih mengikut taburan normal dan akan terdapat korelasi 50% dengan nilai kelewatan untuk paket sebelumnya.
Anda mungkin perasan bahawa dalam arahan pertama yang saya gunakan menambahdan kemudian menukar. Maksud arahan ini jelas, jadi saya hanya akan menambah bahawa terdapat lebih banyak lagi yang, yang boleh digunakan untuk mengalih keluar konfigurasi.
Kehilangan Paket
Sekarang mari kita cuba lakukan kehilangan paket. Seperti yang dapat dilihat daripada dokumentasi, ini boleh dilakukan dalam tiga cara: kehilangan paket secara rawak dengan beberapa kebarangkalian, menggunakan rantai Markov 2, 3 atau 4 keadaan untuk mengira kehilangan paket, atau menggunakan model Elliott-Gilbert. Dalam artikel itu saya akan mempertimbangkan kaedah pertama (paling mudah dan paling jelas), dan anda boleh membaca tentang orang lain .
Mari kita kehilangan 50% paket dengan korelasi 25%:
tc qdisc add dev lo root netem loss 50% 25%
Malangnya, tcpdump tidak akan dapat menunjukkan dengan jelas kehilangan paket kepada kami, kami hanya akan menganggap bahawa ia benar-benar berfungsi. Dan masa berjalan skrip yang meningkat dan tidak stabil akan membantu kami mengesahkan perkara ini. pelanggan.py (boleh diselesaikan serta-merta, atau mungkin dalam 20 saat), serta peningkatan bilangan paket yang dihantar semula:
[user@host ~]# netstat -s | grep retransmited; sleep 10; netstat -s | grep retransmited
17147 segments retransmited
17185 segments retransmited
Menambah bunyi pada paket
Selain kehilangan paket, anda boleh mensimulasikan kerosakan paket: bunyi akan muncul pada kedudukan paket rawak. Mari buat kerosakan paket dengan kebarangkalian 50% dan tanpa korelasi:
tc qdisc change dev lo root netem corrupt 50%
Kami menjalankan skrip klien (tiada apa-apa yang menarik di sana, tetapi ia mengambil masa 2 saat untuk disiapkan), lihat pada trafik:
Tempat pembuangan trafik
[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
Dapat dilihat bahawa beberapa paket telah dihantar berulang kali dan terdapat satu paket dengan metadata yang rosak: pilihan [nop,unknown-65 0x0a3dcf62eb3d,[bad opt]>. Tetapi perkara utama ialah pada akhirnya semuanya berfungsi dengan betul - TCP mengatasi tugasnya.
Penduaan paket
Apa lagi yang boleh anda lakukan netem? Contohnya, simulasikan situasi terbalik kehilangan paketβpenduaan paket. Perintah ini juga mengambil 2 hujah: kebarangkalian dan korelasi.
tc qdisc change dev lo root netem duplicate 50% 25%
Menukar susunan pakej
Anda boleh mencampurkan beg dalam dua cara.
Pada yang pertama, beberapa paket dihantar serta-merta, selebihnya dengan kelewatan yang ditentukan. Contoh daripada dokumentasi:
tc qdisc change dev lo root netem delay 10ms reorder 25% 50%
Dengan kebarangkalian 25% (dan korelasi 50%) paket akan dihantar serta-merta, selebihnya akan dihantar dengan kelewatan 10 milisaat.
Kaedah kedua ialah apabila setiap paket Nth dihantar serta-merta dengan kebarangkalian tertentu (dan korelasi), dan selebihnya dengan kelewatan tertentu. Contoh daripada dokumentasi:
tc qdisc change dev lo root netem delay 10ms reorder 25% 50% gap 5
Setiap pakej kelima mempunyai peluang 25% untuk dihantar tanpa berlengah-lengah.
Menukar Lebar Jalur
Biasanya di mana-mana sahaja mereka rujuk , tetapi dengan bantuan netem Anda juga boleh menukar lebar jalur antara muka:
tc qdisc change dev lo root netem rate 56kbit
Pasukan ini akan membuat trek sekitar localhost pedih seperti melayari Internet melalui modem dail. Selain menetapkan kadar bit, anda juga boleh meniru model protokol lapisan pautan: tetapkan overhed untuk paket, saiz sel dan overhed untuk sel. Sebagai contoh, ini boleh disimulasikan dan kadar bit 56 kbit/saat:
tc qdisc change dev lo root netem rate 56kbit 0 48 5
Mensimulasikan tamat masa sambungan
Satu lagi perkara penting dalam rancangan ujian apabila menerima perisian ialah tamat masa. Ini penting kerana dalam sistem yang diedarkan, apabila salah satu perkhidmatan dilumpuhkan, yang lain mesti kembali kepada yang lain tepat pada masanya atau mengembalikan ralat kepada pelanggan, dan dalam keadaan apa pun mereka tidak sepatutnya menggantung, menunggu jawapan atau sambungan. untuk ditubuhkan.
Terdapat beberapa cara untuk melakukan ini: contohnya, gunakan olok-olok yang tidak bertindak balas, atau sambungkan ke proses menggunakan penyahpepijat, letakkan titik putus di tempat yang betul dan hentikan proses (ini mungkin cara yang paling sesat). Tetapi salah satu yang paling jelas ialah port firewall atau hos. Ia akan membantu kami dengan ini .
Untuk demonstrasi, kami akan port firewall 12345 dan menjalankan skrip klien kami. Anda boleh firewall paket keluar ke port ini pada penghantar atau paket masuk pada penerima. Dalam contoh saya, paket masuk akan berdinding api (kami menggunakan rantai INPUT dan pilihan --dport). Paket sedemikian boleh DROP, REJECT atau REJECT dengan bendera TCP RST, atau dengan hos ICMP yang tidak dapat dicapai (sebenarnya, tingkah laku lalai ialah icmp-port-unreachable, dan terdapat juga peluang untuk menghantar balasan icmp-net-unreachable, icmp-proto-unreachable, icmp-net-dilarang ΠΈ icmp-host-dilarang).
GUGUR
Jika terdapat peraturan dengan DROP, paket hanya akan "hilang".
iptables -A INPUT -p tcp --dport 12345 -j DROP
Kami melancarkan pelanggan dan melihat bahawa ia membeku pada peringkat menyambung ke pelayan. Mari lihat trafik:
Tempat pembuangan trafik
[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
Ia boleh dilihat bahawa pelanggan menghantar paket SYN dengan tamat masa yang meningkat secara eksponen. Jadi kami menemui pepijat kecil dalam klien: anda perlu menggunakan kaedah tersebut settimeout()untuk mengehadkan masa di mana pelanggan akan cuba menyambung ke pelayan.
Kami segera mengalih keluar peraturan:
iptables -D INPUT -p tcp --dport 12345 -j DROPAnda boleh memadamkan semua peraturan sekaligus:
iptables -F
Jika anda menggunakan Docker dan anda perlu firewall semua lalu lintas ke bekas, maka anda boleh melakukannya seperti berikut:
iptables -I DOCKER-USER -p tcp -d CONTAINER_IP -j DROP
REJEK
Sekarang mari tambah peraturan yang serupa, tetapi dengan TOLAK:
iptables -A INPUT -p tcp --dport 12345 -j REJECT
Pelanggan keluar selepas satu saat dengan ralat [Errno 111] Sambungan ditolak. Mari lihat trafik 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
Ia boleh dilihat bahawa pelanggan menerima dua kali pelabuhan tidak dapat dicapai dan kemudian berakhir dengan ralat.
TOLAK dengan tcp-reset
Mari cuba tambah pilihan --reject-dengan tcp-reset:
iptables -A INPUT -p tcp --dport 12345 -j REJECT --reject-with tcp-reset
Dalam kes ini, pelanggan segera keluar dengan ralat, kerana permintaan pertama menerima paket 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
TOLAK dengan icmp-host-unreachable
Mari cuba pilihan lain untuk menggunakan REJECT:
iptables -A INPUT -p tcp --dport 12345 -j REJECT --reject-with icmp-host-unreachable
Pelanggan keluar selepas satu saat dengan ralat [Errno 113] Tiada laluan ke hos, kita lihat dalam trafik ICMP Hos ICMP 127.0.0.1 tidak dapat dicapai.
Anda juga boleh mencuba parameter TOLAK yang lain, dan saya akan menumpukan pada ini :)
Mensimulasikan tamat masa permintaan
Situasi lain ialah apabila pelanggan dapat menyambung ke pelayan, tetapi tidak boleh menghantar permintaan kepadanya. Bagaimana untuk menapis paket supaya penapisan tidak dimulakan dengan segera? Jika anda melihat trafik sebarang komunikasi antara klien dan pelayan, anda akan perasan bahawa apabila membuat sambungan, hanya bendera SYN dan ACK digunakan, tetapi apabila bertukar data, paket permintaan terakhir akan mengandungi bendera PSH. Ia dipasang secara automatik untuk mengelakkan penimbalan. Anda boleh menggunakan maklumat ini untuk mencipta penapis: ia akan membenarkan semua paket kecuali yang mengandungi bendera PSH. Oleh itu, sambungan akan diwujudkan, tetapi pelanggan tidak akan dapat menghantar data ke pelayan.
GUGUR
Untuk DROP arahan akan kelihatan seperti ini:
iptables -A INPUT -p tcp --tcp-flags PSH PSH --dport 12345 -j DROP
Lancarkan pelanggan dan perhatikan lalu lintas:
Tempat pembuangan trafik
[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
Kami melihat bahawa sambungan diwujudkan dan pelanggan tidak boleh menghantar data ke pelayan.
REJEK
Dalam kes ini tingkah laku akan sama: pelanggan tidak akan dapat menghantar permintaan, tetapi akan menerima ICMP 127.0.0.1 port tcp 12345 tidak boleh dicapai dan meningkatkan masa antara penyerahan semula permintaan secara eksponen. Perintahnya kelihatan seperti ini:
iptables -A INPUT -p tcp --tcp-flags PSH PSH --dport 12345 -j REJECT
TOLAK dengan tcp-reset
Perintahnya kelihatan seperti ini:
iptables -A INPUT -p tcp --tcp-flags PSH PSH --dport 12345 -j REJECT --reject-with tcp-reset
Kita sudah tahu bahawa apabila menggunakan --reject-dengan tcp-reset pelanggan akan menerima paket RST sebagai tindak balas, jadi tingkah laku boleh diramalkan: menerima paket RST semasa sambungan diwujudkan bermakna soket ditutup secara tidak dijangka di sisi lain, yang bermaksud pelanggan harus menerima Tetapan semula sambungan oleh rakan sebaya. Mari jalankan skrip kami dan pastikan ini. Dan inilah rupa lalu lintas:
Tempat pembuangan trafik
[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
TOLAK dengan icmp-host-unreachable
Saya rasa sudah jelas kepada semua orang tentang rupa arahan itu :) Tingkah laku pelanggan dalam kes ini akan berbeza sedikit daripada itu dengan TOLAK mudah: pelanggan tidak akan menambah tamat masa antara percubaan untuk menghantar semula paket.
[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
Output
Ia tidak perlu menulis olok-olok untuk menguji interaksi perkhidmatan dengan klien atau pelayan yang digantung; kadangkala cukup untuk menggunakan utiliti standard yang terdapat di Linux.
Utiliti yang dibincangkan dalam artikel mempunyai lebih banyak keupayaan daripada yang diterangkan, jadi anda boleh membuat beberapa pilihan anda sendiri untuk menggunakannya. Secara peribadi, saya sentiasa cukup dengan apa yang saya tulis (malah, malah kurang). Jika anda menggunakan utiliti ini atau yang serupa dalam ujian di syarikat anda, sila tulis bagaimana sebenarnya. Jika tidak, maka saya harap perisian anda akan menjadi lebih baik jika anda memutuskan untuk mengujinya dalam keadaan masalah rangkaian menggunakan kaedah yang dicadangkan.
Sumber: www.habr.com