L2TP се повезује, али PPP преговарање не успева: која фаза?

IPsec тунел се успоставља, клијент приказује заштићеног партнера, а затим веза умире пре него што било шта стигне до приватне подмреже. Тај јаз је PPP који обавља сопствени посао: опције везе, аутентификација корисника и додела адресе дешавају се након што шифровани тунел већ постоји. Ништа у успешној размени прве фазе не даје лозинку ни унутрашњу адресу. Читајте фазе по реду и отказ обично сам себе именује.

Тунел је само први слој

L2TP преноси PPP оквире унутар тунела заштићеног IPsec-ом, што значи да два независна преговарања морају успети пре него што се пакет може рутирати. Спољашње доказује да су оба краја сагласна око кључева и идентитета. Унутрашње одлучује о параметрима везе, да ли се корисник аутентификује и коју адресу клијент добија.

Отказ унутар PPP-а изгледа као сломљен тунел у сваком клијенту који приказује само једно статусно светло. Ако се третира као проблем тунела, то води ка поновном генерисању кључева, рестартовању услуга и на крају замени заједничке тајне која никада није била погрешна. Корисна разлика је јефтина: ако је размена са партнером завршена и клијент је прешао на захтев за корисничким именом или на фазу аутентификације, тунел је у реду. Све после те тачке припада PPP-у.

Прочитајте последњу фазу која је успела

Идите кроз дневник напред и зауставите се на првој фази која није завршена. Прво долази LCP, затим аутентификација, затим IPCP за параметре IPv4.

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

Истек времена за LCP значи да се два краја никада нису договорила о основним опцијама везе, што је неусаглашен профил или блокиран унутрашњи протокол, а не лоша лозинка. Изричито одбијање аутентификације је супротан случај: веза се подигла и једна страна је одбила акредитиве. Истек времена за IPCP после успешне аутентификације указује на скупове адреса или серверску политику. Сваки од њих има другог власника и другу поправку, зато је фаза важнија од коначног текста грешке.

Чувајте изводак из дневника заједно са именом фазе у тикету. Налепљен реп без границе фазе позива следећег читаоца на нагађање, а нагађање овде кошта сат времена.

Сагласност између клијента и сервера

Оба краја морају прихватити исти метод аутентификације, а сачувани профил може затражити онај који је сервер повукао прошлог квартала. Управљана распоређивања такође крију страну сервера, где се разлог одбијања обично бележи на корисника, а не на уређај.

Омогућите један подржани метод уместо сваке старе опције, јер клијент који нуди пет метода замагљује који није успео. Затражите од администратора политику на страни сервера и тачно одбијање, што не захтева да било ко објави лозинку. Стари метод омогућен да спасе једног клијента склон је ширењу на сваки профил који копира датотеку.

Проверите адресу, не пријаву

Завршена пријава није употребљива сесија. IPCP преговара о унутрашњој адреси, а исцрпљен скуп или политика која одбија клијента и даље могу оставити повезан тунел без ичега за рутирање.

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

Прво проверите унутрашњу адресу, затим руту и резолвер за ресурс који вам је заиста потребан. Унутрашња адреса није јавни излаз који сајт пријављује, и мешање тога двоје шаље људе у лов на цурење којег нема. Тестирајте приватни ресурс по адреси пре него по имену, да се отказ DNS-а не схвати као отказ рутирања.

Запишите фазу, метод и адресу у једну белешку и датирајте је. Ако исти налог поново не успе за месец дана, та белешка је разлика између петоминутне провере и нове истраге. Откази у различитим фазама су различити инциденти, чак и када клијент приказује један дијалог.