PPTP në Docker vërtetohet por nuk transporton trafik

Klienti vërtetohet, PPP negocion një adresë dhe më pas asgjë nuk lëviz. Ping dështon, shfletuesi dështon dhe kontejneri duket i lidhur gjatë gjithë kohës. Ky model nuk është problem i tabelës së rrugëtimit, sepse problemet e rrugëtimit zakonisht prishin edhe lidhjen e kontrollit. Është rruga e ngarkesës, dhe në PPTP ngarkesa është një protokoll tjetër nga ai që sapo pati sukses.

Pesë kontrolle, në radhën që kursen më shumë kohë.

Kontrolli 1: ndani kanalin e kontrollit nga ngarkesa

PPTP vërtetohet mbi TCP 1723 dhe më pas transporton ngarkesën PPP brenda GRE, protokolli IP 47. GRE nuk është as TCP as UDP, kështu që çdo rregull që përçon portën e kontrollit nuk thotë asgjë për të. Një NAT ose firewall që lejon 1723 mund ta hedhë protokollin 47 pa ankesë, dhe sesioni mbetet gjysmë i ndërtuar në një mënyrë që duket si sukses.

Nëse hyrja funksionon dhe asnjë paketë nuk kthehet, supozoni GRE ek pari dhe më pas provojeni.

Kontrolli 2: konfirmoni ndihmësin në kernelin e pritësit

Ndjekja e lidhjeve nuk mund të lidhë një lidhje kontrolli TCP me një rrjedhë GRE pa një ndihmës. Moduli është nf_conntrack_pptp, jeton në kernelin e pritësit, dhe ngarkimi i tij brenda imazhit të kontejnerit nuk arrin asgjë sepse modulët vlejnë për të gjithë pritësin. lsmod | grep nf_conntrack_pptp në pritësin Docker është kontrolli. Nëse mungon, modprobe nf_conntrack_pptp e ngarkon për kernelin që punon dhe nuk thotë asgjë për nisjen tjetër, kështu që shtojeni edhe në konfigurimin e pritësit.

Një modul që zhduket në rinisje bëhet i njëjti biletë muajin tjetër.

Kontrolli 3: lexoni politikën e kernelit që e çaktivizon

Edhe me modulin e pranishëm, kerneli që nga 4.7 vendos net.netfilter.nf_conntrack_helper si parazgjedhje në 0, gjë që fik caktimin automatik të ndihmësit për çdo protokoll. Kjo parazgjedhje është arsyeja pse një modul i instaluar saktë ende nuk bën asgjë: kodi është aty dhe politika thotë të mos përdoret. sysctl net.netfilter.nf_conntrack_helper raporton vlerën aktuale, dhe vendosja e saj në 1 gjatë ekzekutimit e bën ndihmësin përsëri të disponueshëm. Ruajeni vlerën përmes konfigurimit sysctl të pritësit nëse dizajni e lejon.

Caktimi automatik lejon trafikun të krijojë pritshmëri në mënyrë implicite, dhe pikërisht për këtë parazgjedhja ndryshoi. Kufizojeni te pritësi i besuar, ose përdorni një rregull të qartë që synon ndihmësin.

Kontrolli 4: shikoni veçmas rrugën e kontejnerit

Një ndihmës i ngarkuar nuk krijon rrugë. Kontejneri ka nevojë për një rrugë drejt serverit PPTP, dhe përçimi në pritës duhet të lejojë GRE në të dy drejtimet: iptables -L FORWARD -v -n tregon nëse protokolli 47 pranohet dhe nëse numëruesit lëvizin. Rregullat masquerade të Docker përkthejnë TCP dhe UDP, jo protokollin 47, kështu që një kontejner i urëzuar mund të ketë nevojë për një pranim forward të qartë dhe, në disa pritës, për rregullin e vet të përkthimit. Konfirmoni gjithashtu se kontejneri ka mbështetjen e pajisjeve PPP që pret imazhi i tij.

Lexoni numëruesit, jo tekstin e rregullit. Një rregull që ekziston dhe nuk përputhet me asgjë është dekor.

Kontrolli 5: provoni se GRE ndiqet, pastaj vendosni për PPTP

Ndërsa klienti punon, lexoni tabelën e ndjekjes. Një zë kontrolli PPTP i vendosur plus një zë GRE e lidhur do të thotë që ndihmësi lidh rrjedhat dhe defekti i mbetur është diku tjetër. Një zë kontrolli pa zë GRE do të thotë që ngarkesa hidhet ose nuk ndiqet, gjë që ju kthen te kontrollet 2 dhe 3.

Vetë PPTP është trashëgimi dhe MS-CHAPv2 është i dobët. Nëse serveri ofron gjithashtu L2TP/IPsec, IKEv2 ose WireGuard, kalimi në një prej tyre eliminon të gjithë këtë klasë problemesh.

Aty ku PPTP duhet të mbetet, ekzekutimi i klientit në pritës në vend të brenda një kontejneri eliminon një shtresë NAT dhe filtrimi, që shpesh është vendimi më i lirë.