PPTP-klientoj de DD-WRT ne atingas unu la alian: kvin kontroloj

Du tekkomputiloj alvokas la PPTP-servilon sur DD-WRT-aparato, ĉiu ricevas adreson, kaj neniu povas pingi la alian. Kunhavataj dosierujoj neniam aperas, kaj la unua instinkto estas, ke la masko 255.255.255.255, kiun la enkursigilo disdonas, devas esti malĝusta. Ĝi ne estas la kaŭzo, kaj ŝanĝo ne kreos eĉ unu novan najbaron. Trairu la kvin kontrolojn sube laŭ ordo kaj haltu tuj kiam unu malsukcesas, ĉar ĉiu havas alian kuracilon.

Kontrolo unu: la /32 ne estas la fuŝo

PPTP portas PPP, kaj PPP-ligilo kunigas ĝuste du finpunktojn: vian klienton kaj la servilon. Retmasko priskribas, kiuj adresoj dividas lokan segmenton, kaj ĉi tie segmento mankas, estas nur la samtavolano ĉe la alia fino de unu drato. Masko el nur unuoj diras ĝuste tion, do DD-WRT donas la ĝustan valoron por tiu ligila tipo. La adreso estas samtavola adreso, ne interfaca adreso en LAN.

Masko 255.255.255.0 apartenas al kunhava medio kun centoj da aparatoj, kaj meti ĝin sur PPP-interfacon ankaŭ ne farus la alian flankon de la tunelo najbaro.

Kontrolo du: legu la valorojn sur la paĝo de la PPTP-servilo

Ĉiuj gravaj agordoj troviĝas sub Servoj, VPN, PPTP-servilo. Ŝaltu la servilon, agordu la servilan adreson al la LAN-adreso de la enkursigilo, kaj tenu la klientan gamon ekster la DHCP-naĝejo, por ke alvokanta kliento kaj kabla maŝino ne ricevu la saman adreson. Sub CHAP-Secrets aldonu unu linion por konto en la formo username * password *, sen spacoj ene de la nomo. Apliki, poste konektiĝu per profilo, kiu nomas la enkursigilon kaj unu el tiuj kontoj.

La loko, kie la kliento haltas, diras al vi, kiun tavolon ekzameni. Kliento, kiu aŭtentiĝas sed ne ricevas adreson, estas problemo de naĝejo aŭ de sekretoj; kliento, kiu ricevas adreson kaj atingas nenion, estas problemo de itinado aŭ de fajroŝirmilo.

Kontrolo tri: serĉu itineron inter la du samtavolanoj

Ĉiu tunelo finiĝanta sur la enkursigilo estas propra interfaco, kutime ppp0, ppp1 kaj tiel plu. Trafiko de unu kliento al la alia devas esti itinata inter tiuj interfacoj, kaj la enkursigilo devas esti preta plusendi ĝin. Rulu ip route sur la enkursigilo kaj serĉu gastigan itineron por ĉiu konektita samtavolano, montrantan al la kongrua PPP-interfaco. Se samtavolano mankas itineron, la tunelo ne estas plene supren, kion ajn asertas la stata ekrano de la kliento.

Du gastigaj itineroj al du apartaj ppp-interfacoj estas la formo, kiun vi volas antaŭ ol iri plu.

Kontrolo kvar: ekzamenu la ĉenon FORWARD, ne INPUT

Trafiko inter klientoj estas plusendata, ne akceptata loke, do la ĉeno INPUT estas la malĝusta loko. Rulu iptables -L FORWARD -v -n kaj serĉu forĵetan regulon, kiu kaptas la PPP-interfacojn, plus la pakaĵajn nombrilojn, kiuj montras, ĉu io ajn alvenas al la ĉeno. Defaŭlta forĵeta politiko sen akcepta regulo por tunela trafiko produktas ĝuste la simptomon, kun kiu vi komencis: ĉiu kliento sola estas en ordo, kune ili estas nevideblaj unu por la alia.

Se malgrandaj pingoj funkcias kaj grandaj transigoj haltas, la tunelo estas fragmentata anstataŭ blokata. PPTP super PPP kutime volas MTU kaj MRU ĉirkaŭ 1450, kaj lasi ilin je 1500 donas al vi ligilon, kiu trapasas manpremojn kaj malsukcesas ĉe realaj ŝarĝoj.

Kontrolo kvin: decidu, kion faru la interreta aliro

Klientoj destinitaj por retumi tra la oficejo bezonas fontan tradukon al la WAN-interfaco. Klientoj destinitaj nur atingi la LAN bezonas itineron kaj nenion alian. Temas pri malsamaj intencoj kun malsamaj regularoj, kaj la demando pri la masko tute kaŝas tiun duan decidon. Skribu, kiun konduton vi volis, antaŭ ol aldoni eĉ unu regulon, ĉar kliento, kiu neatendite eliras tra la oficeja linio, estas surprizo, kiu aperas en kunveno anstataŭ en protokolo.

Unu lasta noto, senrilata al la riparo: PPTP estas eksmoda kaj ĝia aŭtentigo rompiĝis jam de jaroj. La listo supre ankoraŭ klarigas, kion faras PPP-ligilo, kaj la sama rezonado validas, se vi poste transigos la klientojn al moderna tunelo.