DD-WRT PPTP klientai vienas kito nepasiekia: penki patikrinimai

Du nešiojamieji kompiuteriai skambina į DD-WRT įrenginio PPTP serverį, kiekvienas gauna adresą, ir nė vienas negali pinginti kito. Bendrinami aplankai niekada nepasirodo, o pirmoji mintis – kad maršrutizatoriaus dalijama 255.255.255.255 kaukė tikrai neteisinga. Tai ne priežastis, ir jos pakeitimas nesukurs nė vieno naujo kaimyno. Atlikite penkis patikrinimus žemiau iš eilės ir sustokite, kai tik kuris nors nepavyksta, nes kiekvienas turi skirtingą vaistą.

Pirmas patikrinimas: /32 nėra klaida

PPTP perneša PPP, o PPP jungtis sujungia lygiai du galinius taškus: jūsų klientą ir serverį. Tinklo kaukė aprašo, kurie adresai dalijasi vietiniu segmentu, o čia segmento nėra, tik peer kitame vieno laido gale. Kaukė iš vienetų pasako būtent tai, tad DD-WRT pateikia teisingą šios jungties tipo reikšmę. Adresas yra peer adresas, o ne sąsajos adresas LAN tinkle.

255.255.255.0 kaukė priklauso bendrai terpei su šimtais įrenginių, o uždėjus ją ant PPP sąsajos kita tunelio pusė taip pat netaps kaimynu.

Antras patikrinimas: perskaitykite PPTP serverio puslapio reikšmes

Visi svarbūs nustatymai yra skiltyje Paslaugos, VPN, PPTP serveris. Įjunkite serverį, nustatykite serverio adresą į maršrutizatoriaus LAN adresą, o klientų diapazoną laikykite už DHCP telkinio, kad prisiskambinęs klientas ir laidu prijungtas kompiuteris negautų to paties adreso. Skiltyje CHAP-Secrets pridėkite po vieną eilutę kiekvienai paskyrai forma username * password *, be tarpų vardo viduje. Taikykite, tada prisijunkite profiliu, kuriame nurodytas maršrutizatorius ir viena iš tų paskyrų.

Vieta, kurioje klientas sustoja, pasako, kurį sluoksnį tikrinti. Klientas, kuris autentifikuojasi, bet negauna adreso, yra telkinio arba paslapčių problema; klientas, kuris gauna adresą ir nieko nepasiekia, yra maršrutizavimo arba ugniasienės problema.

Trečias patikrinimas: ieškokite maršruto tarp dviejų peer’ų

Kiekvienas maršrutizatoriuje pasibaigiantis tunelis turi savo sąsają, paprastai ppp0, ppp1 ir taip toliau. Srautas iš vieno kliento į kitą turi būti maršrutizuojamas tarp tų sąsajų, o maršrutizatorius turi būti pasirengęs jį persiųsti. Paleiskite ip route maršrutizatoriuje ir ieškokite kiekvieno prijungto peer’o maršruto į hostą, nukreipto į atitinkamą PPP sąsają. Jei peer’ui trūksta maršruto, tunelis nėra visiškai pakilęs, ką bebūtų teigiama kliento būsenos ekrane.

Du maršrutai į hostus per dvi atskiras ppp sąsajas – tokia forma, kurios norite prieš eidami toliau.

Ketvirtas patikrinimas: žiūrėkite FORWARD grandinę, ne INPUT

Srautas tarp klientų persiunčiamas, o ne priimamas vietoje, tad INPUT grandinė yra netinkama vieta. Paleiskite iptables -L FORWARD -v -n ir ieškokite numetimo taisyklės, kuri pagauna PPP sąsajas, bei paketų skaitiklių, rodančių, ar į grandinę apskritai kas nors patenka. Numatytoji numetimo politika be priėmimo taisyklės tunelio srautui sukuria būtent tą simptomą, nuo kurio pradėjote: kiekvienas klientas atskirai yra gerai, kartu jie vienas kitam nematomi.

Jei maži pingai veikia, o dideli perdavimai stringa, tunelis fragmentuojamas, o ne blokuojamas. PPTP per PPP paprastai nori maždaug 1450 MTU ir MRU, o palikus juos 1500 gaunate jungtį, kuri praeina rankos paspaudimus ir žlunga esant tikram krūviui.

Penktas patikrinimas: nuspręskite, ką turi daryti interneto prieiga

Klientams, kurie turi naršyti per biurą, reikia šaltinio adreso vertimo link WAN sąsajos. Klientams, kuriems reikia pasiekti tik LAN, pakanka maršruto ir nieko daugiau. Tai skirtingi ketinimai su skirtingais taisyklių rinkiniais, o kaukės klausimas visiškai paslepia šį antrą sprendimą. Užsirašykite, kokio elgesio norėjote, prieš pridėdami nors vieną taisyklę, nes klientas, netikėtai išeinantis per biuro liniją, yra staigmena, kuri iškyla susirinkime, o ne žurnale.

Paskutinė pastaba, nesusijusi su pataisymu: PPTP pasenęs, o jo autentifikavimas jau metus sulaužytas. Aukščiau pateiktas sąrašas vis dar paaiškina, ką daro PPP jungtis, ir tas pats samprotavimas galioja, jei vėliau perkelsite klientus į modernų tunelį.