Голи L2TP је PPP у коверти и ништа више. Преноси ваше оквире; не шифрује их и не доказује ко седи на другој страни, због чега скоро свако постављање под њега подмеће IPsec. Искрени разлози за покретање голе верзије још постоје: лабораторијска клупа, корак миграције или веза која је већ унутар другог заштићеног пута.

Ако ипак наставите, упишите то упозорење у белешку о дизајну и оставите га тамо. Оно што следи је оперативни пут који користим на домаћинима из породице Debian и RHEL: која датотека чему служи, MTU који спречава класично заглављивање и правила прослеђивања која тунел чине вредним.

Три датотеке деле посао

xl2tpd прекида контролну везу и предаје сваку сесију PPP демону, па је конфигурација распоређена на два програма који никада не читају датотеке оног другог. Слушалац живи у /etc/xl2tpd/xl2tpd.conf, унутар одељка [lns default] који именује распон адреса са ip range, страну сервера са local ip и предају PPP-у са pppoptfile. Укључите require authentication = yes, оставите length bit и flow bit омогућене и изаберите распон који ништа друго на домаћину већ не користи.

PPP политика припада датотеци коју та опција наведе, обично /etc/ppp/options.xl2tpd: auth, одбијања за pap, chap и mschap, require-mschap-v2, MTU и MRU од 1460 и DNS адреса коју клијент може достићи након подизања везе. Акредитиви су опет трећа датотека, /etc/ppp/chap-secrets, где друго поље мора да одговара имену одељка LNS, а четврто може да причврсти одређену адресу из распона.

Зашто се тунел повезује и затим заглављује

Ethernet оквир од 1500 бајтова не стане у пут који већ троши бајтове на сопствена заглавља. Спољно IPv4 заглавље кошта 20, UDP 8, а L2TP заглавље око 12, што оставља 1460 за PPP и његов терет. Управо објављивање те мање бројке у PPP спречава да велики пакети буду фрагментирани или тихо одбачени негде у средини.

Симптом је тунел који изгледа здрав док не стигне стварни саобраћај: пингови и контролне поруке пролазе, копирање датотеке се заглављује, ништа у дневнику не објашњава зашто. Смањите MTU и MRU заједно на оба краја. Подешавање само клијента обично претвара тврдо заглављивање у повремено, што је горе за дијагностику.

Један порт носи два разговора

UDP 1701 стоји под обе половине протокола, а та једна чињеница крши више правила заштитног зида него било који други део поставке. Прво долазе захтев за почетак контролне везе и његов одговор; захтев за сесију и потврда који следе не успостављају ништа више од пара идентификатора. Затим преузима PPP: контрола везе, па аутентификација, па протокол за контролу IP-а да усклади адресе. Свака фаза има свој речник у дневнику и ниједна се не представља као квар L2TP-а.

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

Како тунел учинити корисним: прослеђивање и NAT

Сесија сама по себи достиже само сервер. Приступ клијената интернету тражи прослеђивање, NAT правило за распон на узлазној вези и DNS који клијент заиста може да упита након подизања везе. Распон такође мора да остане изван LAN опсега, иначе се одговори упућени клијентима достављају локално уместо да се гурну назад у тунел.

На серверу укључите прослеђивање са sysctl -w net.ipv4.ip_forward=1, преведите распон са iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, па прихватите одлазни саобраћај тунела FORWARD правилом за -i ppp0 -o eth0 и повратни саобраћај огледалским правилом плус -m state --state RELATED,ESTABLISHED. Сачувајте та правила кроз поновна покретања, јер сервер који се врати без њих изгледа тачно као покварена L2TP конфигурација.

Достизање сопственог LAN-а сервера је други задатак: додајте повратну руту за распон на LAN рутеру или proxy ARP на серверу. Скривање клијената иза NAT-а када им нешто унутар LAN-а мора изравно да се обрати само заказује другу сесију отклањања грешака за касније.

Шта голи стек не ради и како то проверити

Ниједан део овог стека не шифрује PPP оквире и ништа у њему не аутентификује другу страну као сервер који сте заиста одабрали. MS-CHAPv2 заиста штити размену акредитива од слушаоца који само посматра, али нападач смештен на путу ипак може да се умеша у сесију. Изворни Windows клијент нуди L2TP само у комбинацији са IPsec-ом, па рачунајте на Linux, фирмвер рутера и клијенте трећих страна као своје партнере. Третирајте голу конфигурацију као дијагностичку степеницу, никада као место за заустављање.

Проверите у фиксном редоследу: покрените xl2tpd -D у предњем плану, пратите дневник за PPP фазу, прочитајте додељену адресу из ip addr на оба краја, затим снимите UDP 1701 да потврдите да подаци теку након успостављања сесије. Ако се сва четири поклопе, а саобраћај још увек не пролази, кривица је у рутирању, NAT-у или MTU-у, а не у самом L2TP-у.

Повезани чланци