Tietokantakysely jämähtää IPsecin yli: UDP:n uudelleenjärjestys vai TCP?
Kysely, joka jämähtää puhtaan kättelyn jälkeen, osoittaa tunnelin polun sisään. Kolme ehtoa ratkaisee, korjataanko polku vai palataanko TCP:hen portissa 443.
Kysely, joka jämähtää TCP-kättelyn jälkeen, ei ole reititysongelma. Reittivirheet kaatavat kättelyn, joten istunto, joka muodostuu ja sitten vaikenee, osoittaa polun sisään: tarkastus, MTU tai tapa, jolla tunnelin UDP-paketit saapuvat. Edessäsi oleva päätös on, korjaatko tuon polun vai siirrätkö tunnelin TCP:hen. Kolme ehtoa ratkaisee sen, eikä yksikään niistä koske tietokantaa.
Luokittele jämähtäminen ennen kuin syytät tunnelia
Neljä lopputulosta näyttävät käyttäjälle samalta ja tarkoittavat insinöörille täysin eri asioita.
| What the client sees | What it rules out |
|---|---|
| Connection refused | Nothing is listening on the address and port the client reached |
| Timeout before the handshake | A filter, a missing route, or the wrong address |
| Handshake completes, query hangs | The session exists, so look at inspection, MTU and packet order |
| Stalls that recover on retry | Often reordering, or a state table entry expiring |
Vain kaksi viimeistä riviä oikeuttavat ajan tunnelilla. VPN:n yli hylätty yhteys on yleensä tietokanta, joka kuuntelee vain loopbackissa, mikä on kuuntelijan ongelma, ja kättelyä edeltävä aikakatkaisu on suodatin tai reitti. Kumpikaan ei parane kapseloinnin vaihtamisella.
Kirjoita luokittelu ensin tikettiin. Se on halvin askel ja poistaa suurimman osan hakutilasta.
Kolme ehtoa, jotka ratkaisevat UDP:n ja TCP:n välillä
Kapseloitu IPsec-liikenne kulkee UDP:n päällä, ja UDP antaa polulle vapauden järjestää uudelleen ja pudottaa kertomatta kenellekään. Kun uudelleenjärjestys työntää paketit tunnelin toistonsuojausikkunan ulkopuolelle, ne hylätään hiljaa ja sisempi TCP-istunto vain odottaa. Se on mekanismi onnistuvan kättelyn ja koskaan palaamattoman kyselyn takana.
Polun korjaaminen tai TCP:hen palaaminen riippuu kolmesta asiasta. Ensinnäkin, onko polulla todellista pakettihäviötä vai vain uudelleenjärjestystä? Toiseksi, voitko muuttaa, missä tarkastus tapahtuu, tai jättää tämän tunnelin uudelleenjärjestävän komponentin ulkopuolelle? Kolmanneksi, onko työkuorma herkkä jämähtämiskuviolle, esimerkiksi monet multipleksoidut istunnot, jotka jakavat yhden linkin?
Jos ensimmäinen vastaus on häviö ja toinen ei,TCP portissa 443 on pragmaattinen varavaihtoehto. Jos toinen vastaus on kyllä, korjaa polku ja pidä UDP.
Lue palomuurin merkintä, älä sovelluksen virhettä
Sovellus ilmoittaa aikakatkaisusta, mikä ei kerro syystä mitään. Palomuurin oma loki on paikka, jossa pudotus tai esto näkyy, joten suodata tietokannan ja sovelluksen osoitteilla ja etsi sekä hylkäyksiä että hyväksyntöjä.Uhkien torjunnan moduulit voivat hylätä paketteja luomatta sovellustason virhettä, ja juuri sellainen on jämähtävän kyselyn muoto. Hiljaisuus lokissa on myös dataa: se osoittaa johonkin, joka ei lokita, kuten uudelleenjärjestykseen.
Tarkista myös klusteri. Väärin konfiguroitu klusteri voi pitää istuntoa tilataulussa yhdellä jäsenellä, kun paketit kulkevat toisen jäsenen polkua, joten vastaukset saapuvat sinne, missä tilaa ei ole. Sellaiset jämähtämiset näyttävät satunnaisilta eivätkä korreloi kuorman kanssa.
Vertaa molempia päitä ennen kuin muutat mitään, ja vertaa saapumisjärjestystä pakettimäärien sijaan:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapMitä TCP portissa 443 todella maksaa sinulle
Tunnelin siirtäminen TCP:hen poistaa uudelleenjärjestyksen oireen, koska välilaite näkee nyt järjestetyn virran. Se luo myös TCP-over-TCP:n. Ulompi yhteys lähettää uudelleen sen, minkä sisempi on jo lähettänyt uudelleen, ja yksi häviö voi pysäyttää kaikki multipleksoidut istunnot kerralla. Puhtaalla polulla se on näkymätön. Häviöisellä polulla lääke on pahempi kuin oire.
Vaihtokauppa on hyväksyttävä, kun vaihtoehtona on yhteydettömyys, ja se pitäisi dokumentoida poikkeuksena omistajan kanssa sen sijaan, että se otettaisiin normaalina.
Kirjaa kuljetus, portti, esimerkkikysely ja mitattu tulos sekä päivämäärä. Ilman tätä merkintää seuraava insinööri toistaa kokeen, ja poikkeuksesta tulee hiljaa arkkitehtuuri.
Pidä päätös uudelleenarvioitavana
Polkudiagnoosi vanhenee huonosti. Välilaite vaihdetaan, moduulin kokoonpano muuttuu, linkki päivitetään, ja syy TCP:lle portissa 443 katoaa, kun taas kokoonpano jää. Laita poikkeukselle tarkistuspäivä ja nimeä ehto, joka sallisi paluun UDP:hen.
Testaa molempia kuljetuksia pienellä kyselyllä ja suurella tulosjoukolla. Uudelleenjärjestys näkyy kokoriippuvaisina jämähtämisinä, kun taas kuuntelijavika pysäyttää molemmat koot yhtä lailla.