Fem adresseroller i en IPsec-profil, og hvilken der er forkert

Fem forskellige opgaver får en adresse i en typisk forbindelsesdefinition, og de behøver ikke at stemme overens. Administratorer går i stå, fordi en fornuftig tilskyndelse, at pege alle felterne mod den samme vært, er forkert for mindst tre af dem. Vejen ud er først at navngive symptomet og derefter se på det ene eller de to felter, der kunne fremkalde det.

De fem opgaver i den rækkefølge, de betyder noget

Transportendepunktet er der, hvor IKE-udvekslingen leveres. Den godkendte identitet er det navn, hver side beviser, og det kontrolleres mod politik og ikke mod en routingtabel. De beskyttede undernet er de selektorer, der afgør, hvilken indre trafik der hører til tunnelen. Så er der kilden, der bruges, når gatewayen selv starter en samtale, og til sidst næste hop i underlaget for at nå peer'en.

Deltageretiketter som left og right er konventioner for to sider af en forbindelse, ikke synonymer for lokal og fjern. Læs manualen for den implementering, der faktisk er installeret, før du antager, at en nøgle betyder det, et andet produkt mente med den.

Beslutning et: intet etableres

Når der slet ingen udveksling vises i loggene, er endepunktet den første mistænkte: en forkert adresse, en filtreret vej eller et interface, som dæmonen ikke lytter på. Skift først til identitetsfelterne, når et håndtryk er synligt, fordi identitet vurderes inde i udvekslingen og ikke før den. En filtreret vej og en forkert adresse ser identiske ud fra klienten, så kontroller den lyttende side, før du redigerer noget. Bekræft, at dæmonen er bundet til det interface, du forventer, fordi en tjeneste, der lytter på én adresse, ser præcis ud som en blokeret vej.

En offentlig adresse observeret gennem oversættelse er ikke det samme som den identitet, en peer beviser. At ændre en adresse, så den passer til det, en pakkefangst viser i den fjerne ende, er en almindelig og forkert rettelse.

Beslutning to: tunnelen er oppe, og trafikken dør

Selektorer afgør, hvad der kommer ind i tunnelen, og en uoverensstemmelse her giver en forbindelse, der forhandler med succes, mens applikationen stadig fejler. Den fjerne side skal navngive dit beskyttede område som sit fjernområde, og det er præcis der, omvendte værdier sniger sig ind.

Læs begge konfigurationer side om side, før du redigerer. Det lokale område på den ene vært er fjernområdet på den anden, og et enkelt ombyttet par forklarer en tunnel, der ikke bærer noget. Indsnævr parret, før du rører ved nøglerne: et undernet inde i tunnelen og et udenfor fortæller dig, om det er selektoren eller routing, der er skyld i det.

Beslutning tre: kun gatewayens egen trafik fejler

Trafik videresendt for klienter kan fungere perfekt, mens en anmodning, gatewayen selv starter, fejler, fordi den strøm ikke har nogen klientkilde at arve. Indstillingen for foretrukken kilde findes netop til dette tilfælde, og den er ikke kildeoversættelse: den vælger en kildeadresse i stedet for at omskrive en.

En applikation, der udtrykkeligt binder en anden adresse, kan tilsidesætte præferencen, så bekræft pakkens faktiske kilde, før du konkluderer, at indstillingen ignoreres. Fang på gatewayens eget interface i stedet for at stole på konfigurationens hensigt.

Næste hop er en lokal instruks

Næste hop i underlaget fortæller denne vært, hvordan peer'en nås, og den fjerne side har ikke brug for den samme værdi. At behandle det som en delt indstilling eller hardcode en standardgateway går i stykker i det øjeblik, ruten ændres, eller en anden vej dukker op.

Nogle implementeringer tilbyder særlige værdier her. Det, manualen angiver for den installerede version, er det eneste sikre svar, og den lokale routingtabel er beviset på, at det virkede. Når en peer kan nås på navn men ikke på adresse, er den uoverensstemmelse fundet, ikke en detalje at arbejde udenom.

Læs profilen fra begge ender

At vende rollerne på papiret er den hurtigste gennemgang, der findes: byt de beskyttede områder, behold hver sides eget næste hop, og behold hver sides egen identitet. Alt, der ikke overlever byttet, er sandsynligvis tildelt den forkerte opgave.

Test derefter én strøm pr. rolle: nåbarhed mellem peers, en indre klientstrøm og en anmodning, der udgår fra gatewayen. Tre test fortæller dig, hvilken opgave der er tildelt forkert, uden at åbne konfigurationen igen. Føj resultatet til billetten ved siden af det felt, du ændrede, fordi den næste ingeniør møder den samme profil.