L2TP na walang IPsec sa Linux: xl2tpd, pppd at NAT

Ang payak na L2TP ay PPP sa loob ng sobre, at wala nang iba. Dinadala nito ang iyong mga frame; hindi ito nag-e-encrypt sa mga ito at hindi pinapatunayan kung sino ang nakaupo sa kabilang dulo, kaya halos lahat ng deployment ay naglalagay ng IPsec sa ilalim nito. May mga tapat na dahilan pa rin para patakbuhin ang hubad na bersyon: isang lab bench, isang hakbang sa migrasyon, o isang link na nasa loob na ng ibang protektadong daan.

Kung tutuloy ka pa rin, isulat ang babalang iyon sa design note at hayaan itong naroon. Ang sumusunod ay ang operational na landas na ginagamit ko sa mga host ng pamilyang Debian at RHEL: aling file ang may pananagutan sa ano, ang MTU na pumipigil sa klasikong pagtigil, at ang mga tuntunin sa pagpapasa na nagpapahalaga sa tunnel.

Tatlong file ang naghahati sa gawain

Tinatapos ng xl2tpd ang control connection at ipinapasa ang bawat session sa isang PPP daemon, kaya ang configuration ay nahahati sa dalawang programa na hindi kailanman nagbabasa ng mga file ng isa't isa. Ang listener ay nakatira sa /etc/xl2tpd/xl2tpd.conf, sa loob ng seksyong [lns default] na nagpapangalan sa pool ng address gamit ang ip range, sa panig ng server gamit ang local ip, at sa pagpapasa sa PPP gamit ang pppoptfile. I-on ang require authentication = yes, hayaang nakabukas ang length bit at flow bit, at pumili ng pool na wala pang ibang gumagamit sa host.

Ang patakaran ng PPP ay kabilang sa file na pinangalanan ng opsyong iyon, karaniwang /etc/ppp/options.xl2tpd: auth, mga pagtanggi para sa pap, chap at mschap, require-mschap-v2, MTU at MRU na 1460, at address ng DNS na maaabot ng kliyente pagkatapos ng link na umangat. Ang mga kredensyal ay muling ikatlong file, /etc/ppp/chap-secrets, kung saan ang ikalawang field ay dapat tumugma sa pangalan ng seksyong LNS at ang ikaapat na field ay maaaring mag-pin ng partikular na address mula sa pool.

Bakit kumokonekta ang tunnel at pagkatapos ay tumitigil

Ang Ethernet frame na 1500 byte ay hindi kasya sa landas na gumagastos na ng byte sa sarili nitong mga header. Ang panlabas na IPv4 header ay 20, ang UDP ay 8, at ang L2TP header ay mga 12, na nag-iiwan ng 1460 para sa PPP at sa kargada nito. Ang pag-anunsyo ng mas maliit na bilang na iyon sa PPP ang pumipigil sa malalaking packet na mabiyak o tahimik na malaglag sa gitna.

Ang sintomas ay tunnel na mukhang malusog hanggang dumating ang tunay na trapiko: dumadaan ang ping at mga control message, nag-hang ang pagkopya ng file, walang nagpapaliwanag nito sa log. Ibaba ang MTU at MRU nang sabay sa dalawang dulo. Ang pagsasaayos lamang ng kliyente ay kadalasang ginagawang paminsan-minsan ang matigas na pagtigil, na mas mahirap i-diagnose.

Isang port ang nagdadala ng dalawang usapan

Ang UDP 1701 ay nasa ilalim ng dalawang kalahati ng protocol, at ang nag-iisang katotohanang iyon ay sumisira ng mas maraming tuntunin ng firewall kaysa sa anumang ibang bahagi ng setup. Una ang pagdating ng kahilingan sa pagsisimula ng control connection at ang sagot nito; ang kahilingan sa session at ang kumpirmasyon na sumusunod ay wala nang itinatag bukod sa pares ng identifier. Pagkatapos ay kinukuha ng PPP ang pamumuno: kontrol ng link, pagkatapos authentication, pagkatapos protocol ng kontrol ng IP para magkasundo sa mga address. Bawat yugto ay may sariling bokabularyo sa log, at wala sa kanila ang nagpapahayag ng sarili bilang kabiguan ng L2TP.

