Tuneli i ndarë i PPTP nuk funksionon: rregullo fillimisht rrugën GRE

Shikoni një lidhje PPTP duke u ngritur dhe është e lehtë të besosh se pjesa e vështirë ka mbaruar: klienti autentikohet, shfaqet një përshtatës ppp0 ose WAN Miniport dhe dritarja e statusit bëhet e gjelbër. Më pas kërkesa e parë drejt një hosti të brendshëm skadon dhe profili fajësohet. Në praktikë ka dy shtresa të pavarura për të pastruar: transporti i jashtëm që mbart TCP 1723 dhe GRE, dhe politika e brendshme që vendos cilat destinacione përdorin ndërfaqen PPP. Një status i gjelbër provon vetëm se shtresa e parë ka negociuar; për të dytën nuk thotë asgjë.

Ndjek klientin nga profili te soketi i kontrollit

Hap regjistrin e klientit dhe gjej pikën ku kontakton serverin. PPTP hap fillimisht një lidhje TCP në portën 1723 dhe negocion parametrat e tunelit përmes atij kanali. Nëse ky hap dështon, asgjë më pas nuk ka rëndësi, dhe gabimi zakonisht përmend adresën e serverit ose një afat kohor.

Konfirmo lidhjen e kontrollit në rrjet përpara se të prekësh çdo rrugë. Në klient ose në një portë pasqyrë, kap TCP 1723 për një përpjekje lidhjeje:

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

Një shtrëngim duarsh i përfunduar dhe një sesion i vendosur nënkuptojnë se kanali i jashtëm i kontrollit funksionon. Një SYN që nuk merr kurrë SYN-ACK tregon një mur zjarri, një adresë serveri të gabuar ose një ofrues që filtron portën. Një shtrëngim duarsh i ndjekur nga një rinisje e menjëhershme shpesh do të thotë se serveri refuzoi kredencialet ose llojin e tunelit.

GRE është një protokoll i dytë, jo një portë

PPTP mbart ngarkesën PPP brenda GRE të zgjeruar, protokolli IP 47, i cili nuk ka numër porte që një ruter të mund të ndjekë. Prandaj një rregull që lejon TCP 1723 mund ta lërë tunelin ende pa rrugë të dhënash. Pajisjet NAT me gjendje duhet të kuptojnë ID-në e thirrjes brenda GRE për të hartuar përgjigjet, dhe shumë nuk e bëjnë. Specifikimi i PPTP mban kanalin e kontrollit dhe ngarkesën GRE si pjesë të ndara, dhe plani yt i testimit duhet të bëjë të njëjtën gjë.

Vëzhgo protokollin 47 në të njëjtën kapje, pastaj krahaso çfarë del me çfarë kthehet:

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

Paketat që dalin pa përgjigje, ndërsa TCP 1723 mbetet i shëndetshëm, janë shenja klasike e GRE të bllokuar. Passthrough i PPTP në një ruter konsumatori është funksion i atij firmware-i të caktuar, kështu që një rrjet hoteli që funksionon nuk provon asgjë për atë të radhës. Nëse rutera nuk ofron passthrough dhe nuk mund ta ndryshosh, problemi është zgjedhja e protokollit, jo tabela e rrugëve.

Provo se tuneli lëviz një paketë

Sapo GRE rrjedh, negociimi PPP i cakton një adresë ndërfaqes së klientit. Lexo caktimin në vend që ta supozosh:

ip -4 addr show ppp0

Ping adresën e palës së shfaqur si destinacion i lidhjes pikë-pikë. Një përgjigje në këtë fazë provon se rruga e inkapsuluar funksionon nga fillimi në fund dhe se serveri përgjigjet brenda tunelit. Nëse pala përgjigjet por hostet e brendshme jo, transporti i jashtëm është në rregull dhe dështimi ka kaluar brenda.

Bëje këtë përpara se të shtosh çdo rrugë të ndarë. Një ndryshim rruge i bërë ndërsa transporti është i prishur krijon një variabël të dytë dhe fsheh të parin.

Shkruaj politikën e ndarë, përfshirë DNS

Rutimi i ndarë është një listë vendimesh, jo një kuti kontrolli. Çdo prefiks privat që duhet të kalojë tunelin ka nevojë për një rrugë përmes ndërfaqes PPP, dhe çdo prefiks që duhet të mbetet lokal duhet të mungojë në të. Një rrugë drejt një nënrrjeti aplikacioni pa rrugën përkatëse drejt zgjidhësit të tij privat është një mënyrë e zakonshme për të krijuar një ndërprerje që duket si aplikacion i prishur.

Kontrollo vendimin që kerneli merr për një adresë në çdo kategori:

ip route get 10.20.5.10
ip route get 203.0.113.25

I pari duhet të emërtojë ppp0, i dyti gateway-in e zakonshëm. Nëse të dy emërtojnë të njëjtën ndërfaqe, politika nuk është fare e ndarë. Shto adresën e vetë serverit DNS në listën e tunelit, përndryshe zgjidhja e emrave për hostet e brendshme del përmes zgjidhësit lokal dhe nuk kthen asgjë të dobishme.

Një kontroll i përsëritshëm në pesë hapa

Ekzekuto shtresat me radhë dhe ndalo në të parën që dështon: kanali i kontrollit, dukshmëria e GRE, përgjigja e palës PPP, rruga e ndarë për një adresë të brendshme dhe një kërkesë aplikacioni përmes tunelit. Çdo hap ka komandën e vet, kështu që një dështim është i atribuueshëm dhe jo misterioz.

Një version kompakt për një klient Linux duket kështu:

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

Në Windows zbatohet i njëjti rend me route print dhe statusin e përshtatësit të shfaqur në klient. PPTP është një protokoll i vjetër, dhe nëse serveri ofron SSTP ose IKEv2, kalimi është zakonisht përdorim më i mirë i kohës sesa rregullimi i një rruge që varet nga kalimi i protokollit 47 në çdo hop. Kontrollo certifikatën dhe kontratën e autentikimit të zëvendësuesit në vend që të kopjosh një profil të vjetër në një version të ri.