Dräi Saachen authentifizéieren sech an enger L2TP/IPsec-Verbindung, an nëmmen eng dovun betrëfft d'Persoun déi wielt. IPsec bewisen d'Tunnel-Endpunkten, d'L2TP-Kontrollverbindung kann d'Peeren nach eng Kéier mat sengem eegene Geheimnis bewisen, an duerno bewisen PPP de Benotzerkont an der Sessioun. En Ausfall op enger Stuf gesäit aus wéi e generesche Login-Fehler am Client-Dialog an an der Server-Log ganz anescht. Gitt d'Stufen der Rei no duerch a stoppt bei der éischter déi feelt, well all Stuf ënner enger ongetester och ongetest ass.

Dräi Authentifikatiounsstufen, dräi verschidden Identitéiten

IPsec bewisen wiem d'Endpunkten gehéieren, mat engem virgedeelte Schlëssel oder engem Zertifikat. Déi Identitéit gehéiert zu Maschinnen oder Gateways, ni dem Mënsch un der Tastatur. Wa sech d'Peeren op dëser Stuf net eens ginn, gëtt guer kee L2TP-Paket ausgetosch.

D'L2TP-Kontrollverbindung kann en zweeten, getrennten Challenge-Response-Austausch bäisetzen, dee vun engem gemeinsame Geheimnis gedriwwe gëtt, deen allebéid Enden hu mussen.

RFC 2661 mécht déi Kontrollverbindungs-Authentifikatioun optional, wat erkläert firwat dee selwechte Feeler op zwee Serveren ënnerschiddlech Symptomer gëtt. Eng Deployement dat ni en Tunnelgeheimnis konfiguréiert huet, iwwerspréngt d'Stuf komplett; een dat se nëmmen op enger Säit konfiguréiert huet, feelt ier PPP iwwerhaapt ugebuede gëtt. Duerno authentifizéiert PPP de Benotzer mat PAP, CHAP oder MSCHAPv2 an iwwergëtt den Numm un e Kontespeicher deen lokal, an chap-secrets oder op RADIUS ka sinn. En falscht Passwuert op deem Punkt loosst dech nach ëmmer mat engem funktionéierenden Tunnel an enger gescheiterter Sessioun.

Liest de Stoppunkt ier dir eng Konfiguratioun ännert

Fänkt mat ipsec --version un, fir ze wëssen ob d'Statusausgab zu strongSwan oder Libreswan gehéiert. Liest duerno d'Server-Log, net de Client-Dialog, well de Server festhält wéi eng Stuf refuséiert huet.

Eng Zeil entscheet meeschtens den Ticket: eng Plainte iwwer IKE oder Proposen ass Stuf een, eng Kontrollverbindungs-Message ass Stuf zwee, an eng Oflehnung vun der PPP-Method oder dem Kont ass Stuf dräi. Kopéiert déi Zeil mam Zäitstempel an den Ticket. Vum Client aus ze roden verschwënnt deen eenzegen Beweis deen dir schonn hutt.

Haalt Schlësselmaterial a Passwierder aus deem Paste eraus; den Numm vun der Stuf steiert d'Aarbecht, an en duerchgesickerten virgedeelte Schlëssel mécht den Ticket mat schlëmmere Konsequenzen nees op.

Éischt Stuf: huet IPsec eng Associatioun?

Féiert ipsec statusall op strongSwan oder ipsec whack --status op Libreswan aus a sicht eng installéiert Kand-Associatioun mat Zähler déi net null sinn. ip xfrm state weist d'Kernel-Siicht op béiden. En installéierte SA-Puer mat steigende Zähler heescht datt déi éischt Stuf fäerdeg ass an dir kënnt virugoen.

Keng Associatioun iwwerhaapt weist op d'Peer-Adress, de Propositiounsset oder de virgedeelte Schlëssel hin, an heiansdo op en Apparat deen UDP 500 ëmschreift an UDP 4500 fale léisst. Eng Associatioun déi sech opbaut an duerno no e puer Sekonnen verschwënnt ass meeschtens en Ongläichgewiicht vun der Liewensdauer tëscht den zwee Enden an net e Problem mat den Umeldungsdaten. Kontrolléiert ob béid Säiten déiselwecht Verschlësselungs- an Hash-Propositioune lëschten ier dir eppes nei tippt. Wann net, wäert kee Schlëssel jeemools funktionéieren.

Stoppt soulaang d'Associatioun feelt. D'PPP-Optiounen op deem Punkt z'änneren ännert näischt a verstoppt de richtege Feeler virun der nächster Persoun.

Zweet Stuf: huet sech d'L2TP-Kontrollverbindung authentifizéiert?

Soubal IPsec leeft, beobacht de L2TP-Daemon fir eng Kontrollverbindung déi en etabléierte Statut erreecht, well PPP virdru net kann ufänken. Eng Oflehnung op der Kontrollverbindung heescht datt d'Tunnelgeheimnis tëscht den Enden ënnerschiddlech ass, oder datt en Enn e Geheimnis verlaangt dat dat anert ni schéckt. Clienten weisen dacks ee Feld mam Label shared secret, an dat gehéiert normalerweis zu IPsec an net zu L2TP. Et auszefëllen konfiguréiert d'Tunnelgeheimnis net, an et ze läschen deaktivéiert et net.

Wann keng Säit en Tunnelgeheimnis konfiguréiert huet, iwwerspréngt dës Stuf a behandelt en Ausfall vun der Kontrollverbindung als Erreechbarkeetsproblem. Bestätegt datt UDP 1701 den Daemon erreecht an déi zwou Enner sech iwwer déiselwecht Kapselung eens sinn. Eng Firewall-Reeg déi fir eng vun deenen zwee Konditiounen geschriwwe gouf ass eng heefeg Ursaach vun enger Verbindung déi hallef opgeet.

Nëmmen eng Sessioun déi ufänkt iwwer PPP ze verhandelen huet d'Tunnelstuf wierklech passéiert.

Drëtt Stuf: lehnt PPP de Kont of?

En PPP-Ausfall gesäit vun dobaussen anescht aus: den Tunnel ass etabléiert, d'Sessioun fänkt un, an den Daemon loggt en Ausfall vun der Authentifikatiounsmethod oder eng Kontoflehnung. Liest d'Method déi an der Message genannt gëtt. PAP a CHAP feelen aus ënnerschiddleche Grënn, an e Server deen eng refuséiert wäert e Client refuséieren deen nëmmen déi ubitt.

Op engem Linux-Server kuckt d'Optiounsfichier déi den Daemon un PPP gëtt, typesch /etc/ppp/options.xl2tpd, a bestätegt wéi eng Methoden akzeptéiert ginn a wou Konten opgeléist ginn. En Numm deen an RADIUS existéiert awer net an der lokaler Geheimnisfichier feelt propper a gesäit aus wéi en falscht Passwuert. Kontrolléiert duerno datt de Client eng Method ubitt déi de Server akzeptéiert, an net eng méi staark déi de Server refuséiert ze verhandelen. De virgedeelte Schlëssel z'änneren fir dës Stuf ze reparéieren verschwënnt en Nomëtteg a ännert näischt.

Wann d'Sessioun endlech eropkënnt, d'Adressverdeelung, DNS an d'Routen sinn nach net gepréift, an all eenzelt feelt roueg op seng eege Manéier. Haalt déi dräi Schichte getrennt an Ären Notizen: e richtege Schlëssel mat engem falsche Kont feelt ëmmer, an eng Schicht ze reparéieren reparéiert ni eng aner.

Ähnlech Artikelen