Која фаза VPN-а није успела: IPsec, L2TP контрола или PPP аутентификација
Пронађите последњу успешну фазу и поправите само тај слој: IPsec, контролни канал L2TP, PPP аутентификацију или доделу адресе.
Променили сте лозинку и ништа се није померило, јер квар никада није био у PPP-у. L2TP/IPsec пријављује једну грешку везе за пет сасвим различитих предаја, и свака предаја има своје поправљање. Радите уназад: пронађите последњу успешну фазу и мењајте само оно што долази после ње. Редослед испод такође одређује које доказе прво сакупљате.
Одговорите на четири питања по реду
Присилите нови покушај, јер неки клијенти показују претходну грешку док се профил не искључи и поново повеже. Затим одговорите: је ли постојала IPsec безбедносна асоцијација, јесу ли се појавили L2TP контролна веза и позив, је ли PPP дошао до одлуке о аутентификацији и је ли IPCP дао адресу клијенту? Прво не је фаза коју поправљате. Све после ње није тестирано, па одбијено корисничко име ништа не доказује када асоцијације никада није било.
Прекљопите часовнике на оба краја пре поређења. Покушај који је очистио IPsec и пао на PPP-у изгледа као један квар када клијент приказује само последњу поруку, а серверски дневник још чува претходни покушај. Читајте по временској ознаци, не по најгласнијем реду.
Када имате само снимак екрана корисника, ослоните се на најјефтиније раздвајање: погрешан унапред подељен кључ и xl2tpd који никада не одговара дају исти текст у дијалогу Windows-а, али једно захтева тајну промењену на оба краја, а друго покренут демон или правило заштитног зида на самом серверу. Уређај у средини не може да одбаци унутрашњи 1701 након што га је IPsec у транспортном режиму обмотао, зато не тражите филтер путање који не постоји.
Шта сваки слој заправо поседује
IPsec штити пакете између два партнера; L2TP носи PPP сесију унутар те заштићене путање, зато RFC 3193 прописује транспортни режим уместо сопственог тунела. Ознака клијента каже L2TP, па тунел и пријава делују као један механизам. Нису: L2TP контролна веза аутентификује крајеве тунела тамо где распоређивање то укључује, а PPP одвојено аутентификује корисника са CHAP, PAP или MS-CHAPv2 према политици сервера.
Ово раздвајање објашњава две тајне које људи стално мешају. Унапред подељен кључ аутентификује IPsec партнере. Корисничко име и лозинка идентификују корисника пред PPP-ом. Поновно уписивање дељене тајне Windows-а на профилу који се аутентификује сертификатима ништа не мења у фази која пада, а уређивање PPP лозинке не може да пружи канал који недостаје. Иста уздржаност важи за проверу идентитета: не искључујте идентитет партнера или валидацију сертификата да бисте добили тунел, јер се тада повезује путања, а не партнер.
Аутентификација такође није крај PPP-а. Након што корисник буде прихваћен, IPCP преговара о адреси клијента и DNS и WINS опцијама које је сервер спреман да да. Клијент може да прође CHAP или MS-CHAPv2 и ипак остане без адресе, што је квар унутар PPP-а, а не проблем рутирања. Обичан L2TP без IPsec-а остаје важећи и незаштићен, па успешна веза никада не доказује да је саобраћај заштићен; проверите шта сервер захтева, не ознаку клијента.
Одлучите по првој фази која недостаје
Читајте табелу по првом елементу који недостаје, слева надесно. Десна колона је једини посао који вреди у том тренутку; све лево од ње је већ доказано, а поновно тестирање троши прозор застоја без додавања информација.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
Три реда заслужују упозорење. Ред 1701 је место где обично слећу Windows клијенти иза NAT-а: асоцијација се заврши, затим ништа не стиже, а узрок је инкапсулација, не лоша лозинка. Ред IPCP је онај који се погрешно чита као проблем руте, јер Windows увија адресу која недостаје у грешку 720, а икона у траци само каже да веза није успела; тај квар стоји после аутентификације и пре рутирања. Последњи ред уопште није IPsec квар, иако икона каже искључено.
Команде које раздвајају слојеве
На Linux серверу са strongSwan swanctl --list-sas наводи успостављене асоцијације са идентитетом партнера, а ipsec statusall покрива старије strongSwan и libreswan домаћине. Испод ip xfrm state показује стварне асоцијације језгра, док ss -lunp | grep 1701 доказује где је xl2tpd везан. Покрените xl2tpd -D у предњем плану да видите контролне везе и позиве, и укључите pppd отклањање грешака у /etc/ppp/options.xl2tpd да видите понуђени метод и одговор.
Када дневници покажу успешну аутентификацију, следеће питање је да ли се IPCP завршио. Проверите да ли ip range у одељку [lns default] датотеке /etc/xl2tpd/xl2tpd.conf још има слободне адресе и да ли /etc/ppp/options.xl2tpd заиста носи ms-dns и ms-wins ако их клијент очекује. Исцрпљен базен и опција DNS која недостаје изгледају другачије на жици: први оставља клијента без адресе и са 720, други даје адресу али без резолвера, па имена падају док ping на сирове адресе ради. Ни једно се не поправља поновним уносом лозинке.
На клијенту, додатак L2TP у NetworkManager-у уписује разговор pppd у дневник, па journalctl -u NetworkManager -b обично раздваја тунел подигнут, аутентификација одбијена од тунела уопште нема. На Windows-у Get-VpnConnection пријављује стварна подешавања аутентификације профила, а догађаји RasClient под Application у Event Viewer-у именују компоненту која пада. Када је дијалог превише нејасан, укључите netsh ras set tracing * enable.
Снимци захтевају једну пажњу. У транспортном режиму IPsec-а унутрашњи UDP 1701 је шифрован, па снимак на спољном интерфејсу показује ESP, или UDP 4500 под NAT-T, и уопште не L2TP. Недостатак 1701 у снимку је очекиван и није доказ блокираног порта; гледајте да ли се бројачи ESP или 4500 крећу.
NAT, MTU и руте: где вас стек заводи
NAT крши претпоставке пре него што је ишта аутентификовано. ESP је сопствени IP протокол, па га уређај који преводи одбацује ако партнери не инкапсулирају; управо то пружа UDP 4500. На Windows серверу који сам стоји иза кућног рутера или cloud NAT пролаза, фаза IPsec пада са грешком 789 док се AssumeUDPEncapsulationContextOnSendRule не постави на 2 под кључем PolicyAgent и машина не рестартује, а квар остаје неразлучив од затвореног порта. Клијенти иза NAT-а су лакши: са јавном адресом на серверу, NAT-T на UDP 4500 их носи и та вредност није укључена.
Када је PPP подигнут, MTU са црном рупом имитира мртав тунел: мали пакети пролазе, TLS руковање или учитавање странице виси, а клијент може и даље приказивати повезано. Смањите MTU интерфејса или затегните MSS на пролазу пре него што оптужите сервер. Рутирање подељеног тунела је други варалица; подмрежа послата са погрешном маском оставља тунел здравим, а једну апликацију недоступном. Приватно име домаћина додаје свој корак: ако упит излази кроз локални резолвер, име се не разрешава пре него што се тестира било која рута.
Контролна листа пре него што додирнете акредитиве
Прођите листу по реду и зауставите се на првом елементу који падне. Сваки корак је јефтин, и сваки искључује целу класу измена.
- Потврдите да асоцијација постоји на оба краја, упарена по идентитету партнера, а не по ознаци повезано.
- Потврдите да UDP 1701 стиже до xl2tpd; асоцијација без позива је ваш квар.
- Прочитајте пресуду PPP-а и, ако је аутентификовао, резултат IPCP-а, пре него што претпоставите да је лозинка погрешна.
- Тек сада поново унесите акредитиве у формату који сервер очекује, јер префикс домена мења налог.
- Ако и даље пада, снимите оба краја са усклађеним временским ознакама и упоредите фазу по фазу.
Заустављање на другом кораку значи проблем путање или инкапсулације, и никаква измена лозинке то не помера. Заустављање на трећем кораку значи да дневник већ именује метод или базен адреса који треба поправити. У сваком случају следећа измена је она коју можете оправдати, и престајете да кружите кроз подешавања која никада нису била укључена.