Odjemalci PPTP na DD-WRT se ne vidijo med seboj: pet preveritev

Dva prenosnika se prijavita v strežnik PPTP na napravi DD-WRT, vsak dobi naslov, in nobeden ne more pingati drugega. Deljene mape se nikoli ne pojavijo in prva misel je, da mora biti maska 255.255.255.255, ki jo daje usmerjevalnik, napačna. To ni vzrok, in sprememba ne bo ustvarila niti enega novega soseda. Izvedite pet preveritev spodaj po vrsti in se ustavite takoj, ko ena ne uspe, ker ima vsaka drugo zdravilo.

Prva preveritev: /32 ni napaka

PPTP prenaša PPP, povezava PPP pa poveže natanko dva konca: vašega odjemalca in strežnik. Maska omrežja opisuje, kateri naslovi si delijo lokalni segment, tu pa segmenta ni, le partner na drugem koncu ene žice. Maska samih enic pove natanko to, zato DD-WRT daje pravilno vrednost za to vrsto povezave. Naslov je naslov partnerja, ne naslov vmesnika v lokalnem omrežju.

Maska 255.255.255.0 spada na skupni medij s stotimi napravami, in tudi na vmesniku PPP druge strani tunela ne bi naredila za soseda.

Druga preveritev: preberite vrednosti na strani strežnika PPTP

Vse pomembne nastavitve so v Storitve, VPN, Strežnik PPTP. Vklopite strežnik, nastavite naslov strežnika na naslov LAN usmerjevalnika in območje odjemalcev držite zunaj bazena DHCP, da klicoči odjemalec in žični računalnik ne dobita istega naslova. Pod CHAP-Secrets dodajte po eno vrstico na račun v obliki username * password *, brez presledkov v imenu. Uporabite, nato se povežite s profilom, ki navaja usmerjevalnik in enega od teh računov.

Kje se odjemalec ustavi, pove, katero plast pregledati. Odjemalec, ki se overi, a ne dobi naslova, je težava bazena ali skrivnosti; odjemalec, ki dobi naslov in ničesar ne doseže, je težava usmerjanja ali požarnega zidu.

Tretja preveritev: poiščite pot med dvema partnerjema

Vsak tunel, ki se konča na usmerjevalniku, je svoj vmesnik, običajno ppp0, ppp1 in tako naprej. Promet od enega odjemalca do drugega mora biti usmerjen med temi vmesniki, usmerjevalnik pa mora biti pripravljen promet posredovati. Zaženite ip route na usmerjevalniku in poiščite pot do gostitelja za vsakega povezanega partnerja, ki kaže na ustrezen vmesnik PPP. Če partnerju manjka pot, tunel ni popolnoma vzpostavljen, kar koli trdi zaslon stanja odjemalca.

Dve poti do gostiteljev na dva ločena vmesnika ppp je oblika, ki jo želite, preden greste naprej.

Četrta preveritev: poglejte verigo FORWARD, ne INPUT

Promet med odjemalci se posreduje, ne sprejema lokalno, zato je veriga INPUT napačno mesto. Zaženite iptables -L FORWARD -v -n in poiščite pravilo zavrnitve, ki ujame vmesnike PPP, skupaj s števci paketov, ki kažejo, ali do verige sploh kaj pride. Privzeta politika zavrnitve brez pravila sprejema za tunelski promet ustvari natanko tisti simptom, s katerim ste začeli: vsak odjemalec sam je v redu, skupaj so drug za drugega nevidni.

Če majhni pingi delujejo in veliki prenosi obstanejo, se tunel drobi, ne blokira. PPTP prek PPP običajno zahteva MTU in MRU okoli 1450, in če ju pustite na 1500, dobite povezavo, ki preide rokovanja in odpove pri resnični obremenitvi.

Peta preveritev: odločite, kaj naj počne dostop do interneta

Odjemalci, ki naj brskajo skozi pisarno, potrebujejo prevajanje izvornega naslova proti vmesniku WAN. Odjemalci, ki naj dosežejo le LAN, potrebujejo pot in nič drugega. To so različni nameni z različnimi nabori pravil, vprašanje maske pa to drugo odločitev popolnoma skrije. Zapišite, kakšno vedenje ste želeli, preden dodate eno samo pravilo, ker je odjemalec, ki nepričakovano odide skozi pisarniško linijo, presenečenje, ki se pojavi na sestanku, ne v dnevniku.

Zadnja opomba, nepovezana s popravkom: PPTP je zastarel in njegova overitev je že leta pokvarjena. Zgornji seznam še vedno razlaga, kaj počne povezava PPP, in enaka logika velja, če pozneje premaknete odjemalce na sodoben tunel.