Kiu VPN-etapo malsukcesis: IPsec, L2TP-kontrolo aŭ PPP-aŭtentigo

Vi ŝanĝis la pasvorton kaj nenio moviĝis, ĉar la paneo neniam estis en PPP. L2TP/IPsec raportas unu konekteraron por kvin tute malsamaj transdonoj, kaj ĉiu transdono havas sian propran riparon. Laboru malantaŭen: trovu la lastan etapon kiu sukcesis kaj ŝanĝu nur tion, kio venas post ĝi. La suba ordo ankaŭ decidas, kiujn pruvojn vi kolektas unue.

Respondu kvar demandojn laŭvice

Trudu novan provon, ĉar iuj klientoj daŭre montras la antaŭan eraron ĝis la profilo malkonektiĝas kaj rekonektiĝas. Poste respondu ĉi tion: ĉu ekzistis IPsec-sekureca asociiĝo, ĉu aperis L2TP-kontrolkonekto kaj voko, ĉu PPP atingis aŭtentigan verdikton, kaj ĉu IPCP donis adreson al la kliento? La unua ne estas la etapo, kiun vi riparas. Ĉio post ĝi estas netestita, do malakceptita uzantnomo pruvas nenion kiam asociiĝo neniam ekzistis.

Sinkronigu la horloĝojn ĉe ambaŭ finoj antaŭ ol kompari. Repeto, kiu purigis IPsec kaj malsukcesis ĉe PPP, aspektas kiel unu sola paneo kiam la kliento montras nur la finan mesaĝon kaj la servila protokolo ankoraŭ tenas la antaŭan provon. Legu laŭ tempindiko, ne laŭ la plej laŭta linio.

Kiam vi havas nur la ekrankopion de la uzanto, apogu vin sur la plej malmultekosta disigo: malĝusta antaŭdividita ŝlosilo kaj xl2tpd kiu neniam respondas produktas la saman tekston en la Windows-dialogo, tamen unu bezonas sekreton ŝanĝitan ĉe ambaŭ finoj kaj la alia bezonas demonon lanĉitan aŭ fajroŝirmilan regulon sur la servilo mem. Aparato en la mezo ne povas forĵeti la internan 1701 post kiam IPsec en transporta reĝimo ĉirkaŭvolvis ĝin, do ne serĉu vojfiltron kiu ne ekzistas.

Kion ĉiu tavolo vere posedas

IPsec protektas pakaĵojn inter la du samtavoloj; L2TP portas PPP-sesion ene de tiu protektita vojo, pro kio RFC 3193 specifas transportan reĝimon anstataŭ propran tunelon. La klienta etikedo diras L2TP, do la tunelo kaj la ensaluto ŝajnas unu mekanismo. Ili ne estas: la L2TP-kontrolkonekto aŭtentigas la tunelajn finpunktojn kie deplojo tion ebligas, kaj PPP aparte aŭtentigas la uzanton per CHAP, PAP aŭ MS-CHAPv2 laŭ servila politiko.

Tiu disigo klarigas la du sekretojn, kiujn homoj daŭre konfuzas. Antaŭdividita ŝlosilo aŭtentigas la IPsec-samtavolojn. Uzantnomo kaj pasvorto identigas la uzanton al PPP. Retajpi la komunan sekreton de Windows sur profilo, kiu aŭtentiĝas per atestiloj, ŝanĝas nenion ĉe la malsukcesanta etapo, kaj redakti la PPP-pasvorton ne povas provizi mankan protektitan kanalon. La sama sindetenemo validas por la identa kontrolo: ne malŝaltu samtavolan identecon aŭ atestilan validigon por akiri tunelon, ĉar tiam konektiĝas la vojo, ne la samtavolo.

Ankaŭ aŭtentigo ne estas la fino de PPP. Post kiam la uzanto akceptiĝas, IPCP intertraktas la klientan adreson kaj la DNS- kaj WINS-opciojn, kiujn la servilo pretas doni. Kliento povas trapasi CHAP aŭ MS-CHAPv2 kaj tamen fini sen adreso, kio estas paneo interne de PPP kaj ne vojiga problemo. Simpla L2TP sen IPsec restas valida kaj neprotektita, do sukcesa konekto neniam pruvas, ke la trafiko estas protektita; kontrolu, kion la servilo postulas, ne la etikedon de la kliento.

Decidu laŭ la unua mankanta etapo

Legu la tabelon laŭ la unua mankanta ero, de maldekstre dekstren. La dekstra kolumno estas la sola laboro inda je tiu momento; ĉio maldekstre de ĝi jam estas pruvita, kaj retestado bruligas la interrompan fenestron sen aldoni informon.

Tri vicoj meritas averton. La vico 1701 estas kie Windows-klientoj malantaŭ NAT kutime alteriĝas: la asociiĝo kompletiĝas, poste nenio alvenas, kaj la enkapsuligo estas la kaŭzo, ne malbona pasvorto. La vico IPCP estas tiu, kiu estas mislegata kiel vojiga problemo, ĉar Windows envolvas mankantan adreson en eraron 720 kaj la pleto-ikono nur diras, ke la konekto malsukcesis; tiu paneo sidas post aŭtentigo kaj antaŭ vojigo. La lasta vico tute ne estas IPsec-paneo, kvankam la pleto-ikono diras malkonektita.

Komandoj, kiuj apartigas la tavolojn

