Trafikk forlèt den eine staden og kjem aldri attende, båe gatewayane rapporterer ei fullført forhandling, og det einaste sporet er ein haug med utgåande pakkar utan svar. På eit Linux-endepunkt er den vanlege årsaka ikkje krypteringsstyrken, MTU-en eller ein rutetabell. Det er granulariteten i policy-oppføringane og nummeret som knyter kvar policy til ein tryggingsassosiasjon. Prosedyren nedanfor les dei to databasane før noko anna blir rørt.

Del opp symptomet før du endrar noko

Ein einsretta feil med ei fullført IKE-forhandling avgrensar problemet til datastien. Anten passa den utgåande policyen og svaret vart forkasta, eller så kom svaret aldri fram fordi den andre sida ikkje hadde noko å senda det gjennom. Frå ein applikasjon ser båe like ut, og xfrm-databasane skil dei.

Ikkje start med MTU-en. Ein feil MTU gir hakking og fragmenteringssymptom, ikkje ei rein retningsdeling med stigande utgåande teljarar.

Les policy-databasen og state-databasen

Kryptering på Linux blir avgjort av policy-oppføringar, så ein passande policy, ikkje ei rute, er det som fører ein pakke inn i tunnelen. Køyr ip xfrm policy for å sjå selectors, retning, prioritet og mal for kvar oppføring, og ip xfrm state for å sjå dei etablerte assosiasjonane med reqid-ane sine. Policyen og assosiasjonen blir knytte saman av den reqiden.

Sjå på alle tre retningane. Utgåande og inngåande dekkjer trafikk til og frå denne verten; forward-retninga har noko å seia når verten rutar for andre. Ein manglande eller avvikande oppføring i éi retning forklarer eit einsretta resultat utan nokon kryptografisk feil.

Den klassiske asymmetrien: éin reqid for fleire subnett

Ein vanleg feil kjem frå ein peer som installerer policyar for alle forhandla subnett under éin einaste reqid, noko som skjer med racoons generate_policy require. Trafikken går då ut gjennom den assosiasjonen som vart oppretta sist, medan den andre sida held på ein eigen assosiasjon per subnett. Svar kjem inn på ein assosiasjon der reqiden ikkje peikar på policyen som burde godta dei, og kjernen forkastar dei etter dekryptering.

Løysinga er ei konfigurasjonsendring, ikkje ein brannmurregel: generate_policy unique; gir kvar policy sin eigen reqid, slik at peerens assosiasjonar per policy har passande partnarar. Bruk det, forhandle på nytt, og tel dei distinkte reqid-ane for subnetta du ventar før du erklærer suksess.

Viss to subnett framleis deler ein reqid medan den andre sida ventar to, har du funne asymmetrien. Skriv ned koplinga, for ho er beviset på om den neste endringa retta henne eller bevarte henne.

Selectors kjem frå forhandlinga, ikkje frå konfigurasjonen din

Dei verna områda er det båe endar vart samde om, ikkje det ei av sidene bad om. Ein klient som tilbyr eit vertspar mot eit breitt eksternt område, får den innsnevra versjonen til gatewayen, og klienten kan ikkje utvida han. Les dei installerte selectors i staden for dei i den lokale fila.

Når målet er det motsette, å halda éin destinasjon utanfor tunnelen, legg til ein bypass-policy med eit lågare prioritetsnummer slik at han vinn over den automatisk installerte oppføringa. Ein policy utan mal tillèt klartekst, noko som gjer han til eit medvite unntak for ei endringslogg i staden for eit feilsøkingstrinn.

Kontroller i denne rekkefølgja, og vit korleis du rullar tilbake

List policyar for kvart subnett i båe retningar, inkludert forward viss verten rutar. Tel distinkte reqids og stadfest éin per policy på sida som ventar det. Samanlikn installerte selectors med dei forhandla. Les teljarar per assosiasjon på nytt etter ein rekey, for assosiasjonen du undersøkte kan alt vera borte. Kontroller ruter til slutt, sidan ei manglande rute til det eksterne subnettet gir eit liknande einsretta symptom med reine policyteljarar.

Før du endrar peeren, lagre den gjeldande utskrifta frå båe xfrm-kommandoane. Viss den nye innstillinga ikkje gjenopprettar returretninga, er det å gjenoppretta den utskrifta ei raskare tilbakerulling enn å byggja tunnelen på nytt frå minnet, og det held samanlikninga ærleg.

Relaterte artiklar