L2TP/IPsec mislearret: isolearje IPsec, tunnelautentikaasje of PPP-ynloggen

Trije saken autentisearje har yn ien L2TP/IPsec-ferbining, en mar ien fan harren belûkt de persoan dy't ynkilet. IPsec bewiist de tunnel-einpunten, de L2TP-kontrôleferbining kin de peers nochris bewize mei syn eigen geheim, en PPP bewiist dan it brûkersakkoart binnen de sesje. In mislearring yn hokker fazy dan ek liket op in generike oanmeldflater yn 'e kliïntdialooch en liket yn in serverlog folslein oars. Wurkje de fazen yn folchoarder ôf en stop by de earste dy't mislearret, want elke faze ûnder in net testte faze is ek net test.

Trije autentikaasjefazen, trije ferskillende identiteiten

IPsec bewiist wa't de einpunten besit, mei in foarôf dielde kaai of in sertifikaat. Dy identiteit heart by masines of gateways, nea by de minske oan it toetseboerd. As de peers it yn dizze faze net iens wurde, wurdt der hielendal gjin L2TP-pakket útwiksele.

De L2TP-kontrôleferbining kin in twadde, aparte útdaging-antwurd-útwikseling tafoegje, oandreaun troch in dield geheim dat beide kanten hawwe moatte.

RFC 2661 makket dy autentikaasje fan 'e kontrôleferbining opsjoneel, wat ferklearret wêrom't deselde flater op twa servers ferskillende symptomen jout. In ymplemintaasje dy't nea in tunnelgeheim konfigurearre hat, slacht de faze folslein oer; ien dy't it mar oan ien kant konfigurearre hat, mislearret foardat PPP ea oanbean wurdt. PPP autentisearret de brûker dan mei PAP, CHAP of MSCHAPv2 en jout de namme troch oan in akkoartopslach dy't lokaal wêze kin, yn chap-secrets, of op RADIUS. In ferkeard wachtwurd lit jo op dat punt noch altyd mei in wurkjende tunnel en in mislearre sesje sitten.

Lês it stoppunt foardat jo in konfiguraasje bewurkje

Begjin mei ipsec --version, sadat jo witte oft de statusútfier fan strongSwan of fan Libreswan is. Lês dêrnei de serverlog, net de kliïntdialooch, want de server registrearret hokker faze wegere.

Ien rigel beslist it ticket meastentiids: in IKE- of foarstelklacht is faze ien, in berjocht oer de kontrôleferbining is faze twa, en in PPP-metoade- of akkoartôfwizing is faze trije. Kopiearje dy rigel mei de tiidstimpel yn it ticket. Gokken fan 'e kliïntkant ôf fergriemt it iene bewiisstik dat jo al hawwe.

Hâld kaaimateriaal en wachtwurden bûten dy plakactie; de fazenamme rjochtet it wurk, en in útlekte foarôf dielde kaai iepenet it ticket op 'e nij mei slimmere gefolgen.

Stap ien: hat IPsec in assosjaasje?

Fier ipsec statusall út op strongSwan of ipsec whack --status op Libreswan en sykje nei in fêstige bernelingsassosjaasje mei tellers dy't net nul binne. ip xfrm state toant by beide de werjefte fan 'e kernel. In ynstalleare pear SA’s mei oprinnende tellers betsjut dat faze ien klear is en jo fierder kinne.

Gjin assosjaasje hielendal wiist op it peeradres, de foarstelset of de foarôf dielde kaai, en soms op in apparaat dat UDP 500 oanskriuwt wylst it UDP 4500 falle lit. In assosjaasje dy't ta stân komt en dan nei in pear sekonden ferdwynt, is meast in libbensdoer-mismatch tusken de beide kanten ynstee fan in probleem mei de oanmeldgegevens. Kontrolearje oft beide kanten deselde fersiferings- en hashfoarstellen listje foardat jo wat oertype. As se dat net dogge, sil gjin inkele kaai ea wurkje.

Stop salang't de assosjaasje ûntbrekt. It bewurkjen fan PPP-opsjes feroaret op dat punt neat en ferberget de echte fout foar de folgjende persoan.

Stap twa: hat de L2TP-kontrôleferbining him autentisearre?

As IPsec ienris oerein is, hâld de L2TP-daemon yn 'e gaten foar in kontrôleferbining dy't in fêstige steat berikt, want PPP kin dêrfoar net begjinne. In wegering op 'e kontrôleferbining betsjut dat it tunnelgeheim tusken de kanten ferskilt, of dat ien kant in geheim easket dat de oare nea stjoert. Kliïnten biede faak ien fjild oan mei it label shared secret, en dat heart normaal by IPsec ynstee fan by L2TP. It ynfoljen derfan konfigurearret it tunnelgeheim net, en it wiskjen derfan skeakelt it net út.

As gjin fan beide kanten in tunnelgeheim konfigurearre hat, slach dan dizze faze oer en behannelje in mislearring fan 'e kontrôleferbining ynstee as berikberens. Kontrolearje dat UDP 1701 de daemon berikt en dat beide kanten it iens binne oer deselde ynkapseling. In firewallregel skreaun foar ien fan dy beide betingsten is in folsleine oarsaak fan in ferbining dy't heal iepenet.

Allinnich in sesje dy't PPP begjint te ûnderhanneljen hat de tunnelfaze echt helle.

Stap trije: wiist PPP it akkoart ôf?

In PPP-mislearring sjocht der fan bûten oars út: de tunnel is fêstige, de sesje begjint, en de daemon registrearret in mislearring fan in autentikaasjemetoade of in akkoartôfwizing. Lês de metoade dy't yn dat berjocht neamd wurdt. PAP en CHAP mislearje om ferskillende redenen, en in server dy't ien wegeret, sil in kliïnt ôfwize dy't allinnich dy iene oanbiedt.

Besjoch op in Linux-server it opsjebestân dat de daemon oan PPP jout, meastentiids /etc/ppp/options.xl2tpd, en befêstigje hokker metoaden akseptearre wurde en wêr't akkoarten oplost wurde. In namme dy't yn RADIUS bestiet mar net yn it lokale geheimbestân, mislearret skjin en liket op in ferkeard wachtwurd. Kontrolearje dan dat de kliïnt in metoade oanbiedt dy't de server akseptearret, ynstee fan in sterkere dy't de server wegeret te ûnderhanneljen. It feroarjen fan 'e foarôf dielde kaai om dizze faze te reparearjen fergriemt in middei en feroaret neat.

As de sesje úteinlik ta stân komt, adresopdracht, DNS en rûtes binne noch net kontrolearre, en elk mislearret stil op syn eigen wize. Hâld de trije lagen apart yn jo notysjes: in krekte kaai mei in ferkeard akkoart mislearret altyd, en it reparearjen fan ien laach reparearret nea in oare.