Halló allir, ég heiti Sasha, ég stýri bakendaprófunum hjá FunCorp. Við, eins og margir aðrir, höfum innleitt þjónustumiðaðan arkitektúr. Annars vegar einfaldar þetta verkið því... Auðveldara er að prófa hverja þjónustu fyrir sig, en hins vegar þarf að prófa samspil þjónustu hver við aðra, sem oft á sér stað yfir netið.
Í þessari grein mun ég tala um tvö tól sem hægt er að nota til að athuga grunnatburðarás sem lýsa rekstri forrits í viðurvist netvandamála.
Herma netvandamál
Venjulega er hugbúnaður prófaður á prófunarþjónum með góða nettengingu. Í erfiðu framleiðsluumhverfi eru hlutirnir kannski ekki svo sléttir, svo stundum þarf að prófa forrit við lélegar tengingaraðstæður. Á Linux mun tólið hjálpa til við að líkja eftir slíkum aðstæðum tc.
tc(skammstöfun. frá Umferðarstjórn) gerir þér kleift að stilla sendingu netpakka í kerfinu. Þetta tól hefur mikla möguleika, þú getur lesið meira um þá . Hér mun ég aðeins fjalla um nokkrar þeirra: við höfum áhuga á umferðaráætlun, sem við notum qdiskur, og þar sem við þurfum að líkja eftir óstöðugu neti, munum við nota classless qdisc .
Við skulum ræsa echo server á þjóninum (ég notaði ):
ncat -l 127.0.0.1 12345 -k -c 'xargs -n1 -i echo "Response: {}"'
Til þess að sýna í smáatriðum alla tímastimpla í hverju skrefi í samskiptum milli viðskiptavinarins og netþjónsins skrifaði ég einfalt Python skriftu sem sendir beiðni Próf á echo serverinn okkar.
Frumkóði viðskiptavinar
#!/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
Við skulum ræsa það og skoða umferðina á viðmótinu lo og höfn 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
Umferðarhaugur
[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
Allt er staðlað: þríhliða handaband, PSH/ACK og ACK sem svar tvisvar - þetta er skipting á beiðni og svari milli viðskiptavinar og netþjóns, og FIN/ACK og ACK tvisvar - klára tenginguna.
Pakki seinkun
Nú skulum við stilla seinkunina á 500 millisekúndur:
tc qdisc add dev lo root netem delay 500ms
Við ræsum biðlarann og sjáum að handritið keyrir núna í 2 sekúndur:
[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
Hvað er í umferðinni? Við skulum skoða:
Umferðarhaugur
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
Þú getur séð að væntanleg töf upp á hálfa sekúndu hefur birst í samskiptum biðlarans og netþjónsins. Kerfið hegðar sér miklu áhugaverðara ef seinkunin er meiri: kjarninn byrjar að endursenda suma TCP pakka. Við skulum breyta seinkuninni í 1 sekúndu og skoða umferðina (ég mun ekki sýna framleiðsla viðskiptavinarins, það eru væntanlegar 4 sekúndur í heildartíma):
tc qdisc change dev lo root netem delay 1s
Umferðarhaugur
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
Það má sjá að viðskiptavinurinn sendi SYN pakka tvisvar og þjónninn sendi SYN/ACK tvisvar.
Til viðbótar við fast gildi er hægt að stilla seinkunina á frávik, dreifingarfall og fylgni (við gildið fyrir fyrri pakka). Þetta er gert sem hér segir:
tc qdisc change dev lo root netem delay 500ms 400ms 50 distribution normal
Hér höfum við stillt seinkunina á milli 100 og 900 millisekúndna, gildin verða valin í samræmi við normaldreifingu og það verður 50% fylgni við seinkun gildi fyrri pakkans.
Þú gætir hafa tekið eftir því í fyrstu skipuninni sem ég notaði bæta viðog þá breyting. Merking þessara skipana er augljós, svo ég bæti bara við að það er meira del, sem hægt er að nota til að fjarlægja stillingarnar.
Pakkatap
Við skulum nú reyna að gera pakkatap. Eins og sjá má af skjölunum er hægt að gera þetta á þrjá vegu: að tapa pakka af handahófi með einhverjum líkindum, nota Markov keðju með 2, 3 eða 4 ríkjum til að reikna út pakkatap eða nota Elliott-Gilbert líkanið. Í greininni mun ég íhuga fyrstu (einfaldustu og augljósustu) aðferðina og þú getur lesið um aðra .
Við skulum missa 50% pakka með fylgni upp á 25%:
tc qdisc add dev lo root netem loss 50% 25%
Því miður, tcpdump mun ekki geta sýnt okkur greinilega tap á pakka, við munum aðeins gera ráð fyrir að það virki í raun. Og aukinn og óstöðugur keyrslutími handritsins mun hjálpa okkur að sannreyna þetta. client.py (hægt að klára samstundis, eða kannski á 20 sekúndum), auk aukins fjölda endursendra pakka:
[user@host ~]# netstat -s | grep retransmited; sleep 10; netstat -s | grep retransmited
17147 segments retransmited
17185 segments retransmited
Bætir hávaða í pakka
Til viðbótar við pakkatap geturðu líkt eftir pakkaskemmdum: hávaði mun birtast í handahófskenndri pakkastöðu. Við skulum gera pakkaskemmdir með 50% líkum og án fylgni:
tc qdisc change dev lo root netem corrupt 50%
Við keyrum biðlarahandritið (ekkert áhugavert þar, en það tók 2 sekúndur að klára), skoðaðu umferðina:
Umferðarhaugur
[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
Það má sjá að sumir pakkar voru sendir ítrekað og það er einn pakki með brotnum lýsigögnum: valkostir [nei, óþekkt-65 0x0a3dcf62eb3d,[slæmt val]>. En aðalatriðið er að á endanum virkaði allt rétt - TCP tókst á við verkefni sitt.
Fjölföldun pakka
Hvað annað er hægt að gera við netem? Til dæmis, líkja eftir öfugri stöðu pakkataps - pakkaafritun. Þessi skipun tekur einnig 2 rök: líkur og fylgni.
tc qdisc change dev lo root netem duplicate 50% 25%
Breyting á röð pakka
Þú getur blandað pokunum saman á tvo vegu.
Í þeim fyrsta eru sumir pakkar sendir strax, restin með tiltekinni töf. Dæmi úr skjölunum:
tc qdisc change dev lo root netem delay 10ms reorder 25% 50%
Með 25% líkum (og fylgni 50%) verður pakkinn sendur strax, afgangurinn verður sendur með 10 millisekúndna seinkun.
Önnur aðferðin er þegar hver N. pakki er sendur samstundis með ákveðnum líkum (og fylgni) og restin með ákveðinni töf. Dæmi úr skjölunum:
tc qdisc change dev lo root netem delay 10ms reorder 25% 50% gap 5
Fimmti hver pakki hefur 25% líkur á að verða sendur án tafar.
Breyting á bandbreidd
Venjulega alls staðar sem þeir vísa til , en með hjálpinni netem Þú getur líka breytt bandbreidd viðmótsins:
tc qdisc change dev lo root netem rate 56kbit
Þetta lið mun gera ferðir um localhost jafn sársaukafullt og að vafra um netið í gegnum innhringimótald. Auk þess að stilla bitahraðann geturðu líka líkt eftir samskiptareglum hlekkjalagsins: stilltu kostnaðinn fyrir pakkann, frumastærðina og kostnaðinn fyrir reitinn. Til dæmis er hægt að líkja eftir þessu og bitahraði 56 kbit/sek:
tc qdisc change dev lo root netem rate 56kbit 0 48 5
Hermir eftir tengingartíma
Annar mikilvægur punktur í prófunaráætluninni þegar hugbúnaður er samþykktur er tímamörk. Þetta er mikilvægt vegna þess að í dreifðum kerfum, þegar ein af þjónustunum er óvirk, verða hinar að falla aftur til hinna í tíma eða skila villu til viðskiptavinarins, og í engu tilviki ættu þær einfaldlega að hanga, bíða eftir svari eða tengingu á að stofna.
Það eru nokkrar leiðir til að gera þetta: til dæmis, nota spotta sem svarar ekki, eða tengjast ferlinu með því að nota villuforrit, setja brotpunkt á réttan stað og stöðva ferlið (þetta er sennilega rangstæðasta leiðin). En einn af þeim augljósustu er að eldvegggjafir eða vélar. Það mun hjálpa okkur með þetta .
Til sýnis munum við eldvegggátt 12345 og keyra biðlarahandritið okkar. Þú getur eldveggað sendan pakka í þessa höfn hjá sendanda eða komandi pakka á móttakandanum. Í dæmunum mínum verða komandi pakkar eldveggir (við notum keðjuINPUT og valmöguleikann --dport). Slíkir pakkar geta verið DROP, REJECT eða REJECT með TCP fánanum RST, eða með ICMP hýsil sem ekki er hægt að ná til (í rauninni er sjálfgefin hegðun icmp-port-unreachable, og einnig er möguleiki á að senda svar icmp-net-óaðgengilegt, icmp-proto-unreachable, icmp-net-bannað и icmp-host-bannað).
DROP
Ef það er regla með DROP munu pakkar einfaldlega „hverfa“.
iptables -A INPUT -p tcp --dport 12345 -j DROP
Við ræsum biðlarann og sjáum að hann frýs á stigi tengingar við netþjóninn. Lítum á umferðina:
Umferðarhaugur
[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
Það má sjá að viðskiptavinurinn sendir SYN pakka með veldisvísis vaxandi tímamörkum. Svo við fundum smá villu í biðlaranum: þú þarft að nota aðferðina stilla tíma ()til að takmarka þann tíma sem viðskiptavinurinn mun reyna að tengjast þjóninum.
Við fjarlægjum strax regluna:
iptables -D INPUT -p tcp --dport 12345 -j DROPÞú getur eytt öllum reglum í einu:
iptables -F
Ef þú ert að nota Docker og þú þarft að eldvegga alla umferð sem fer í gáminn, þá geturðu gert það á eftirfarandi hátt:
iptables -I DOCKER-USER -p tcp -d CONTAINER_IP -j DROP
Hafna
Nú skulum við bæta við svipaðri reglu, en með REJECT:
iptables -A INPUT -p tcp --dport 12345 -j REJECT
Viðskiptavinurinn hættir eftir sekúndu með villu [Errno 111] Tenging hafnað. Við skulum líta á ICMP umferðina:
[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
Það má sjá að viðskiptavinurinn fékk tvisvar höfn óaðgengileg og endaði svo með villu.
HAFNA með tcp-reset
Við skulum reyna að bæta við valkostinum --hafna-með tcp-endurstilla:
iptables -A INPUT -p tcp --dport 12345 -j REJECT --reject-with tcp-reset
Í þessu tilviki hættir viðskiptavinurinn strax með villu vegna þess að fyrsta beiðnin fékk RST pakka:
[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
HAFNA með icmp-host-unreachable
Prófum annan valmöguleika til að nota REJECT:
iptables -A INPUT -p tcp --dport 12345 -j REJECT --reject-with icmp-host-unreachable
Viðskiptavinurinn hættir eftir sekúndu með villu [Errno 113] Engin leið til að hýsa, sjáum við í ICMP umferð ICMP gestgjafi 127.0.0.1 óaðgengilegur.
Þú getur líka prófað hinar REJECT færibreyturnar og ég mun einbeita mér að þessum :)
Hermir eftir biðtíma
Önnur staða er þegar viðskiptavinurinn gat tengst þjóninum, en getur ekki sent beiðni til hans. Hvernig á að sía pakka þannig að síun byrji ekki strax? Ef þú skoðar umferð hvers kyns samskipta milli viðskiptavinarins og netþjónsins muntu taka eftir því að þegar tenging er komið á eru aðeins SYN og ACK fánarnir notaðir, en þegar skipt er um gögn mun síðasti beiðnipakkinn innihalda PSH fánann. Það setur sjálfkrafa upp til að forðast biðminni. Þú getur notað þessar upplýsingar til að búa til síu: það mun leyfa alla pakka nema þá sem innihalda PSH fána. Þannig verður tengingin komið á, en viðskiptavinurinn mun ekki geta sent gögn á netþjóninn.
DROP
Fyrir DROP myndi skipunin líta svona út:
iptables -A INPUT -p tcp --tcp-flags PSH PSH --dport 12345 -j DROP
Ræstu viðskiptavininn og horfðu á umferðina:
Umferðarhaugur
[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
Við sjáum að tengingunni er komið á og viðskiptavinurinn getur ekki sent gögn á netþjóninn.
Hafna
Í þessu tilviki verður hegðunin sú sama: viðskiptavinurinn mun ekki geta sent beiðnina, en mun taka á móti ICMP 127.0.0.1 tcp tengi 12345 óaðgengilegt og auka tímann á milli endursendinga beiðni veldisvísis. Skipunin lítur svona út:
iptables -A INPUT -p tcp --tcp-flags PSH PSH --dport 12345 -j REJECT
HAFNA með tcp-reset
Skipunin lítur svona út:
iptables -A INPUT -p tcp --tcp-flags PSH PSH --dport 12345 -j REJECT --reject-with tcp-reset
Við vitum það nú þegar þegar við notum --hafna-með tcp-endurstilla viðskiptavinurinn mun fá RST pakka sem svar, svo hægt er að spá fyrir um hegðunina: að fá RST pakka á meðan tengingin er komið á þýðir að falsinum er óvænt lokað hinum megin, sem þýðir að viðskiptavinurinn ætti að fá Tenging endurstillt af jafningja. Við skulum keyra handritið okkar og ganga úr skugga um þetta. Og svona mun umferðin líta út:
Umferðarhaugur
[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
HAFNA með icmp-host-unreachable
Ég held að það sé nú þegar augljóst fyrir alla hvernig skipunin mun líta út :) Hegðun viðskiptavinarins í þessu tilfelli mun vera örlítið frábrugðin því sem er með einfaldri RJECT: viðskiptavinurinn mun ekki auka tíma á milli tilrauna til að endursenda pakkann.
[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
Það er ekki nauðsynlegt að skrifa spotta til að prófa samspil þjónustu við hengdan viðskiptavin eða netþjón; stundum er nóg að nota venjuleg tól sem finnast í Linux.
Tólin sem fjallað er um í greininni hafa enn meiri möguleika en lýst var, svo þú getur fundið upp á eigin valkostum til að nota þau. Sjálfur á ég alltaf nóg af því sem ég skrifaði um (reyndar jafnvel minna). Ef þú notar þessi eða svipuð tól við prófun í fyrirtæki þínu, vinsamlegast skrifaðu hvernig nákvæmlega. Ef ekki, þá vona ég að hugbúnaðurinn þinn verði betri ef þú ákveður að prófa hann við netvandamál með því að nota þær aðferðir sem mælt er með.
Heimild: www.habr.com