Kumokonekta ang PPTP at pagkatapos ay nag-hang sa likod ng Linux NAT: ang GRE helper

May nagpapasa ng 1723, narating ng kliyente ang server, nagsisimula ang pagpapatunay, at pagkatapos ay tumitigil ang lahat nang walang error. Ang natural na konklusyon ay maling password, kaya tatlong beses na muling inilalagay ang password. Maayos ang pagpapasa at maayos ang mga kredensyal. Ang nasira ay isang pangalawang protocol na hindi kailanman sinaklaw ng pagpapasa, at isang default ng kernel na tahimik na tumigil sa pagtulong dito.

Ang pagpapasa ay hindi kailanman naging problema

Inilalarawan ng tuntunin sa pagpapasa ng port ang trapikong TCP o UDP. Hindi nito mailarawan ang payload na lumilipat sa ibang protocol ng IP sa gitna ng sesyon, at ganoon nga ang ginagawa ng PPTP.

Kaya mukhang malusog ang koneksyon hanggang sa sandaling mag-hang ito. Nagtagumpay ang bahaging kayang pamahalaan ng tuntunin sa port, at ang bahaging hindi kayang pamahalaan ay siyang bahaging nabigo.

TCP para sa kontrol, GRE para sa data

Ang tawag ay pinag-uusapan sa TCP 1723. Kapag nakatayo na, lumilipat ang payload sa GRE, protocol IP 47, na wala talagang dalang numero ng port. Ang tuntuning nakabatay sa port ay walang maipapares.

Ang dinadala ng GRE ay isang identifier ng tawag sa header nito, at kailangang muling isulat ng tagasalin ng NAT ang field na iyon nang pare-pareho sa dalawang direksyon, kung hindi ay tumitigil ang dalawang kalahati ng sesyon sa pagkakasundo. Isang direksyon ang muling isinulat at ang isa ay hindi ay gumagawa ng sesyong nagpapatunay at pagkatapos ay itinatapon ang bawat packet ng data. Ganoon na nga ang hugis ng sintomas: tagumpay, pagkatapos ay katahimikan.

Ang hubad na GRE na walang PPTP ay hindi nangangailangan ng ganoong muling pagsulat, kaya ang ordinaryong GRE tunnel ay maaaring gumana sa router na nabibigo para sa kliyenteng PPTP sa parehong landas.

Apat na module at isang sysctl na nagpatay sa kanila

Dalawang module ang humahawak ng framing, nf_conntrack_proto_gre at nf_nat_proto_gre. Dalawa pa ang humahawak ng identifier ng tawag, nf_conntrack_pptp at nf_nat_pptp. Ang pag-load ng huli ay humihila ng iba sa pamamagitan ng dependencies, kaya dapat ipakita ng listahan ng module ang apat.

Gumagamit ang mas lumang mga tagubilin ng prefix na ip_ mula sa panahon ng 2.6. Ang mga utos na iyon ay maaaring magmukhang tumatakbo nang walang nilo-load, kaya suriin ang na-load na listahan sa halip na ang exit status.

Hindi na sapat na naka-load sila. Mula noong Linux 4.7 ang sysctl net.netfilter.nf_conntrack_helper ay 0 bilang default, na nagpapawalang-bisa sa awtomatikong pagtatalaga ng helper para sa mga bagong flow. Maaaring may lahat ng module ang isang router at wala pa ring isinasalin. Suriin ang epektibong halaga bago muling tingnan ang listahan ng module.

Maaaring muling buksan ang awtomatikong pagtatalaga sa buong sistema, o ikabit ang helper sa mga flow na nangangailangan nito at hayaang manatili ang lahat ng iba:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

Ang pangalawang opsyon ang mas mainam. Nililimitahan nito ang pag-uugali sa trapikong PPTP sa halip na muling paganahin ang awtomatikong pagtatalaga sa buong router.

Pagbubukas ng protocol na walang port

Ang tuntunin ng firewall na nagpapahintulot ng 1723 ay walang sinasabi tungkol sa protocol 47. Sa firewalld, payagan ang protocol sa zone na nakaharap sa kliyente. Sa ordinaryong iptables, tanggapin ang protocol na gre sa input chain.

Pagkatapos ay kumuha sa dalawang panig. Ang mga packet na umaalis sa kliyente nang walang dumarating na tugon ay nangangahulugang sinasala ang landas ng pagbalik, at iba iyon sa kredensyal na tinanggihan.

Pagkatapos kumonekta, ang limitasyon sa laki

Naglalagay ang GRE ng header, at nagdadagdag pa ang PPP sa loob nito, kaya ang gumaganang link ay nag-uulat ng MTU na malayo sa ilalim ng 1500. Naglo-load ang maliliit na tugon at nag-hang ang malalaki, na mukhang pangalawang problemang walang kaugnayan na lumilitaw sa sandaling malutas ang una.

Basahin ang MTU sa PPP adapter ng kliyente at itugma ito sa sariling kalkulasyon ng router sa halip na babaan ang mga numero hanggang may gumana. Ang mga packet na buong laki na lumalabas nang walang bumabalik ay tumutukoy sa limitasyong iyon, hindi sa pagsasalin.

Ang pagkumpuni ng landas ay nagpapabalik sa gumagamit sa trabaho, at hindi nito ginagawang mabuting pagpipilian ang PPTP. Ang MS-CHAPv2 at RC4 ay matagal nang lipas, kaya ituring ang pag-load ng module bilang pansamantalang pagwawasto at planuhin ang paglipat sa isang pinapanatiliwang protocol.