Rigardu PPTP-konekton ekleviĝi kaj estas facile kredi, ke la malfacila parto finiĝis: la kliento aŭtentikiĝas, ppp0-adaptilo aŭ WAN Miniport aperas, kaj la stata fenestro verdiĝas. Poste la unua peto al interna gastiganto finiĝas per tempolimo, kaj la profilo estas kulpigata. Praktike estas du sendependaj tavoloj por purigi: la ekstera transporto, kiu portas TCP 1723 kaj GRE, kaj la interna politiko, kiu decidas, kiuj celoj uzas la PPP-interfacon. Verda stato pruvas nur, ke la unua tavolo interkonsentis; pri la dua ĝi diras nenion.

Sekvu la klienton de la profilo ĝis la rega ingo

Malfermu la klientan protokolon kaj trovu la punkton, kie ĝi kontaktas la servilon. PPTP unue malfermas TCP-konekton al pordo 1723 kaj intertraktas tunelajn parametrojn per tiu kanalo. Se ĉi tiu paŝo malsukcesas, nenio poste gravas, kaj la eraro kutime nomas la servilan adreson aŭ tempolimon.

Konfirmu la regan konekton sur la drato antaŭ ol tuŝi ajnan itineron. Sur la kliento aŭ spegula pordo, kaptu TCP 1723 por unu konekta provo:

sudo tcpdump -ni any 'tcp port 1723' -c 20

Kompletigita manpremo kaj establita sesio signifas, ke la ekstera rega kanalo funkcias. SYN, kiu neniam ricevas SYN-ACK, indikas fajroŝirmilon, malĝustan servilan adreson aŭ provizanton, kiu filtradas la pordon. Manpremo sekvata de tuja restarigo ofte signifas, ke la servilo rifuzis la legitimilojn aŭ la tunelan tipon.

GRE estas dua protokolo, ne pordo

PPTP portas la PPP-ŝarĝon ene de plibonigita GRE, IP-protokolo 47, kiu havas neniun pordan numeron por spurigi per enkursigilo. Tial regulo, kiu permesas TCP 1723, ankoraŭ povas lasi la tunelon sen datena vojo. Stateful NAT-aparatoj devas kompreni la alvokan ID ene de GRE por mapi respondojn reen, kaj multaj ne faras tion. La PPTP-specifikaĵo tenas la regan kanalon kaj la GRE-ŝarĝon kiel apartajn partojn, kaj same devas via testplano.

Atentu protokolon 47 en la sama kaptaĵo, poste komparu, kio eliras, kun kio revenas:

sudo tcpdump -ni any 'proto gre' -c 20

Paketoj elirantaj sen respondoj, dum TCP 1723 restas sana, estas la klasika signo de blokita GRE. La trapaso de PPTP ĉe hejma enkursigilo estas trajto de tiu specifa firmvaro, do funkcianta hotelreto pruvas nenion pri la sekva. Se la enkursigilo ne ofertas traparadon kaj vi ne povas ŝanĝi ĝin, la protokola elekto estas la problemo, ne la itinera tabelo.

Pruvu, ke la tunelo movas unu paketon

Kiam GRE fluas, PPP-intertraktado asignas adreson al la klienta interfaco. Legu la asignon anstataŭ supozi ĝin:

ip -4 addr show ppp0

Ping la samtavolan adreson montratan kiel la cellokon de la punkto-al-punkto-ligilo. Respondo en ĉi tiu etapo pruvas, ke la enkapsuligita vojo funkcias de fino al fino kaj ke la servilo respondas ene de la tunelo. Se la samtavolano respondas sed internaj gastigantoj ne, la ekstera transporto estas en ordo kaj la fuŝo moviĝis internen.

Faru tion antaŭ ol aldoni ajnan dividitan itineron. Itinera ŝanĝo farita dum la transporto estas rompita kreas duan variablon kaj kaŝas la unuan.

Skribu la dividitan politikon, inkluzive DNS

Dividita enkursigado estas listo de decidoj, ne markobutono. Ĉiu privata prefikso, kiu devas trapasi la tunelon, bezonas itineron tra la PPP-interfaco, kaj ĉiu prefikso, kiu devas resti loka, devas foresti el ĝi. Itinero al aplikaĵ-subreto sen kongrua itinero al ĝia privata solvilo estas ofta maniero krei paneon, kiu aspektas kiel rompita aplikaĵo.

Kontrolu la decidon, kiun la kerno faras por unu adreso en ĉiu kategorio:

ip route get 10.20.5.10
ip route get 203.0.113.25

La unua devus nomi ppp0, la dua la ordinaran enirejon. Se ambaŭ nomas la saman interfacon, la politiko tute ne estas dividita. Aldonu la propran adreson de la DNS-servilo al la tunela listo, alie nomrezolucio por internaj gastigantoj eliras tra la loka solvilo kaj redonas nenion utilan.

Ripetebla kontrolo en kvin paŝoj

Rulu la tavolojn en ordo kaj haltu ĉe la unua, kiu malsukcesas: rega kanalo, videbleco de GRE, respondo de la PPP-samtavolano, dividita itinero por unu interna adreso kaj aplikaĵpeto tra la tunelo. Ĉiu paŝo havas sian propran komandon, do malsukceso estas atribuebla anstataŭ mistera.

Kompakta versio por Linux-kliento aspektas tiel:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

En Windows validas la sama ordo kun route print kaj la adaptila stato montrata en la kliento. PPTP estas malnova protokolo, kaj se la servilo ofertas SSTP aŭ IKEv2, translokiĝi kutime estas pli bona uzo de tempo ol agordi vojon, kiu dependas de trapaso de protokolo 47 ĉe ĉiu salto. Kontrolu la atestilon kaj la aŭtentikigan kontrakton de la anstataŭaĵo anstataŭ kopii malnovan profilon en novan eldonon.

Rilataj artikoloj