DD-WRT PPTP klienti nesasniedz viens otru: piecas pārbaudes

Divi klēpjdatori pieslēdzas DD-WRT iekārtas PPTP serverim, katrs saņem adresi, un neviens nevar pingot otru. Koplietotās mapes nekad neparādās, un pirmā doma ir, ka maršrutētāja izdalītā 255.255.255.255 maska noteikti ir nepareiza. Tā nav vaina, un tās maiņa neradīs nevienu jaunu kaimiņu. Veiciet piecas pārbaudes zemāk pēc kārtas un apstājieties, tiklīdz kāda neizdodas, jo katrai ir cits līdzeklis.

Pirmā pārbaude: /32 nav kļūda

PPTP pārvadā PPP, un PPP saite savieno tieši divus galapunktus: jūsu klientu un serveri. Tīkla maska apraksta, kuras adreses dala lokālo segmentu, un šeit segmenta nav, ir tikai vienaudzis viena vada otrā galā. Maska no vieniem vienīgiem saka tieši to, tāpēc DD-WRT izdala pareizo vērtību šim saites tipam. Adrese ir vienaudža adrese, nevis saskarnes adrese LAN tīklā.

Maska 255.255.255.0 pieder koplietotai videi ar simtiem ierīču, un tās uzlikšana PPP saskarnei arī nepadarīs tuneļa otru pusi par kaimiņu.

Otrā pārbaude: izlasiet PPTP servera lapas vērtības

Visi svarīgie iestatījumi ir sadaļā Pakalpojumi, VPN, PPTP serveris. Ieslēdziet serveri, iestatiet servera adresi uz maršrutētāja LAN adresi un turiet klientu diapazonu ārpus DHCP baseina, lai piezvanītais klients un kabelētā iekārta nesaņemtu vienu un to pašu adresi. Sadaļā CHAP-Secrets pievienojiet vienu rindu katram kontam formā username * password *, bez atstarpēm vārda iekšienē. Piemērojiet, pēc tam pievienojieties ar profilu, kas nosauc maršrutētāju un vienu no šiem kontiem.

Vieta, kur klients apstājas, pasaka, kuru slāni pārbaudīt. Klients, kas autentificējas, bet nesaņem adresi, ir baseina vai noslēpumu problēma; klients, kas saņem adresi un neko nesasniedz, ir maršrutēšanas vai ugunsmūra problēma.

Trešā pārbaude: meklējiet maršrutu starp diviem vienaudžiem

Katrs tunelis, kas beidzas maršrutētājā, ir sava saskarne, parasti ppp0, ppp1 un tā tālāk. Datplūsmai no viena klienta uz otru jābūt maršrutētai starp šīm saskarnēm, un maršrutētājam jābūt gatavam to pārsūtīt. Palaidiet ip route maršrutētājā un meklējiet resursdatora maršrutu katram pievienotajam vienaudzim, kas norāda uz atbilstošo PPP saskarni. Ja vienaudzim trūkst maršruta, tunelis nav pilnībā uzcelts, lai ko apgalvotu klienta statusa ekrāns.

Divi resursdatora maršruti uz divām atsevišķām ppp saskarnēm ir tā forma, kuru vēlaties pirms došanās tālāk.

Ceturtā pārbaude: skatiet FORWARD ķēdi, nevis INPUT

Datplūsma starp klientiem tiek pārsūtīta, nevis pieņemta lokāli, tāpēc INPUT ķēde ir nepareizā vieta. Palaidiet iptables -L FORWARD -v -n un meklējiet nomešanas noteikumu, kas aptver PPP saskarnes, kā arī pakešu skaitītājus, kas rāda, vai ķēdē vispār kaut kas nonāk. Noklusējuma nomešanas politika bez pieņemšanas noteikuma tuneļa datplūsmai rada tieši tos simptomus, ar kuriem sākāt: katrs klients atsevišķi ir kārtībā, kopā tie viens otram ir neredzami.

Ja mazi pingi strādā un lieli pārnesumi iesprūst, tunelis tiek sadrumstalots, nevis bloķēts. PPTP virs PPP parasti grib MTU un MRU ap 1450, un, atstājot tos uz 1500, jūs iegūstat saiti, kas iztur rokasspiedienus un neizdodas reālā slodzē.

Piektā pārbaude: izlemiet, ko interneta piekļuvei jādara

Klientiem, kuriem jāpārlūko caur biroju, nepieciešama avota adreses tulkošana uz WAN saskarni. Klientiem, kuriem jāsasniedz tikai LAN, nepieciešams maršruts un nekas vairāk. Tie ir atšķirīgi nodomi ar atšķirīgiem noteikumu kopumiem, un maskas jautājums pilnībā apslēpj šo otro lēmumu. Pierakstiet, kādu uzvedību vēlējāties, pirms pievienojat kaut vienu noteikumu, jo klients, kas negaidīti iziet pa biroja līniju, ir pārsteigums, kas uzpeld sanāksmē, nevis žurnālā.

Pēdējā piezīme, kas nav saistīta ar labojumu: PPTP ir novecojis, un tā autentifikācija jau gadiem ir salauzta. Iepriekšējais saraksts joprojām izskaidro, ko dara PPP saite, un tie paši apsvērumi ir spēkā, ja vēlāk pārvietojat klientus uz modernu tuneli.