L2TP/IPsec huts egiten du: bereizi IPsec, tunelaren autentifikazioa edo PPP saioa

L2TP/IPsec konexio bakar baten barruan hiru gauza autentifikatzen dira, eta horietako bakarra da markatzen duen pertsonari dagokiona. IPsec-ek tunelaren muturrak frogatzen ditu, L2TP kontrol-konexioak pareak berriro froga ditzake bere sekretu propioarekin, eta gero PPPk saioaren barruko erabiltzaile-kontua frogatzen du. Edozein etapatan huts eginez gero, saio-hasierako errore orokorra dirudi bezeroaren elkarrizketan, eta erabat desberdina dirudi zerbitzariaren erregistroan. Egin etapak ordenean eta gelditu huts egiten duen lehenengoan, probatu gabeko etapa baten azpiko etapa guztiak ere probatu gabeak baitira.

Hiru autentifikazio-etapa, hiru identitate desberdin

IPsec-ek muturren jabea nor den frogatzen du, aurrez partekatutako gako edo ziurtagiri baten bidez. Identitate hori makina edo pasabideena da, inoiz ez teklatuaren aurrean dagoen pertsonarena. Pareek etapa honetan ados jarri ezin badira, ez da L2TP paketerik trukatzen.

L2TP kontrol-konexioak bigarren erronka-erantzun truke bereizi bat gehi dezake, bi muturrek eduki behar duten sekretu partekatu batek bultzatuta.

RFC 2661ek kontrol-konexioko autentifikazio hori hautazko egiten du, eta horrek azaltzen du zergatik ematen duen errore berak sintoma desberdinak bi zerbitzaritan. Tunel-sekretua inoiz konfiguratu ez duen hedapenak etapa guztiz saltatzen du; alde bakarrean konfiguratu duenak PPP inoiz eskaini aurretik huts egiten du. Gero PPPk PAP, CHAP edo MSCHAPv2 erabiliz autentifikatzen du erabiltzailea, eta izena kontu-biltegi batera pasatzen du; biltegia lokala izan daiteke, chap-secrets-en edo RADIUSen. Une horretan pasahitz okerrak tunel funtzionamenduan eta saio huts eginda uzten zaitu oraindik.

Irakurri gelditzeko puntua konfigurazioa editatu aurretik

Hasi ipsec --version-ekin, jakin dezazun egoera-irteera strongSwanena edo Libreswanena den. Gero irakurri zerbitzariaren erregistroa, ez bezeroaren elkarrizketa, zerbitzariak erregistratzen baitu zein etapak uko egin dion.

Lerro batek erabakitzen du txartela normalean: IKE edo proposamenen inguruko kexa lehen etapa da, kontrol-konexioko mezua bigarrena da, eta PPP metodo edo kontu baten ukapena hirugarrena da. Kopiatu lerro hori txartelera denbora-markarekin. Bezeroaren aldetik asmatzeak jada daukazun froga bakarra alferrik galtzen du.

Eduki gako-materiala eta pasahitzak itsaste horretatik kanpo; etaparen izenak bideratzen du lana, eta filtratutako aurrez partekatutako gako batek txartela berriro irekitzen du ondorio okerragoekin.

Lehen urratsa: badu IPsec-ek elkarterik?

Exekutatu ipsec statusall strongSwanen edo ipsec whack --status Libreswanen, eta bilatu ezarritako ume-elkarte bat zero ez diren kontagailuekin. ip xfrm state-ek nukleoaren ikuspegia erakusten du bietan. Instalatutako SA pare batek kontagailuak igoz gero, lehen etapa eginda dago eta aurrera egin dezakezu.

Elkarterik ez egoteak parearen helbidera, proposamen-multzorik edo aurrez partekatutako gakora seinalatzen du, eta batzuetan UDP 500 berridazten duen baina UDP 4500 botatzen duen gailu batera. Ezarri eta segundo gutxiren buruan desagertzen den elkarteak, normalean, bi muturren arteko bizitzaren desadostasuna islatzen du, ez kredentzialen arazoa. Egiaztatu bi aldeek enkriptatze- eta hash-proposamen berberak zerrendatzen dituzten, ezer berridazten hasi aurretik. Ez badute, inoiz ez du gako batek ere funtzionatuko.

Gelditu elkartea falta den bitartean. Une horretan PPP aukerak editatzeak ez du ezer aldatzen eta hurrengo pertsonari benetako matxura ezkutatzen dio.

Bigarren urratsa: autentifikatu da L2TP kontrol-konexioa?

IPsec martxan dagoenean, begiratu L2TP deabrua kontrol-konexio bat ezarritako egoerara iristen ote den, PPPk ezin baitio horren aurretik hasi. Kontrol-konexioan uko egiteak esan nahi du tunel-sekretua desberdina dela muturren artean, edo mutur batek besteak inoiz bidaltzen ez duen sekretu bat eskatzen duela. Bezeroek sarritan sekretu partekatu gisa etiketatutako eremu bakarra erakusten dute, eta hori normalean IPsec-ena izaten da, ez L2TP-rena. Hura betetzeak ez du tunel-sekretua konfiguratzen, eta hura garbitzeak ez du desgaitzen.

Bi aldeek tunel-sekreturik konfiguratuta ez badute, saltatu etapa hau eta tratatu kontrol-konexioko hutsa irisgarritasun-arazo gisa. Egiaztatu UDP 1701 deabrura iristen dela eta bi muturrak enkapsulazio berarekin ados daudela. Bi baldintzetako batentzat idatzitako suebaki-araua erdi-irekitzen den konexio baten ohiko arrazoia da.

PPP negoziatzen hasten den saioak bakarrik gainditu du tunelaren etapa benetan.

Hirugarren urratsa: ukatzen al du PPPk kontua?

PPPren hutsak beste modu batera ematen du kanpotik: tunela ezarrita dago, saioa hasten da, eta deabruak autentifikazio-metodoaren hutsegitea edo kontuaren ukapena erregistratzen du. Irakurri mezu horretan izendatutako metodoa. PAP eta CHAP arrazoi desberdinengatik huts egiten dute, eta bat ukatzen duen zerbitzariak soilik hura eskaintzen duen bezero bati uko egingo dio.

Linux zerbitzari batean, aztertu deabruak PPPri pasatzen dion aukera-fitxategia, normalean /etc/ppp/options.xl2tpd, eta egiaztatu zein metodo onartzen diren eta non ebazten diren kontuak. RADIUSen badagoen baina tokiko sekretu-fitxategian ez dagoen izen batek garbiro huts egiten du eta pasahitz txarra dirudi. Gero egiaztatu bezeroak zerbitzariak onartzen duen metodo bat eskaintzen duela, zerbitzariak negoziatzeari uko egiten dion indartsuago bat eskaini beharrean. Etapa hau konpontzeko aurrez partekatutako gakoa aldatzeak arratsalde bat galtzen du eta ez du ezer aldatzen.

Saioa azkenean altxatzen denean, helbide-esleipena, DNSa eta ibilbideak oraindik ez daude egiaztatuta, eta bakoitzak isilean huts egiten du bere erara. Eutsi hiru geruzak bereizita zure oharretan: gako zuzenak kontu okerrarekin beti huts egiten du, eta geruza bat konpontzeak ez du inoiz beste bat konpontzen.