Ang pagbasa ng capture sa eksaktong pagkakasunod-sunod na iyon ay nagsasabi kung aling yugto ang nabigo, at ang kabiguan ng PPP authentication ay hindi maaayos sa pag-edit ng xl2tpd. Ang pinagsasaluhang port ay nagpapaliwanag ng isa pang karaniwang kabiguan: ang tuntunin na pumapayag lamang sa mga unang packet ng isang flow ay hinahayaang mabuo ang session at pagkatapos ay hinaharangan ang paglilipat. Payagan ang 1701 para sa buong usapan, sa dalawang direksyon.

Gawing kapaki-pakinabang ang tunnel: pagpapasa at NAT

Ang session sa sarili nito ay umaabot lamang sa server. Ang pag-access sa internet ng kliyente ay nangangailangan ng pagpapasa, tuntunin ng NAT para sa pool sa uplink, at DNS na tunay na maaaring itanong ng kliyente pagkatapos umangat ang link. Ang pool ay dapat ding manatiling labas ng saklaw ng LAN, kung hindi ay ang mga sagot na nakadirekta sa mga kliyente ay inihahatid nang lokal sa halip na itulak pabalik sa tunnel.

Sa server, i-on ang pagpapasa gamit ang sysctl -w net.ipv4.ip_forward=1, isalin ang pool gamit ang iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, pagkatapos tanggapin ang palabas na trapiko ng tunnel gamit ang tuntuning FORWARD para sa -i ppp0 -o eth0 at ang pabalik na trapiko gamit ang mirror rule kasama ang -m state --state RELATED,ESTABLISHED. Gawing permanente ang mga tuntuning iyon sa mga reboot, dahil ang server na bumabalik na wala ang mga ito ay eksaktong mukhang sirang configuration ng L2TP.

Ang pag-abot sa sariling LAN ng server ay ibang gawain: magdagdag ng return route para sa pool sa LAN router, o proxy ARP sa server. Ang pagtatago ng mga kliyente sa likod ng NAT kapag may bagay sa loob ng LAN na kailangang tuwirang kausapin sila ay nag-iiskedyul lamang ng ikalawang debugging session mamaya.

Ano ang hindi ginagawa ng hubad na stack, at paano i-verify

Walang bahagi ng stack na ito ang nag-e-encrypt sa mga PPP frame, at walang anuman dito ang nag-authenticate sa malayong dulo bilang ang server na tunay mong pinili. Pinoprotektahan ng MS-CHAPv2 ang pagpapalitan ng kredensyal mula sa isang tagapakinig na nanonood lamang, ngunit ang isang attacker na nakapuwesto sa landas ay maaari pa ring makialam sa session. Ang native na kliyente ng Windows ay nag-aalok ng L2TP kasama lamang ng IPsec, kaya isaalang-alang ang Linux, firmware ng router at mga kliyente ng third party bilang iyong mga kapareha. Ituring ang hubad na configuration bilang baitang ng diagnosis, hindi kailanman bilang lugar na hihintuan.

I-verify sa takdang pagkakasunod-sunod: patakbuhin ang xl2tpd -D sa foreground, panoorin ang journal para sa yugto ng PPP, basahin ang inilaan na address mula sa ip addr sa dalawang dulo, pagkatapos i-capture ang UDP 1701 upang kumpirmahin na dumadaloy ang data pagkatapos umangat ang session. Kung ang apat ay tumutugma at nabibigo pa rin ang trapiko, ang kasalanan ay sa routing, NAT o MTU, hindi sa L2TP mismo.