PPTP Dockerren barruan autentifikatu egiten da, baina ez du trafikorik eramaten

Bezeroa autentifikatu egiten da, PPPk helbide bat negoziatzen du, eta gero ezerk ez du mugitzen. Pingak huts egiten du, arakatzaileak huts egiten du, eta edukiontziak konektatuta ematen du denbora osoan. Eredu hori ez da bideratze-taularen arazoa, bideratze-arazoek normalean kontrola-konexioa ere apurtzen baitute. Kargaren bidea da, eta PPTPn karga oraintxe lortu den protokoloaren desberdina da.

Bost egiaztapen, denbora gehien aurrezten duen ordenan.

1. egiaztapena: bereizi kontrol-kanala kargatik

PPTPk TCP 1723 bidez autentifikatzen da eta gero PPP karga GREren barruan eramaten du, IP 47 protokoloa. GRE ez da TCP ez UDP, beraz kontrol-portua birbidaltzen duen arau orok ez du ezer esaten hari buruz. 1723 pasatzen duen NAT edo suebaki batek 47 protokoloa erreklamaziorik gabe bota dezake, eta saioa erdi eraikita geratzen da arrakasta dirudien moduan.

Saioa hasten bada eta paketerik itzultzen ez bada, suposatu GRE lehenengo eta frogatu gero.

2. egiaztapena: berretsi laguntzailea host nukleoan

Konexioen jarraipenak ezin du TCP kontrol-konexio bat GRE fluxu batekin lotu laguntzaile bat gabe. Modulua nf_conntrack_pptp da, host nukleoan bizi da, eta edukiontzi irudiaren barruan kargatzeak ez du ezer lortzen moduluak host osoan balio dutelako. Docker hostean lsmod | grep nf_conntrack_pptp da egiaztapena. Falta bada, modprobe nf_conntrack_pptp exekutatzen ari den nukleoarentzat kargatzen du eta ez du ezer esaten hurrengo abioari buruz, beraz gehitu host konfiguraziora ere.

Berrabiaraztean desagertzen den modulua datorren hilean txartel berbera bihurtzen da.

3. egiaztapena: irakurri hura desgaitzen duen nukleo-politika

Modulua han egon arren, 4.7tik aurrerako nukleoek net.netfilter.nf_conntrack_helper 0-ra jartzen dute lehenespenez, eta horrek protokolo guztietarako laguntzaile-esleipen automatikoa itzaltzen du. Lehenespen hori da behar bezala instalatutako moduluak oraindik ezer egiten ez duen arrazoia: kodea han dago eta politikak ez erabiltzeko esaten du. sysctl net.netfilter.nf_conntrack_helper uneko balioa erakusten du, eta exekuzio-denboran 1-era jartzeak laguntzailea berriro eskuragarri uzten du. Gorde balioa hostaren sysctl konfigurazioaren bidez diseinuak onartzen badu.

Esleipen automatikoak trafikoari inplizituki itxaropenak sortzen uzten dio, eta horregatik aldatu zen lehenespena. Mugatu host fidagarrira, edo erabili laguntzaileari zuzendutako arau esplizitua.

4. egiaztapena: begiratu edukiontziaren bidea bereizita

Kargatutako laguntzaile batek ez du biderik sortzen. Edukiontziak PPTP zerbitzarirako bidea behar du, eta hostaren birbidalketak GRE baimendu behar du bi noranzkoetan: iptables -L FORWARD -v -n erakusten du 47 protokoloa onartzen den eta kontagailuak mugitzen diren. Dockeren masquerade arauek TCP eta UDP itzultzen dituzte, ez 47 protokoloa, beraz zubidun edukiontzi batek forward onarpen esplizitua behar izan dezake eta, host batzuetan, bere itzulpen-araua. Egiaztatu halaber edukiontziak bere irudiak espero duen PPP gailu euskarria duela.

Irakurri kontagailuak, ez arauaren testua. Badagoen eta ezeri bat egiten ez dion araua apaingarria da.

5. egiaztapena: frogatu GRE jarraitzen dela, gero erabaki PPTPri buruz

Bezeroa martxan dagoela, irakurri jarraipen-taula. Ezarritako PPTP kontrol-sarrera bat eta erlazionatutako GRE sarrera batek laguntzaileak fluxuak lotzen dituela eta gainerako akatsa beste nonbait dagoela esan nahi dute. GRE sarrerarik gabeko kontrol-sarrera batek karga botatzen dela edo jarraitzen ez dela esan nahi du, eta horrek 2 eta 3 egiaztapenetara itzultzen zaitu.

PPTP bera legatua da eta MS-CHAPv2 ahula da. Zerbitzariak L2TP/IPsec, IKEv2 edo WireGuard ere eskaintzen baditu, horietako batera aldatzeak arazo-mota oso hau kentzen du.

PPTPk geratu behar duen lekuetan, bezeroa edukiontziaren barruan beharrean hostean exekutatzeak NAT eta iragazketa geruza bat kentzen du, eta sarritan erabaki merkeagoa da.