L2TP без IPsec на Linux: xl2tpd, pppd і NAT

Звычайны 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.