L2TP se povezuje, ali PPP pregovaranje ne uspijeva: koja faza?

IPsec tunel se uspostavi, klijent pokaže zaštićenog partnera, a zatim veza umre prije nego išta stigne do privatne podmreže. Taj jaz je PPP koji obavlja svoj vlastiti posao: opcije veze, autentifikacija korisnika i dodjela adrese sve se događa nakon što šifrirani tunel već postoji. Ništa u uspješnoj razmjeni prve faze ne daje lozinku ni unutrašnju adresu. Čitajte faze po redu i kvar obično sam sebe imenuje.

Tunel je samo prvi sloj

L2TP prenosi PPP okvire unutar tunela zaštićenog IPsec-om, što znači da dva nezavisna pregovaranja moraju uspjeti prije nego se paket može rutirati. Vanjsko dokazuje da se oba kraja slažu o ključevima i identitetima. Unutrašnje odlučuje o parametrima veze, o tome autentificira li se korisnik i koju adresu klijent dobiva.

Kvar unutar PPP-a izgleda kao slomljen tunel u svakom klijentu koji prikazuje samo jedno statusno svjetlo. Ako ga tretiramo kao problem tunela, to vodi do ponovnog generiranja ključeva, restarta usluga i na kraju zamjene zajedničke tajne koja nikada nije bila pogrešna. Korisna razlika je jeftina: ako je razmjena s partnerom završena i klijent je prešao na upit za korisničko ime ili na fazu autentifikacije, tunel je u redu. Sve nakon te točke pripada PPP-u.

Pročitajte posljednju fazu koja je uspjela

Idite kroz zapisnik naprijed i zaustavite se na prvoj fazi koja nije završena. Prvo dolazi LCP, zatim autentifikacija, pa IPCP za IPv4 parametre.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Istek LCP-a znači da se dva kraja nikada nisu dogovorila o osnovnim opcijama veze, što je neusklađen profil ili blokiran unutrašnji protokol, a ne loša lozinka. Izričito odbijanje autentifikacije je suprotan slučaj: veza se podigla i jedna strana je odbila akreditive. Istek IPCP-a nakon uspješne autentifikacije upućuje na skupove adresa ili serversku politiku. Svaki od njih ima drugog vlasnika i drugu popravku, zato je faza važnija od konačnog teksta pogreške.

Držite isječak zapisnika zajedno s imenom faze u zahtjevu. Zalijepljeni rep bez granice faze poziva sljedećeg čitatelja na nagađanje, a nagađanje ovdje košta sat vremena.

Suglasje između klijenta i poslužitelja

Oba kraja moraju prihvatiti istu metodu autentifikacije, a spremljeni profil može tražiti onu koju je poslužitelj umirovio prošlog tromjesečja. Upravljane instalacije također skrivaju stranu poslužitelja, gdje se razlog odbijanja obično bilježi uz korisnika, a ne uz uređaj.

Omogućite jednu podržanu metodu umjesto svake naslijeđene opcije, jer klijent koji nudi pet metoda zamagljuje koja je pala. Zatražite od administratora politiku na strani poslužitelja i točno odbijanje, što ne zahtijeva da itko objavi lozinku. Naslijeđena metoda omogućena da spasi jedan klijent obično se proširi na svaki profil koji kopira datoteku.

Provjerite adresu, ne prijavu

Završena prijava nije upotrebljiva sesija. IPCP pregovara unutrašnju adresu, a iscrpljen skup ili politika koja odbija klijenta i dalje može ostaviti povezan tunel bez ičega za rutiranje.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Prvo provjerite unutrašnju adresu, zatim rutu i razrješivač za resurs koji vam stvarno treba. Unutrašnja adresa nije javni izlaz koji web-stranica prijavljuje, a brkanje to dvoje šalje ljude u lov na curenje kojeg nema. Testirajte privatni resurs po adresi prije nego po imenu, da se DNS kvar ne shvati kao kvar rutiranja.

Zapišite fazu, metodu i adresu u jednu bilješku i datirajte je. Ako isti račun ponovno padne za mjesec dana, ta bilješka je razlika između petominutne provjere i nove istrage. Kvarovi u različitim fazama različiti su incidenti, čak i kada klijent prikazuje samo jedan dijalog.