DD-WRT PPTP-kliendid ei jõua üksteiseni: viis kontrolli

Kaks sülearvutit valivad end sisse DD-WRT seadme PPTP-serverisse, kumbki saab aadressi, ja kumbki ei saa teisele pingi saata. Jagatud kaustad ei ilmu kunagi ja esimene mõte on, et ruuteri jagatav mask 255.255.255.255 peab olema vale. See ei ole süüdlane ja selle muutmine ei loo ühtki uut naabrit. Käige allolevad viis kontrolli järjest läbi ja lõpetage kohe, kui üks ebaõnnestub, sest igal on erinev ravim.

Esimene kontroll: /32 ei ole viga

PPTP kannab PPP-d ja PPP-lüli ühendab täpselt kaks otspunkti: teie klient ja server. Võrgumask kirjeldab, millised aadressid jagavad kohalikku segmenti, ja siin segmenti ei ole, on ainult partner ühe juhtme teises otsas. Ainult ühtedest koosnev mask ütleb täpselt seda, seega annab DD-WRT selle lülitüübi jaoks õige väärtuse. Aadress on partneri aadress, mitte liidese aadress LAN-is.

Mask 255.255.255.0 kuulub jagatud kandjale sadade seadmetega, ja selle panemine PPP-liidesele ei tee tunnelit teisel pool samuti naabriks.

Teine kontroll: lugege PPTP-serveri lehe väärtusi

Kõik olulised seaded on jaotises Teenused, VPN, PPTP-server. Lülitage server sisse, seadke serveri aadressiks ruuteri LAN-aadress ja hoidke kliendi vahemik DHCP poolist väljas, et sissehelistav klient ja kaabliga masin ei saaks sama aadressi. Lisage CHAP-Secretsi alla üks rida konto kohta kujul username * password *, ilma tühikuteta nime sees. Rakendage ja seejärel ühenduge profiiliga, mis nimetab ruuterit ja üht neist kontodest.

Koht, kus klient peatub, ütleb teile, millist kihti uurida. Klient, kes autendib end, aga ei saa aadressi, on pooli või saladuste probleem; klient, kes saab aadressi ja ei jõua kuhugi, on marsruutimise või tulemüüri probleem.

Kolmas kontroll: otsige marsruuti kahe partneri vahel

Iga ruuteril lõppev tunnel on omaette liides, tavaliselt ppp0, ppp1 ja nii edasi. Liiklus ühest kliendist teise tuleb nende liideste vahel marsruutida ja ruuter peab olema valmis seda edasi saatma. Käivitage ruuteril ip route ja otsige iga ühendatud partneri jaoks host-marsruuti, mis osutab vastavale PPP-liidesele. Kui partneril puudub marsruut, ei ole tunnel täielikult üleval, mida iganes kliendi olekuekraan väidab.

Kaks host-marsruuti kahe eraldi ppp-liidese suunas on see kuju, mida enne edasiminekut soovite.

Neljas kontroll: vaadake FORWARD-ahelat, mitte INPUT-i

Klientide vaheline liiklus edastatakse, mitte ei võeta kohapeal vastu, seega on INPUT-ahel vale koht. Käivitage iptables -L FORWARD -v -n ja otsige drop-reeglit, mis haarab PPP-liidesed, pluss paketiloendureid, mis näitavad, kas ahelani jõuab üldse midagi. Vaikimisi drop-poliitika ilma tunneliliikluse accept-reeglita annab täpselt selle sümptomi, millega alustasite: iga klient üksi on korras, koos on nad teineteise jaoks nähtamatud.

Kui väikesed pingid töötavad ja suured ülekanded takerduvad, killustub tunnel, mitte ei blokeeru. PPTP üle PPP tahab tavaliselt MTU-d ja MRU-d umbes 1450, ja nende jätmine 1500 peale annab lüli, mis läbib kätlused ja kukub läbi tegeliku koormuse juures.

Viies kontroll: otsustage, mida internetiühendus tegema peab

Kliendid, kes peavad kontori kaudu sirvima, vajavad lähteaadressi tõlget WAN-liidese suunas. Kliendid, kes peavad jõudma ainult LAN-i, vajavad marsruuti ja mitte midagi muud. Need on erinevad kavatsused erinevate reeglistikega ja maski küsimus varjab selle teise otsuse täielikult. Kirjutage üles, millist käitumist soovisite, enne kui lisate ühegi reegli, sest klient, kes ootamatult kontori liini kaudu välja läheb, on üllatus, mis kerkib esile koosolekul, mitte logis.

Viimane märkus, mis ei puuduta parandust: PPTP on vananenud ja selle autentimine on aastaid katki olnud. Ülalolev nimekiri selgitab siiski, mida PPP-lüli teeb, ja sama mõttekäik kehtib, kui viite kliendid hiljem moodsale tunnelile.