Inkomende IPsec-eweknie pas by geen profiel nie? Kontroleer vier velde

Jou eweknie rapporteer dat die tonnel op is, jou kant wys geen sekuriteitsassosiasie nie, en die konfigurasielêer bevat duidelik 'n passende verbindingsnaam. Daardie drie stellings kan almal waar wees. 'n Inkomende onderhandeling word teen die lopende konfigurasie gepas, met die eweknie se adres, die identiteit wat dit voorhou en die verkeer wat dit voorstel. 'n Lêer op skyf wat nooit gelaai is nie, 'n identiteit wat nie met die verwagte waarde ooreenstem nie, of 'n keurderpaar wat met een voorvoegsel verkeerd is, sal elkeen stilte lewer. Gaan die vier veldbundels in die volgorde na wat die antwoorder volg.

Begin by die pakkie, nie by die lêer nie

Die antwoorder ontvang 'n IKE-versoek, soek 'n definisie wat hierdie eweknie kan aanvaar, en gaan dan voort met verifikasie en verkeerskeuse. As geen gelaaide definisie by die eerste stap pas nie, eindig die onderhandeling voordat enige nuttige fout die gebruiker bereik.

Daarom is “die konfigurasie lyk reg” nie bewys nie. Die vraag is wat die lopende diens gelaai het en watter inskrywing dit vir hierdie poging gekies het. 'n Statuslys beantwoord dit in een opdrag, terwyl 'n redigeerderbuffer 'n ander vraag beantwoord. Kontroleer die lys voordat jy die lêer weer verander.

Veldbundel een: die definisie wat werklik gelaai is

Kontroleer die lopende toestand met die gereedskap wat die daemon besit: 'n statusopdrag wat gelaaide verbindings lys, nie die redigeerderbuffer nie. Bevestig dat die inskrywing wat jy verwag teenwoordig is, geaktiveer is vir die outomatiese gedrag wat jy beoog, en gelaai is ná jou laaste wysiging. 'n Gestoor lêer wat nie herlaai is nie, is die mees algemene oorsaak van “ek het dit reggemaak en niks het verander”.

Bevestig ook watter lêer die diens lees. Verspreidings verskil, en 'n verbinding wat in die verkeerde insluiting geskryf is, word stilweg geïgnoreer eerder as verwerp. As die statuslys jou inskrywing glad nie wys nie, vermoed die insluitingspad voordat jy die sintaks vermoed.

Veldbundel twee: eindpunte is nie identiteite nie

Die adres waarvandaan die eweknie verbind en die identiteit waarmee dit verifieer, is aparte velde. 'n Gasheernaam, 'n onderskeidende naam, 'n sleutel-ID en 'n adres kan almal as 'n IKE-identiteit dien, afhangend van die konfigurasie, en hulle hoef glad nie soos die openbare adres te lyk nie.

Eindpuntpassing kan ook 'n NAT-sienswy betrek: die adres wat op die draad gesien word, kan verskil van die adres wat die eweknie dink hy het. In libreswan se verbindingsmodel is links en regs etikette vir die twee deelnemers eerder as 'n vaste plaaslike en afgeleë volgorde, en daarom is die kopiëring van 'n werkende konfigurasie van 'n ander terrein en die omruiling van die adresse nie 'n betroubare vertaling nie.

Skryf beide kante se verwagte identiteit en die geloofsbrief wat dit valideer neer. As daardie twee reëls verskil, sal geen hoeveelheid adresverstelling 'n passing lewer nie.

Veldbundel drie: die verkeer wat beskerm word

Keurders beskryf die innerlike bron- en bestemmingsreekse, hul adresfamilie en enige protokol- of poortbeperking. 'n Voorstel vir een gasheeradres is nie dieselfde versoek as 'n hele subnet nie, en 'n antwoorder wat vir die subnet opgestel is, kan dit van die hand wys of vernou.

Wanneer die twee kante verskil, vergelyk die beoogde vloei vanuit beide standpunte eerder as om elke keurder te verbreed om iets te laat verbind. Vra elke administrateur na die vloei wat hulle dink hulle beskerm, en diff dan die twee antwoorde. Die wanverhouding is gewoonlik 'n gasheer-voorvoegsel aan die een kant en 'n subnet aan die ander. 'n Tonnel wat pas omdat dit nou alles beskerm, is 'n ander sekuriteitsbesluit, en een wat niemand goedgekeur het nie.

Veldbundel vier: jy lees een implementering

Libreswan, ouer Openswan en strongSwan het verskillende bestuursgereedskap, verskillende konfigurasiesintaks en verskillende passingsvolgorde. 'n Werkende voorbeeld van een sê niks presies oor 'n ander se profielkeuseprioriteit of sy foutbewoording nie, so verifieer met die dokumentasie vir die daemon op hierdie gasheer.

Korreleer een poging van begin tot einde: die inisieerder se bronadres, aangebode identiteit en voorgestelde keurders, teen die antwoorder se keuseboodskap en die gelaaide inskrywing wat dit noem. Nul-inkapselings- en dekapsuleertellers sê net dat die waargenome assosiasies daardie pakkies nie gedra het nie; hulle noem nie die eindpunt wat die voorstel verwerp het nie en bewys nie dat 'n passende inskrywing op daardie oomblik bestaan het nie.

Bevestig ná 'n gekoördineerde regstelling die gekose profiel en assosiasie, en oefen dan die werklike toegelate diens en sy antwoordpad. 'n Profielpassing maak onderhandeling moontlik, en onderhandeling is nie die laaste toegangsbeheer nie.