Swali linalokwama baada ya handshake ya TCP si tatizo la uelekezaji. Hitilafu za njia hushindwa handshake, kwa hivyo kipindi kinachojengwa na kisha kunyamaza kinaelekeza ndani ya njia: ukaguzi, MTU, au jinsi pakiti za UDP za handaki zinavyofika. Uamuzi ulio mbele yako ni kama kurekebisha njia hiyo au kuhamisha handaki kwenye TCP. Masharti matatu huamua hilo, na hakuna hata moja kuhusu hifadhidata.

Ainisha kukwama kabla ya kulaumu handaki

Matokeo manne yanaonekana sawa kwa mtumiaji na yanamaanisha mambo tofauti kabisa kwa mhandisi.

What the client seesWhat it rules out
Connection refusedNothing is listening on the address and port the client reached
Timeout before the handshakeA filter, a missing route, or the wrong address
Handshake completes, query hangsThe session exists, so look at inspection, MTU and packet order
Stalls that recover on retryOften reordering, or a state table entry expiring

Ni safu mbili za mwisho tu zinazohalalisha muda kwenye handaki. Muunganisho uliokataliwa kupitia VPN kwa kawaida ni hifadhidata inayosikiliza tu kwenye loopback, ambayo ni tatizo la msikilizaji, na muda kuisha kabla ya handshake ni chujio au njia. Hakuna kati yao inaboreka kwa kubadilisha ufungashaji.

Andika uainishaji kwenye tikiti kwanza. Ni hatua ya bei nafuu zaidi na inaondoa sehemu kubwa ya nafasi ya utafutaji.

Masharti matatu yanayoamua UDP dhidi ya TCP

Trafiki ya IPsec iliyofungwa huenda kwa UDP, na UDP inaipa njia uhuru wa kupanga upya na kutupa bila kumwambia mtu yeyote. Upangaji upya unaposukuma pakiti nje ya dirisha la kuzuia kurudia la handaki, huachwa kimya na kipindi cha ndani cha TCP kinasubiri tu. Huo ndio utaratibu ulio nyuma ya handshake inayofanikiwa na swali lisilorejea kamwe.

Kurekebisha njia au kurudi kwenye TCP kunategemea mambo matatu. Kwanza, kuna upotevu halisi wa pakiti kwenye njia, au upangaji upya tu? Pili, unaweza kubadilisha mahali ukaguzi unafanyika, au kuondoa handaki hii kwenye kipengele kinachopanga upya? Tatu, mzigo wa kazi ni nyeti kwa muundo wa kukwama, kwa mfano vipindi vingi vya multiplex vinavyoshiriki kiungo kimoja?

Ikiwa jibu la kwanza ni upotevu na la pili ni hapana,TCP kwenye 443 ndio njia mbadala ya kiutendaji. Ikiwa jibu la pili ni ndiyo, rekebisha njia na uendelee na UDP.

Soma rekodi ya firewall, si hitilafu ya programu

Programu inaripoti muda kuisha, ambayo haisemi chochote kuhusu sababu. Logi ya firewall yenyewe ndio mahali kutupwa au kuzuiwa huonekana, kwa hivyo chuja kwa anwani za hifadhidata na programu na tafuta kutupwa pamoja na kukubaliwa.Vipande vya kuzuia vitisho vinaweza kutupa pakiti bila kuzalisha hitilafu katika ngazi ya programu, na hiyo ndiyo sura kamili ya swali linalokwama. Ukimya kwenye logi pia ni data: unaelekeza kwenye kitu kisichorekodi, kama upangaji upya.

Angalia pia kikundi. Kikundi kilichowekwa vibaya kinaweza kushikilia kipindi kwenye jedwali la hali kwa mwanachama mmoja huku pakiti zikipita njia ya mwanachama mwingine, kwa hivyo majibu hufika mahali pasipo hali. Kukwama kama huko kunaonekana kama bahati nasibu na hakuendani na mzigo.

Linganisha ncha zote mbili kabla ya kubadilisha chochote, na linganisha mpangilio wa kuwasili badala ya idadi ya pakiti:

tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcap

Kile TCP kwenye 443 kinachokugharimu kwa kweli

Kuhamisha handaki kwenye TCP kunaondoa dalili ya upangaji upya, kwa sababu sanduku la kati sasa linaona mtiririko uliopangwa. Pia huunda TCP juu ya TCP. Muunganisho wa nje hutuma tena kile muunganisho wa ndani ulichotuma tena, na upotevu mmoja unaweza kusimamisha vipindi vyote vya multiplex kwa wakati mmoja. Kwenye njia safi hilo halionekani. Kwenye njia yenye upotevu tiba ni mbaya kuliko dalili.

Mabadilishano yanakubalika wakati njia mbadala ni kukosa muunganisho kabisa, na inapaswa kuandikwa kama ubaguzi wenye mmiliki badala ya kuchukuliwa kama kawaida.

Rekodi usafirishaji, bandari, swali la mfano na matokeo yaliyopimwa, pamoja na tarehe. Bila rekodi hiyo mhandisi anayefuata hurudia jaribio, na ubaguzi unakuwa usanifu kimya kimya.

Weka uamuzi uweze kupitiwa upya

Utambuzi wa njia huzeeka haraka. Sanduku la kati hubadilishwa, usanidi wa kipande hubadilika, kiungo huboreshwa, na sababu ya TCP kwenye 443 hupotea wakati usanidi unabaki. Weka tarehe ya mapitio kwenye ubaguzi na taja sharti litakalokuwezesha kurudi kwenye UDP.

Jaribu usafirishaji wote wawili kwa swali dogo na kwa seti kubwa ya matokeo. Upangaji upya huonekana kama kukwama kunakotegemea ukubwa, wakati hitilafu ya msikilizaji husimamisha ukubwa wote kwa usawa.

Makala zinazohusiana