Uitgaande ESP sonder antwoord beteken nie die VPN is dood nie
ESP beskerm een rigting per assosiasie en erken niks. Bring die innerlike gesprek en inkomende SA in lyn voordat jy die bediener onreageerbaar noem.
Jy het verkeer op die IPsec-gasheer vasgevang, gesien hoe ESP-pakkette vertrek, niks sien terugkom en tot die gevolgtrekking gekom dat die ander kant stukkend is. Die opname ondersteun nie daardie gevolgtrekking nie. ESP beskerm een rigting van 'n gesprek en erken niks op die IP-laag nie, so ontbrekende terug-ESP kan net so maklik beteken dat die toepassing niks te sê gehad het as dat die tonnel dood is. Lees die innerlike uitruiling en die ontvangkant se toestand voordat jy enige een van die kante blameer.
Die mite: elke beskermde pakket verdien 'n antwoord
ESP is nie 'n versoek-antwoord-protokol nie. Dit versleutel en verifieer wat die beleid ook al kies, en die ontvanger valideer, ontsleutel en lewer daardie innerlike pakket sonder om 'n pakket van sy eie te skep. 'n UDP-navraag wat die bestemming ignoreer, of 'n ICMP-eggolo wat inkomende beleid verwerp, lewer stilte in beide rigtings as die korrekte uitkoms. Om daardie stilte as 'n vervoerfout te behandel, stuur jou op soek na 'n netwerkfout wat nooit daar was nie.
Wat 'n eenrigting-opname werklik bewys, is dat die sender se stapel iets op daardie waarnemingspunt versleutel het. Niks oor aankoms nie, en niks oor die bedoeling om te antwoord nie. Die nuttige vraag is nie "hoekom is daar geen antwoord nie" nie, maar "wat moes die innerlike gesprek voortgebring het".
Twee SA's, twee SPI's, een gesprek
IPsec-sekuriteitsassosiasies is eenrigting, so 'n normale beskermde uitruiling loop 'n inkomende assosiasie en 'n uitgaande assosiasie met aparte identifiseerders en onafhanklike toestand. Om die terugverkeer vir die uitgaande pakket se SPI te soek, is dus 'n kategorie-fout, want enige antwoord reis onder die eweknie se eie uitgaande SA met sy eie SPI. Pas die paar eerder op verkeerskeerders en eweknie-adresse.
Hersleuteling bemoeilik die prentjie vir 'n paar sekondes op 'n slag, want ou en vervangende toestand kan oorvleuel. As die simptoom rondom 'n hersleuteling begin het, versamel assosiasie-identifiseerders en tydstempels saam eerder as net die verbinding se naam.
Wat die ontvanger moet doen voordat enigiets antwoord
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Elke ry faal onafhanklik en elke faling het 'n ander eienaar, daarom kan 'n enkele opname hulle nie onderskei nie. Die inkomende teller is die enigste direkte bewys van aankoms, want 'n pakket wat sy verifikasie of herspel-toets faal, word sonder enige antwoord weggegooi. 'n Eweknie wie se inkomende teller nie beweeg het nie, stuur jou dus glad geen inligting oor sy beleid nie.
Aflewering is 'n aparte stap van ontsleuteling. Toestand kan geldig wees en die pakket steeds daarna deur 'n inkomende beleid of 'n roete wat nie die innerlike bestemming insluit nie, laat val word, so kyk of die teikengasheer gewone teks gesien het eerder as om te aanvaar dat 'n skoon teller beteken die pakket het gegaan waar jy wou.
Inheemse ESP is nie UDP nie
Inheemse ESP is IP-protokol 50, wat nóg TCP nóg UDP is en hoegenaamd geen poorte het nie. 'n Brandmuur-reël wat IKE op UDP 500 toelaat, sê dus niks oor die datapad nie, en 'n filter wat rondom poorte geskryf is, kan 'n tonnel laat onderhandel en dan alles wat daarbinne gedra word, laat val. Toets die datapad op sy eie, in die modus wat jy werklik waargeneem het.
Agter 'n NAT verander die vorm: die beskermde loonvrag reis binne UDP, gewoonlik op poort 4500, soos RFC 3948 bepaal. Teken die aktiewe modus aan voordat jy enige reël skryf, want 'n toestel op die pad kan inheemse ESP en UDP-ingekapselde ESP heeltemal anders behandel, en sommige middleboxes laat een toe terwyl hulle die ander laat val.
Lees tellers wat by hierdie voorval hoort
Op 'n strongSwan-gasheer rapporteer swanctl --list-sas pakket- en greptellers per assosiasie in beide rigtings, wat genoeg is om "nooit aangekom" van "aangekom en nie geantwoord" te skei. Op Linux tel /proc/net/xfrm_stat saamgetelde falings soos ontbrekende toestand, ontbrekende beleid en protokolfoute. Daardie totale hoop op vanaf die selflaai en hoort by een netwerknaamruimte, so 'n groot getal is nie 'n toeskrywing nie.
Neem twee lesings rondom die voorvalvenster in die korrekte naamruimte en vergelyk die verskille, anders sal jy verlede week se foute op vanmiddag se kaartjie vaspen. Sit die naamruimte en beide tydstempels in die kaartjie sodat die volgende leser die vergelyking kan herhaal eerder as om 'n totaal te vertrou.
Noem die stadium, nie die verdagte nie
'n Nuttige gevolgtrekking sê waar die pakket gestop het: nooit ontvang nie, ontvang en weggegooi, afgelewer maar onbeantwoord, of geantwoord en op die terugpad verloor. Elkeen van dié dui op 'n ander eienaar en 'n ander volgende opdrag. "Geen antwoord van die VPN-bediener" druk vier verskillende foute in een sin wat die opname nooit geregverdig het nie.
Hou opnames smal, en hou rou kerntoestand uit kaartjies, want dit kan sleutelmateriaal dra wat niks buite die gasheer te doen het nie. Die tellerverskille en die tydstempels is die dele wat werd is om aan die volgende persoon te gee.