Mae PPTP mewn Docker yn dilysu ond nid yw'n cario traffig

Mae'r cleient yn dilysu, mae PPP yn trafod cyfeiriad, ac yna nid oes dim yn symud. Mae ping yn methu, mae'r porwr yn methu, ac mae'r cynhwysydd yn edrych yn gysylltiedig drwy'r amser. Nid problem tabl llwybro yw'r patrwm hwnnw, oherwydd mae problemau llwybro fel arfer yn torri'r cysylltiad rheoli hefyd. Y llwybr llwyth sydd yma, ac mewn PPTP mae'r llwyth yn brotocol gwahanol i'r un a lwyddodd o'r newydd.

Pum archwiliad, yn y drefn sy'n arbed y mwyaf o amser.

Archwiliad 1: gwahanwch y sianel reoli oddi wrth y llwyth

Mae PPTP yn dilysu dros TCP 1723 ac yna'n cario llwyth PPP y tu mewn i GRE, protocol IP 47. Nid yw GRE yn TCP nac yn UDP, felly nid yw pob rheol sy'n anfon y porth rheoli yn dweud dim amdano. Gall NAT neu wal dân sy'n pasio 1723 ollwng protocol 47 heb gwyn, ac mae'r sesiwn yn aros yn hanner-adeiladwyd mewn ffordd sy'n edrych fel llwyddiant.

Os yw'r mewngofnodi'n gweithio ac nad oes pecyn yn dod yn ôl, tybiwch GRE yn gyntaf a'i brofi wedyn.

Archwiliad 2: cadarnhewch y cymhorthydd yng nghnewyllyn y gwesteiwr

Ni all olrhain cysylltiadau gysylltu cysylltiad rheoli TCP â llif GRE heb gymhorthydd. Y modiwl yw nf_conntrack_pptp, mae'n byw yng nghnewyllyn y gwesteiwr, ac nid yw ei lwytho y tu mewn i ddelwedd y cynhwysydd yn cyflawni dim oherwydd mae modiwlau'n gweithredu ar draws y gwesteiwr i gyd. lsmod | grep nf_conntrack_pptp ar y gwesteiwr Docker yw'r archwiliad. Os yw ar goll, mae modprobe nf_conntrack_pptp yn ei lwytho ar gyfer y cnewyllyn sy'n rhedeg ac yn dweud dim am y cychwyn nesaf, felly ychwanegwch ef at ffurfweddiad y gwesteiwr hefyd.

Mae modiwl sy'n diflannu wrth ailgychwyn yn dod yn unfath docyn y mis nesaf.

Archwiliad 3: darllenwch y polisi cnewyllyn sy'n ei analluogi

Hyd yn oed gyda'r modiwl yn bresennol, mae cnewyllyn ers 4.7 yn gosod net.netfilter.nf_conntrack_helper i 0 yn ddiofyn, sy'n diffodd aseinio cymhorthydd awtomatig ar gyfer pob protocol. Y diofyn hwnnw yw'r rheswm pam nad yw modiwl sydd wedi'i osod yn gywir yn gwneud dim o hyd: mae'r cod yno ac mae'r polisi'n dweud peidio â'i ddefnyddio. Mae sysctl net.netfilter.nf_conntrack_helper yn adrodd y gwerth cyfredol, ac mae ei osod i 1 ar amser rhedeg yn gwneud y cymhorthydd ar gael eto. Cadwch y gwerth drwy ffurfweddiad sysctl y gwesteiwr os yw'r dyluniad yn caniatáu hynny.

Mae aseinio awtomatig yn caniatáu i draffig greu disgwyliadau'n ymhlyg, a dyna'n union pam y newidiodd y diofyn. Cyfyngwch ef i'r gwesteiwr ymddiriedol, neu defnyddiwch reol benodol sy'n targedu'r cymhorthydd.

Archwiliad 4: edrychwch ar lwybr y cynhwysydd ar wahân

Nid yw cymhorthydd wedi'i lwytho yn creu llwybr. Mae'r cynhwysydd angen llwybr i weinydd PPTP, ac mae'n rhaid i anfon ymlaen y gwesteiwr ganiatáu GRE yn y ddwy gyfeiriad: mae iptables -L FORWARD -v -n yn dangos a yw protocol 47 yn cael ei dderbyn ac a yw'r cyfrifwyr yn symud. Mae rheolau masquerade Docker yn cyfieithu TCP ac UDP, nid protocol 47, felly efallai y bydd angen derbyniad forward penodol ar gynhwysydd pont ac, ar rai gwesteiwyr, ei reol gyfieithu ei hun. Cadarnhewch hefyd fod gan y cynhwysydd y gefnogaeth dyfais PPP y mae ei ddelwedd yn ei disgwyl.

Darllenwch y cyfrifwyr yn hytrach na thestun y rheol. Mae rheol sy'n bod ac nad yw'n cyfateb i ddim yn addurn.

Archwiliad 5: profwch fod GRE yn cael ei olrhain, yna penderfynwch am PPTP

Gyda'r cleient yn rhedeg, darllenwch y tabl olrhain. Mae cofnod rheoli PPTP sefydledig ynghyd â chofnod GRE cysylltiedig yn golygu bod y cymhorthydd yn cysylltu'r llifau a bod y gwall sy'n weddill yn rhywle arall. Mae cofnod rheoli heb gofnod GRE yn golygu bod y llwyth yn cael ei ollwng neu heb ei olrhain, sy'n eich rhoi'n ôl at archwiliadau 2 a 3.

Mae PPTP ei hun yn etifeddiaeth ac mae MS-CHAPv2 yn wan. Os yw'r gweinydd hefyd yn cynnig L2TP/IPsec, IKEv2 neu WireGuard, mae symud i un ohonynt yn dileu'r dosbarth cyfan hwn o broblemau.

Lle mae'n rhaid i PPTP aros, mae rhedeg y cleient ar y gwesteiwr yn lle y tu mewn i gynhwysydd yn dileu un haen o NAT a hidlo, sy'n aml yn benderfyniad rhatach.