Гэрийн чиглүүлэгчийн ард PPTP сервер: эхлээд 1723 ба GRE-г засаарай

Гэрийн чиглүүлэгчийн ард PPTP нь хоёр хамааралгүй аргаар бүтэлгүйтдэг бөгөөд тэдгээрийг хольж бол нэг бүтэн оройг үрэх болно. Нэг гэмтэл нь дамжуулалтын цоорхой: чиглүүлэгч TCP 1723-ыг нэвтрүүлж, IP протокол 47-г хаядаг тул клиент 619 алдаанд гацдаг. Нөгөө нь хэмжээний асуудал: туннель босч, баталгаажиж, дараа нь бүрэн хэмжээтэй пакет гарах ёстой үед хөлддөг. Аль нь таных болохыг тогтоох нь эхний жинхэнэ алхам; үлдсэн нь таны чиглүүлэгч юуг илэрхийлж чадахыг харьцуулдаг, аль брэнд илүү вэ гэдгийг биш.

Хоёр тээвэрлэгч, зөвхөн нэг нь порттой

PPTP нь хоёр тээвэрлэгчид хуваагдана: TCP 1723 дээрх удирдлагын холболт, өргөтгөсөн GRE-д ороосон PPP кадрууд, өөрөөр хэлбэл IP протокол 47. GRE-д портын дугаар байхгүй тул 1723 портыг дамжуулах гэж бичсэн дүрэм түүнийг хамарч чадахгүй, вэб интерфэйс тухайн талбарыг хэрхэн нэрлэсэн ч. Гэр ахуйн чиглүүлэгч ихэвчлэн протоколын дүрмийн оронд PPTP нэвтрүүлэх гэсэн нүдийг санал болгодог бөгөөд тэр нүд хоёр ажил хийдэг: галт ханыг 47 протоколыг нэвтрүүлж, NAT-д GRE урсгалыг хянахыг заадаг. Linux чиглүүлэгч дээр эдгээр ажил нь тусдаа модуль, тусдаа дүрэм байдаг тул хагас тохируулсан нэвтрүүлэлт ажилладаг удирдлагын суваг өгсөөр байна. Ямар нэг зүйлийг өөрчлөхөөс өмнө аль хагас нь байгааг олж мэдээрэй.

Серверийн өөрийн галт хана мөн чиглүүлэгчийн хаягаас 47 протоколыг зөвшөөрөх ёстой. Зөвхөн 1723/tcp хүлээн авдаг хост галт хана LAN-ийн дотроос 619 алдааг дахин үүсгэдэг тул эвдэрсэн дамжуулалт болон эвдэрсэн хост дүрэм ижил харагдана.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

Модулиуд байхгүй бол sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre-ээр ачаалж, ачааллыг байнгын болгоорой, учир нь туслахыг мартсан дахин ачаалалт ажиллаж байсан туннелийг дахин 619 алдаа болгоно. Дамжуулах дүрэм 47 протоколыг зөвхөн серверийн хаяг руу хүлээн авах ёстой, бүх LAN руу биш. RFC 2637 тодорхойлолт удирдлага болон өгөгдлийн замыг тусгаарладаг тул ганц ч порт дамжуулах дэлгэц PPTP-г бүрэн дүрслэхгүй.

Нэвтрүүлэх нүд эсвэл тодорхой протоколын дүрэм

Зөвхөн галт ханыг онгойлгодог нэвтрүүлэх нүд нь дуудлагын танигчийг дахин бичдэг ALG-ээс зөвд ойр байдаг. Галт ханын хагас нь урьдчилан таамаглагдах, учир нь 47 протоколыг нэг бол хүлээн авна, эсвэл хаяна, тоолуурууд аль нь болохыг хэлнэ. Дахин бичих хагас нь үйлдвэрлэгчид ялгаатай газар, учир нь PPTP-ийн дуудлагын танигч туннель бүрт байдаг бөгөөд тэдгээрийг засварладаг NAT өөрөө хүрсэн дуудлага бүрийг хянах ёстой. Нэг клиент холбогдоод хоёр нь холбогдохгүй үед ALG нь эхний сэжигтэн.

1723-ын очих газрын NAT дүрэм мөн эзэмшлийн асуудалтай. Хуучин дүрэм серверийг зогсоосон хост руу 1723-ыг илгэсээр байвал пакетууд хаалттай порт дээр бууж, чиглүүлэгчийн өөрийн PPTP үйлчилгээ хариу өгөхөө болино, энэ нь галт ханын гэмтэл мэт уншигддаг ч үнэндээ хуучирсан зорилт юм. Хоёр дахь дүрмийг нэмэхийн өмнө дүрэм болон түүний очих газрыг уншаарай. PPTP-г өөрсдөө дуусгадаг чиглүүлэгч дээр WAN дүрэм суурилагдсан үйлчилгээтэй өрсөлддөг тул 1723 болон 47 протоколд нэг эзэн сонгоорой.

