Conntrack NEW sur ACK-paketo: kion ĝi ne pruvas
ACK markita kiel NEW signifas, ke la spurilo ne havis kongruan staton, ne ke la VPN malfermis sesion. Legu la hokon, la tuple-on kaj la registran fenestron.
En la fajroŝirma protokolo estas unu linio, kiun vi ne atendis: ACK-paketo, conntrack-stato NEW, fonta adreso, kiu ne estas via, celloka pordo malfermita. La tento estas legi ĝin kiel novan envenantan ligon, kiun neniu rajtigis. Kion la linio efektive diras estas pli mallarĝe: kiam tiu paketo atingis ĉi tiun hokon, la spurilo havis neniun kongruan staton, kaj la paketo portis ACK. Tiuj estas du faktoj pri du malsamaj aferoj, kaj nek unu estas kompleta transskribo de manpremo. Jen la ordo, kiun mi trapasas antaŭ ol fari konkludon.
Komencu per la paketo, ne per la verdikto
Apartigu la observojn antaŭ ol interpreti ilin. La TCP-flagoj priskribas ĉi tiun paketon, la stato de la spurilo priskribas, kion ĝi sciis ĉe tiu hoko, kaj via registraĵo priskribas nur la fenestron, kiun vi registris.
Konfuzi tiujn tri estas la maniero, kiel ACK fariĝas «la provizanto enlasis iun».
Kion NEW vere signifas ĉe la hoko
La kongruo de iptables conntrack dokumentas NEW kiel paketon, kiu komencas ligon, aŭ unu ligitan al ligo, kiu ankoraŭ ne vidis trafikon en ambaŭ direktoj. ESTABLISHED signifas, ke la spurilo vidis paketojn en ambaŭ direktoj. Neniu el la du difinoj diras, ke la paketo estis SYN, kaj neniu diras, ke ĝi alvenis sen historio.
Spurilo, kiu komencas observi fluon meze, klasifikas la sekvan paketon laŭ tio, kion ĝi scias, kaj tio povas esti nenio. Tio estas aserto pri la memoro de la spurilo, ne pri la intenco de la fora gastiganto.
Malstrikta spurado klarigas la plej multajn ACK-surprizojn
La kerno dokumentas nf_conntrack_tcp_loose, kio permesas al la spurilo transpreni TCP-ligojn, kies komencon ĝi ne vidis. Kun la agordo je sia defaŭlta valoro, ACK el la mezo de fluo povas esti adoptita kiel establita fluo. Malŝaltu ĝin kaj la sama paketo estos pli verŝajne klasifikita kiel INVALID anstataŭ NEW. Ambaŭ rezultoj priskribas la regulojn de la spurilo, ne la historion de la aplikaĵo.
Do kontrolu tiun agordon antaŭ ol konstrui teorion sur la etikedo.
Ekskludu la enuajn kaŭzojn en ĉi tiu ordo
La plej multaj NEW-sur-ACK-okazaĵoj, kiujn mi postsekvis, finiĝis per unu el tiuj, kaj ĉiuj estas malmultekostaj kontroli:
- La conntrack-tabelo estis malplenigita, aŭ la spurilo restartiĝis.
- La gastiganto restartiĝis, aŭ la fluo translokiĝis al alia namespace aŭ aparato.
- Nesimetria enkursigo sendis la SYN el vojo, kiun vi ne registras.
- NAT reskribis la tuple-on, do la ero ne plu kongruas kun tio, kion vi legis.
- La registraĵo komenciĝis malfrue kaj neniam vidis la komencon.
Ĉiu el tiuj forigas la pli fruajn paketojn el la vido de la spurilo kaj lasas la pli malfruajn sendifektaj. Restarto aŭ malplenigo de la tabelo estas la plej facile konfirmebla el uptime kaj protokoloj. Nesimetria enkursigo montriĝas kiel unudirekta registraĵo. NAT estas la ruza, ĉar la tuple, kiun la spurilo konservis, ne estas la tuple presita en la protokolo.
Notu, kiujn el tiuj vi ekskludis, kaj kiel, antaŭ ol daŭrigi.
Legu la tuple-on, la interfacon kaj la hokon
Conntrack-ero estas ŝlosita per adresoj, pordoj kaj protokolo, do ĉiu traduko ŝanĝas, kiu ero kongruas. Notu ankaŭ la interfacon kaj la hokon, ĉar paketo vidata sur la malĝusta interfaco aŭ post alia ĉeno diras al vi, ke la vojo ne estas tiu de la diagramo. Kiam la okazaĵo temas pri VPN, decidu, ĉu vi rigardas la internan paketon aŭ la eksteran portanto. Poste komparu kun tio, kion la enirejo protokolis por la sama kvinparta tuple.
Du vidpunktoj pri unu fluo, kiuj malkonsentas, estas pli informaj ol ĉiu el ili sola.
Kiam indas eskali
Eskalu, kiam vi povas montri servon, kiu estas atingebla kaj ne devus esti, kun la fluo, la politiko, kiu permesis ĝin, kaj pruvoj el ambaŭ finoj. Ne raportu provizantan difekton surbaze de unu stata etikedo aŭ unu parta registraĵo, ĉar tiu raporto estos fermita per la klarigo, kiun vi ĵus legis. Se la servo vere estas elmetita, la posedanto de tiu limo estas la ĝusta persono por ripari ĝin, kaj delegita pordomapo aŭ neintenca aŭskultanto estas pli verŝajna kaŭzo ol cimo.
Poste fermu la videblecan breĉon, kiu lasis unu paketon aspekti kiel tuta sesio.