Sur Linux-servilo kun strongSwan, swanctl --list-sas listigas establitajn asociiĝojn kun ilia samtavola identeco, kaj ipsec statusall kovras pli malnovajn strongSwan- kaj libreswan-gastigantojn. Sube, ip xfrm state montras la faktajn asociiĝojn de la kerno, dum ss -lunp | grep 1701 pruvas, kie xl2tpd estas ligita. Rulu xl2tpd -D en la malfono por vidi kontrolkonektojn kaj vokojn aperi, kaj ŝaltu pppd-sencimigon en /etc/ppp/options.xl2tpd por vidi la proponitan metodon kaj la respondon.

Kiam la protokoloj montras sukcesan aŭtentigon, la sekva demando estas, ĉu IPCP kompletiĝis. Kontrolu, ĉu ip range en la sekcio [lns default] de /etc/xl2tpd/xl2tpd.conf ankoraŭ havas liberajn adresojn, kaj ĉu /etc/ppp/options.xl2tpd efektive portas ms-dns kaj ms-wins se la kliento atendas ilin. Elĉerpita baseno kaj mankanta DNS-opcio aspektas malsame sur la drato: la unua lasas la klienton sen adreso kaj kun 720, la dua donas adreson sed neniun solvilon, do nomoj malsukcesas dum ping al krudaj adresoj funkcias. Neniun el ili riparas reentajpo de la pasvorto.

Ĉe la kliento, la NetworkManager-L2TP-kromaĵo skribas la pppd-konversacion en la ĵurnalon, do journalctl -u NetworkManager -b kutime apartigas tunelo supre, aŭtentigo rifuzita de neniu tunelo entute. Sur Windows, Get-VpnConnection raportas la efektivajn aŭtentigajn agordojn de la profilo, kaj la RasClient-eventoj sub Application en Event Viewer nomas la malsukcesantan komponanton. Kiam la dialogo estas tro malklara, ŝaltu netsh ras set tracing * enable.

Kaptaĵoj bezonas unu singardemon. Kun IPsec en transporta reĝimo la interna UDP 1701 estas ĉifrita, do kaptaĵo sur la ekstera interfaco montras ESP, aŭ UDP 4500 sub NAT-T, kaj tute neniun L2TP. Mankanta 1701 en kaptaĵo estas atendata kaj ne pruvo de blokita pordo; observu, ĉu la ESP- aŭ 4500-kalkuliloj moviĝas.

NAT, MTU kaj vojoj: kie la stako trompas vin

NAT rompas supozojn antaŭ ol io ajn estas aŭtentigita. ESP estas propra IP-protokolo, do tradukanta aparato forĵetas ĝin krom se la samtavoloj enkapsuligas; tion provizas UDP 4500. Sur Windows-servilo, kiu mem staras malantaŭ hejma enkursigilo aŭ nuba NAT-pordego, la IPsec-etapo malsukcesas per eraro 789 ĝis AssumeUDPEncapsulationContextOnSendRule estas agordita al 2 sub la PolicyAgent-ŝlosilo kaj la maŝino restartiĝas, kaj la paneo restas nedistingebla de fermita pordo. Klientoj malantaŭ NAT estas pli facilaj: kun publika adreso sur la servilo, NAT-T sur UDP 4500 portas ilin kaj tiu valoro ne partoprenas.

Post kiam PPP supre, MTU kun nigra truo imitas mortan tunelon: malgrandaj pakaĵoj trapasas, TLS-manpremo aŭ paĝa ŝarĝo pendas, kaj la kliento eble ankoraŭ montras konektita. Malaltigu la interfacan MTU aŭ fiksu MSS ĉe la pordego antaŭ ol kulpigi la servilon. Split-tunnel-vojigo estas la alia trompanto; subreto sendita kun malĝusta masko lasas la tunelon sana kaj unu aplikaĵon neatingebla. Privata gastignomo aldonas sian propran paŝon: se la demando eliras tra la loka solvilo, la nomo malsukcesas solviĝi antaŭ ol iu vojo testiĝas.

Kontrollisto antaŭ ol tuŝi akreditaĵojn

Laboru la liston laŭorde kaj haltu ĉe la unua malsukcesanta ero. Ĉiu paŝo estas malmultekosta, kaj ĉiu el ili ekskludas tutan klason da ŝanĝoj.

1. Konfirmu, ke la asociiĝo ekzistas ĉe ambaŭ finoj, parigita laŭ samtavola identeco anstataŭ konektita-etikedo.
2. Konfirmu, ke UDP 1701 atingas xl2tpd; asociiĝo sen voko estas via paneo.
3. Legu la verdikton de PPP, kaj se ĝi aŭtentigis, la IPCP-rezulton, antaŭ ol supozi, ke la pasvorto malĝustas.
4. Nur nun reentajpu akreditaĵojn en la formato, kiun la servilo atendas, ĉar domajna prefikso ŝanĝas la konton.
5. Se ĝi ankoraŭ malsukcesas, kaptu ambaŭ finojn kun vicigitaj tempindikoj kaj komparu etapon post etapo.

Halti ĉe la dua paŝo signifas voj- aŭ enkapsuligan problemon, kaj neniu pasvorta ŝanĝo movos ĝin. Halti ĉe la tria paŝo signifas, ke la protokolo jam nomas la metodon aŭ la adresan basenon riparindan. En ambaŭ kazoj la sekva ŝanĝo estas tiu, kiun vi povas pravigi, kaj vi ĉesas cikli tra agordoj, kiuj neniam partoprenis.