Нэг NAT-ийн ард хоёр клиент байх нь энгийн дамжуулалтыг ухаалаг дамжуулалтаас тусгаарлах тохиолдол. Дуудлагын танигчийг дахин бичихгүйгээр 47 протоколыг дамжуулах нь тэдгээрийг засах гэж оролддог туслахаас ихэвчлэн дээр ажилладаг.

Чиглүүлэгчийг буруутгахаас өмнө туннелийг хэмжээрэй

PPTP нь ашигтай ачааллыг багасгадаг бөгөөд энэ багасалт нь нууц биш, арифметик юм. Туннелийн пакет бүр гадаад IP толгой, өргөтгөсөн GRE толгой, PPP толгой, шифрлэлттэй бол MPPE толгой зөөдөг. Зам үүссэн кадрыг зөөж чадахгүй үед жижиг пакетууд гарч, нэвтрэлт дуусч, файл дамжуулалт эсвэл TLS гар барилт бүрэн хэмжээтэй пакет илгээсэн эхний мөчид сесс зогсдог.

Таамаглахын оронд тоог бодоорой. Өргөтгөсөн GRE 8 байт, PPP 4 байт, MPPE 4 байт, гадаад IP толгой 20 байт тул туннель ямар ч ачааллын өмнө 36 байт иддэг. 1492-т дуусах PPPoE WAN дээр багтах хамгийн том PPP MTU нь 1492 хасах 36, өөрөөр хэлбэл 1456. PPP сонголтуудад mtu болон mru-г тэр утгад тааруулж, хуваалтгүй ping-ээр дахин туршаарай.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

Ping зам хэмждэг, туннель биш: 1464 байт ачаалал дээр 28 байт IP болон ICMP толгой нэмэгдэж 1492 байтын кадрыг яг дүүргэнэ. Тэр ping бүтэлгүйтвэл гарах хүртэл тоог буулгаж, үр дүнгээс 36-г хас. Замын хязгаараас дээш тавьсан туннелийн MTU нь хэмжээг дурдсан нэг ч лог мөргүйгээр хөлдөлт үүсгэдэг.

Нэг чиглүүлэгч дээр PPTP, L2TP/IPsec эсвэл OpenVPN

Нэг чиглүүлэгч гурван нийтлэг туннелийн аль нэгийг зөөж чадна, ялгаа нь юуг илэрхийлэх ёстойд байна. PPTP-д хоёр өөр давхаргад хоёр дүрэм хэрэгтэй. IPsec дээрх L2TP-д түлхүүр солилцоонд UDP 500 болон 4500, NAT-T үүнийг зөөхгүй бол ачаалалд 50 протокол хэрэгтэй. OpenVPN-д нэг UDP порт хангалттай, туслах огт хэрэггүй.

L2TP-ийн багана GRE-ээс автоматаар найрсаг биш. ESP нь IP протокол 50 бөгөөд түүнд ч порт байхгүй тул 47 протоколд хүндрэлтэй чиглүүлэгч мөн адил шалтгаанаар 50 протоколд хүндрэлтэй байж болно. NAT-T нь ESP-г UDP 4500 дотор ороохын тулд байдаг бөгөөд хоёр төгсгөл дэмжвэл 50 протоколын дүрэм илүүдэхгүй болно. Энэ нь төгсгөлүүдийн шинж, чиглүүлэгчийн PPTP нүднийх биш. Хоёуланд нь дүрэм бичихийн өмнө клиент яг ямар инкапсуляц тохиролцсоныг баталгаажуулаарай.

OpenVPN нь чиглүүлэгчийн талд хамгийн цөөн хөдөлгөөнт хэсэгтэй хувилбар. Нэг UDP порт, нэг дамжуулалт, холболт хянах туслахгүй, дуудлагын танигчийг дахин бичихгүй. Солилцоо нь суурилагдсан залгагчийн оронд суулгах шаардлагатай клиент бөгөөд PPTP яриа дотор үлдэх цорын ганц шалтгаан ихэвчлэн энэ.

Юуг засах, юуг солих

Дамжуулалт болон MTU-г засах нь ажилладаг туннель өгнө, барих ёстой туннель биш. PPTP-ийн MSCHAPv2 баталгаажуулалт олон жил халдлагад өртөмтгий, ажиллаж буй туннель офлайнаар сэргээж болох нэвтрэх мэдээллийг зөөдөг. Алсын төхөөрөмж L2TP/IPsec эсвэл OpenVPN ажиллуулж чадвал засварыг огноотой түр арга хэмжээ гэж үзээрэй.

Шийдвэр нь алсын төгсгөл юуг дэмждэг, зохицуулалт хэр удаан тэсвэрлэх ёстойгоос хамаарна. Зөвхөн PPTP ярьдаг хуучин төхөөрөмж засвар авна; клиент суулгаж болох бүхэн шилждэг.

Тикетийг хаахаас өмнө клиент нэвтрэлт биш, том дамжуулалтыг тэсвэрлэж байгаа, мөн дахин ачаалсны дараа ч чиглүүлэгч 47 протоколын дүрмээ хадгалж байгааг баталгаажуулаарай. Нэг файлын хуулбар даваад дараагийн firmware шинэчлэлтийн дараа үхдэг туннель хэзээ ч дуусаагүй байсан.