Ang PPTP sa Docker ay nagpapatotoo ngunit hindi nagdadala ng trapiko

Nagpapatotoo ang kliyente, nakikipag-usap ang PPP sa isang address, at pagkatapos ay walang gumagalaw. Nabigo ang ping, nabigo ang browser, at ang container ay mukhang konektado sa buong oras. Ang pattern na ito ay hindi problema sa routing table, dahil ang mga problema sa routing ay karaniwang sumisira rin sa control connection. Ito ang landas ng payload, at sa PPTP ang payload ay ibang protocol kaysa sa katatapos na nagtagumpay.

Limang pagsusuri, sa pagkakasunod-sunod na nagtitipid ng pinakamaraming oras.

Pagsusuri 1: paghiwalayin ang control channel sa payload

Nagpapatotoo ang PPTP sa ibabaw ng TCP 1723 at pagkatapos ay dinadala ang PPP payload sa loob ng GRE, protocol IP 47. Ang GRE ay hindi TCP at hindi rin UDP, kaya bawat tuntunin na nagpapasa ng control port ay walang sinasabi tungkol dito. Ang NAT o firewall na nagpapadaan ng 1723 ay maaaring magtapon ng protocol 47 nang walang reklamo, at ang session ay nananatiling kalahating itinayo sa paraang mukhang tagumpay.

Kung gumagana ang pag-login at walang packet na bumabalik, ipagpalagay muna ang GRE at pagkatapos ay patunayan ito.

Pagsusuri 2: tiyakin ang helper sa kernel ng host

Hindi maaaring ikonekta ng connection tracking ang isang TCP control connection sa isang GRE flow nang walang helper. Ang module ay nf_conntrack_pptp, nakatira ito sa kernel ng host, at ang pag-load nito sa loob ng container image ay walang naidudulot dahil ang mga module ay para sa buong host. Ang lsmod | grep nf_conntrack_pptp sa host ng Docker ang pagsusuri. Kung wala ito, nilo-load ito ng modprobe nf_conntrack_pptp para sa tumatakbong kernel at walang sinasabi tungkol sa susunod na boot, kaya idagdag din ito sa configuration ng host.

Ang module na nawawala sa reboot ay nagiging parehong ticket sa susunod na buwan.

Pagsusuri 3: basahin ang patakarang kernel na nagpapatay dito

Kahit naroroon ang module, itinatakda ng mga kernel mula 4.7 ang net.netfilter.nf_conntrack_helper sa 0 bilang default, na nagpapatay sa awtomatikong pagtatalaga ng helper para sa bawat protocol. Ang default na iyon ang dahilan kung bakit ang tamang na-install na module ay wala pa ring ginagawa: naroon ang code at sinasabi ng patakaran na huwag itong gamitin. Iniulat ng sysctl net.netfilter.nf_conntrack_helper ang kasalukuyang halaga, at ang pagtatakda nito sa 1 habang tumatakbo ay muling nagpapagamit ng helper. Panatilihin ang halaga sa pamamagitan ng sysctl configuration ng host kung pinapayagan ng disenyo.

Ang awtomatikong pagtatalaga ay nagpapahintulot sa trapiko na lumikha ng mga inaasahan nang implicit, at iyon mismo ang dahilan kung bakit binago ang default. Limitahan ito sa pinagkakatiwalaang host, o gumamit ng tahasang tuntunin na nakatutok sa helper.

Pagsusuri 4: tingnan nang hiwalay ang landas ng container

Ang na-load na helper ay hindi lumilikha ng ruta. Kailangan ng container ng landas patungo sa PPTP server, at dapat pahintulutan ng forwarding sa host ang GRE sa dalawang direksyon: ipinapakita ng iptables -L FORWARD -v -n kung tinatanggap ang protocol 47 at kung gumagalaw ang mga counter. Isinasalin ng mga masquerade rule ng Docker ang TCP at UDP, hindi ang protocol 47, kaya ang isang bridged container ay maaaring mangailangan ng tahasang forward accept at, sa ilang host, ng sarili nitong translation rule. Tiyakin din na may suporta ang container para sa PPP device na inaasahan ng image nito.

Basahin ang mga counter sa halip na ang teksto ng tuntunin. Ang tuntuning umiiral at hindi tumutugma sa anuman ay dekorasyon.

Pagsusuri 5: patunayan na sinusubaybayan ang GRE, pagkatapos ay magpasya tungkol sa PPTP

Habang tumatakbo ang kliyente, basahin ang tracking table. Ang isang matatag na PPTP control entry at isang kaugnay na GRE entry ay nangangahulugang ikinokonekta ng helper ang mga flow at ang natitirang depekto ay nasa ibang lugar. Ang control entry na walang GRE entry ay nangangahulugang itinatapon o hindi sinusubaybayan ang payload, na nagbabalik sa iyo sa pagsusuri 2 at 3.

Ang PPTP mismo ay legacy at mahina ang MS-CHAPv2. Kung nag-aalok din ang server ng L2TP/IPsec, IKEv2 o WireGuard, ang paglipat sa isa sa mga ito ay nag-aalis ng buong klase ng problemang ito.

Kung saan kailangang manatili ang PPTP, ang pagpapatakbo ng kliyente sa host sa halip na sa loob ng container ay nag-aalis ng isang layer ng NAT at filtering, na kadalasan ang mas murang desisyon.