PPTP en Docker aŭtentikigas sed portas neniun trafikon
PPTP bezonas TCP 1723 por kontrolo kaj GRE por la utilaĵo. En ujo la conntrack-helpanto ofte mankas, do la ensaluto funkcias kaj nenio alia.
La kliento aŭtentikigas, PPP interkonsentas adreson, kaj poste nenio moviĝas. Ping malsukcesas, la retumilo malsukcesas, kaj la ujo ŝajnas konektita la tutan tempon. Tiu ŝablono ne estas problema pri la enkursiga tabelo, ĉar enkursigaj problemoj kutime rompas ankaŭ la kontrolan konekton. Temas pri la vojo de la utilaĵo, kaj en PPTP la utilaĵo estas malsama protokolo ol tiu, kiu ĵus sukcesis.
Kvin kontroloj, en la ordo kiu ŝparas la plej multe da tempo.
Kontrolo 1: apartigu la kontrolkanalon de la utilaĵo
PPTP aŭtentikigas super TCP 1723 kaj poste portas la PPP-utilaĵon ene de GRE, IP-protokolo 47. GRE estas nek TCP nek UDP, do ĉiu regulo kiu plusendas la kontrolan pordon diras nenion pri ĝi. NAT aŭ fajroŝirmilo kiu pasigas 1723 povas forĵeti protokolon 47 sen plendo, kaj la seanco restas duone konstruita tiamaniere ke ĝi aspektas kiel sukceso.
Se la ensaluto funkcias kaj neniu paketo revenas, supozu GRE unue kaj pruvu ĝin poste.
Kontrolo 2: konfirmu la helpanton en la gastiga kerno
Konekta spuraro ne povas ligi TCP-kontrolkonekton al GRE-fluo sen helpanto. La modulo estas nf_conntrack_pptp, ĝi loĝas en la gastiga kerno, kaj ŝargi ĝin ene de la uja bildo atingas nenion ĉar moduloj validas por la tuta gastiganto. lsmod | grep nf_conntrack_pptp sur la Docker-gastiganto estas la kontrolo. Se ĝi mankas, modprobe nf_conntrack_pptp ŝargas ĝin por la kuranta kerno kaj diras nenion pri la sekva ekfunkciigo, do aldonu ĝin ankaŭ al la gastiga agordo.
Modulo kiu malaperas ĉe restarto fariĝas la sama bileto sekvan monaton.
Kontrolo 3: legu la kernan politikon kiu malŝaltas ĝin
Eĉ kun la modulo ĉeestanta, kernoj ekde 4.7 agordas net.netfilter.nf_conntrack_helper defaŭlte al 0, kio malŝaltas aŭtomatan helpanton-donadon por ĉiu protokolo. Tiu defaŭlto estas la kialo ke ĝuste instalita modulo ankoraŭ faras nenion: la kodo estas tie kaj la politiko diras ne uzi ĝin. sysctl net.netfilter.nf_conntrack_helper raportas la nunan valoron, kaj agordi ĝin al 1 dum funkciado refarre disponigas la helpanton. Konservu la valoron per la sysctl-agordo de la gastiganto se la dezajno permesas tion.
Aŭtomata donado lasas trafikon krei atendojn implicite, kaj ĝuste pro tio la defaŭlto ŝanĝiĝis. Limigu ĝin al la fidinda gastiganto, aŭ uzu eksplicitan regulon kiu celas la helpanton.
Kontrolo 4: rigardu la ujan vojon aparte
Ŝargita helpanto ne kreas itineron. La ujo bezonas vojon al la PPTP-servilo, kaj plusendado sur la gastiganto devas permesi GRE en ambaŭ direktoj: iptables -L FORWARD -v -n montras ĉu protokolo 47 estas akceptata kaj ĉu la kalkiloj moviĝas. La masquerade-reguloj de Docker tradukas TCP kaj UDP, ne protokolon 47, do ponto-ujo eble bezonas eksplicitan forward-permeson kaj, sur iuj gastigantoj, sian propran tradukan regulon. Konfirmu ankaŭ ke la ujo havas la PPP-aparatan subtenon kiun ĝia bildo atendas.
Legu la kalkilojn anstataŭ la regulan tekston. Regulo kiu ekzistas kaj kongruas kun nenio estas ornamaĵo.
Kontrolo 5: pruvu ke GRE estas spurata, poste decidu pri PPTP
Kun la kliento funkcianta, legu la spuran tabelon. Starigita PPTP-kontrola enskribo plus rilata GRE-enskribo signifas ke la helpanto ligas la fluojn kaj la restanta fuŝo estas aliloke. Kontrola enskribo sen GRE-enskribo signifas ke la utilaĵo estas forĵetata aŭ ne spurata, kio rekondukas vin al kontroloj 2 kaj 3.
PPTP mem estas heredaĵo kaj MS-CHAPv2 estas malforta. Se la servilo ankaŭ ofertas L2TP/IPsec, IKEv2 aŭ WireGuard, transiri al unu el ili forigas ĉi tiun tutan klason de problemoj.
Kie PPTP devas resti, funkciigi la klienton sur la gastiganto anstataŭ ene de ujo forigas unu tavolon de NAT kaj filtrado, kio ofte estas la pli malmultekosta decido.