Linux дээр IPsecгүй L2TP: 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, 1460-ийн MTU болон MRU, холболт боссны дараа клиент хүрч чадах DNS хаяг. Нэвтрэх мэдээлэл дахин гурав дахь файл, /etc/ppp/chap-secrets, тэнд хоёр дахь талбар LNS хэсгийн нэртэй тохирох ёстой, дөрөв дэх талбар сангаас тодорхой хаяг тогтоож болно.

Туннель яагаад холбогдоод гацдаг

1500 байтын Ethernet кадр өөрийн толгойд байт зарцуулдаг замын дотор багтахгүй. Гадна IPv4 толгой 20, UDP 8, L2TP толгой ойролцоогоор 12 авдаг тул PPP болон түүний ачаалалд 1460 үлддэг. 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-ээр орчуулж, дараа нь -i ppp0 -o eth0-ийн FORWARD дүрмээр гарч буй туннелийн трафикийг, толь дүрэм дээр нэмээд -m state --state RELATED,ESTABLISHED-ээр буцаж ирэх трафикийг хүлээн авна уу. Эдгээр дүрмийг дахин ачааллах хооронд тогтвортой байлга, учир нь тэдгээргүй буцаж ирсэн сервер яг эвдэрсэн L2TP тохиргоо шиг харагдана.

Серверийн өөрийн LAN-д хүрэх нь өөр ажил: LAN чиглүүлэгч дээр сангийн буцах маршрут нэмэх, эсвэл сервер дээр proxy ARP ажиллуулах. LAN доторх ямар нэг зүйл клиентүүдэд шууд хандах шаардлагатай үед тэднийг NAT-ийн ард нуух нь зөвхөн дараа нь хоёр дахь дибаг сессийг төлөвлөж байгаа хэрэг.

Нүцгэн стек юу хийдэггүй, хэрхэн шалгах

Энэ стекийн аль ч хэсэг PPP кадрыг шифрлэдэггүй бөгөөд дотор нь юу ч алслагдсан талыг таны үнэхээр сонгосон сервер гэж нэвтрүүлэхгүй. MS-CHAPv2 нэвтрэх мэдээллийн солилцоог зөвхөн ажиглаж буй сонсогчоос хамгаалдаг ч замд байрласан халдагч сессэд оролцож болно. Windows-ийн төрөлх клиент L2TP-г зөвхөн IPsec-тэй хамт санал болгодог тул Linux, чиглүүлэгчийн firmware, гуравдагч талын клиентүүдийг өөртэйгөө тэнцэх тал гэж тооцоорой. Нүцгэн тохиргоог оношлогооны шат гэж үзэж, хэзээ ч зогсох газар болгож болохгүй.

Тогтсон дарааллаар шалгана уу: xl2tpd -D-г урд талд ажиллуулж, PPP үе шатыг журналаас ажиглаж, хоёр үзүүрт ip addr-ээс олгогдсон хаягийг уншиж, дараа нь сесс боссны дараа өгөгдөл урсаж байгааг батлахын тулд UDP 1701-ийг барьж авна уу. Дөрөв нь тохирч байтал трафик бүтэлгүйтвэл алдаа нь чиглүүлэлт, NAT эсвэл MTU-д байна, L2TP-д өөрт нь биш.