PPTP í Docker auðkennir sig en flytur engan umferð
PPTP þarf TCP 1723 fyrir stjórnun og GRE fyrir hleðsluna. Í gámi vantar oft conntrack-aðstoðarmanninn, svo innskráningin virkar og ekkert annað.
Biðlarinn auðkennir sig, PPP semur um vistfang og síðan hreyfist ekkert. Ping mistekst, vafrinn mistekst og gámurinn virðist tengdur allan tímann. Þetta mynstur er ekki vandamál leiðartöflu, því leiðarvandamál brjóta yfirleitt líka stjórnsambandið. Þetta er slóð hleðslunnar, og í PPTP er hleðslan önnur samskiptaregla en sú sem tókst rétt í þessu.
Fimm prófanir, í þeirri röð sem sparar mestan tíma.
Prófun 1: aðskildu stjórnrásina frá hleðslunni
PPTP auðkennir sig yfir TCP 1723 og flytur síðan PPP-hleðsluna inni í GRE, IP-samskiptareglu 47. GRE er hvorki TCP né UDP, svo hver regla sem sendir stjórnhliðið áfram segir ekkert um það. NAT eða eldveggur sem hleypir 1723 í gegn getur sleppt samskiptareglu 47 án kvörtunar, og lotan verður hálfbyggð á þann hátt sem lítur út eins og árangur.
Ef innskráningin virkar og ekkert pakki kemur til baka, gerðu ráð fyrir GRE fyrst og sannaðu það síðan.
Prófun 2: staðfestu aðstoðarmanninn í kjarna hýsingarinnar
Tengingarakning getur ekki tengt TCP-stjórnsamband við GRE-strauma án aðstoðarmanns. Einingin er nf_conntrack_pptp, hún býr í kjarna hýsingarinnar, og að hlaða henni inni í gámmyndinni skilar engu því einingar gilda fyrir alla hýsinguna. lsmod | grep nf_conntrack_pptp á Docker-hýsingunni er prófunin. Ef hún vantar hleður modprobe nf_conntrack_pptp henni fyrir keyrandi kjarnann og segir ekkert um næstu ræsingu, svo bættu henni einnig við stillingar hýsingarinnar.
Eining sem hverfur við endurræsingu verður sama miðinn í næsta mánuði.
Prófun 3: lestu kjarnastefnuna sem slökkvar á henni
Jafnvel með eininguna til staðar setja kjarnar frá 4.7 net.netfilter.nf_conntrack_helper sjálfgefið í 0, sem slökkvar á sjálfvirkri aðstoðarmannatildælingu fyrir hverja samskiptareglu. Það sjálfgefið er ástæðan fyrir því að rétt uppsett eining gerir samt ekkert: kóðinn er þar og stefnan segir að nota hann ekki. sysctl net.netfilter.nf_conntrack_helper tilkynnir núverandi gildi, og að setja það í 1 á keyrslutíma gerir aðstoðarmanninn aftur aðgengilegan. Varðveittu gildið í gegnum sysctl-stillingu hýsingarinnar ef hönnunin leyfir.
Sjálfvirk tildæling leyfir umferð að búa til væntingar óbeint, og það er einmitt ástæðan fyrir því að sjálfgefið gildi var breytt. Takmarkaðu hana við trausta hýsingu, eða notaðu skýra reglu sem beinist að aðstoðarmanninum.
Prófun 4: skoðaðu slóð gámsins sérstaklega
Hlaðinn aðstoðarmaður býr ekki til leið. Gámurinn þarf slóð að PPTP-þjóninum, og áframsending á hýsingunni verður að leyfa GRE í báðar áttir: iptables -L FORWARD -v -n sýnir hvort samskiptaregla 47 er samþykkt og hvort teljararnir hreyfast. Masquerade-reglur Docker þýða TCP og UDP, ekki samskiptareglu 47, svo brúaður gámur gæti þurft skýra forward-samþykkt og, á sumum hýsingum, sína eigin þýðingarreglu. Staðfestu líka að gámurinn hafi þá PPP-tækjastuðning sem myndin hans gerir ráð fyrir.
Lestu teljarana frekar en texta reglunnar. Regla sem er til og passar við ekkert er skraut.
Prófun 5: sannaðu að GRE sé rakið, taktu svo ákvörðun um PPTP
Með biðlarann í gangi skaltu lesa rakningartöfluna. Uppsett PPTP-stjórnfærsla auk tengdrar GRE-færslu þýðir að aðstoðarmaðurinn tengir straumana og að gallinn sem eftir er sé annars staðar. Stjórnfærsla án GRE-færslu þýðir að hleðslunni er sleppt eða hún er ekki rakin, sem færir þig aftur að prófunum 2 og 3.
PPTP sjálft er arfleifð og MS-CHAPv2 er veikt. Ef þjónninn býður líka L2TP/IPsec, IKEv2 eða WireGuard, þá fjarlægir flutningur yfir í eitt þeirra allan þennan flokk vandamála.
Þar sem PPTP verður að vera áfram, fjarlægir að keyra biðlarann á hýsingunni í staðinn fyrir inni í gámi eitt lag af NAT og síun, sem er oft ódýrari ákvörðun.