Twee skootrekenaars skakel in by die PPTP-bediener op 'n DD-WRT-boks, elkeen kry 'n adres, en nie een kan die ander ping nie. Gedeelde gidse verskyn nooit en die eerste ingewing is dat die 255.255.255.255-masker wat die router uitdeel verkeerd moet wees. Dit is nie die fout nie, en om dit te verander sal nie een nuwe buur skep nie. Werk die vyf kontroles hieronder in volgorde deur en stop sodra een faal, want elkeen het 'n ander kuur.

Kontrole een: die /32 is nie die fout nie

PPTP dra PPP, en 'n PPP-skakel verbind presies twee eindpunte: jou kliënt en die bediener. 'n Netmasker beskryf watter adresse 'n plaaslike segment deel, en hier is geen segment nie, net die eweknie aan die ander kant van een draad. 'n Masker van almal-enes sê presies dit, so DD-WRT deel die korrekte waarde vir die skakeltipe uit. Die adres is 'n eweknie-adres, nie 'n koppelvlakadres op 'n LAN nie.

'n 255.255.255.0-masker hoort op 'n gedeelde medium met honderde toestelle, en om dit op 'n PPP-koppelvlak te sit sou ook nie die ander kant van die tonnel 'n buur maak nie.

Kontrole twee: lees die waardes op die PPTP-bedienerblad

Die instellings wat saak maak, is almal op Dienste, VPN, PPTP-bediener. Aktiveer die bediener, stel die bedieneradres op die router se LAN-adres, en hou die kliëntreeks buite die DHCP-poel sodat 'n inkies-kliënt en 'n bedrade masjien nie dieselfde adres kry nie. Voeg onder CHAP-Secrets een reël per rekening by in die vorm username * password *, met geen spasies in die naam nie. Pas toe en verbind dan met 'n profiel wat die router en een van daardie rekeninge noem.

Waar die kliënt stop, sê vir jou watter laag om te ondersoek. 'n Kliënt wat verifieer maar geen adres kry nie, is 'n poel- of geheimeprobleem; 'n kliënt wat 'n adres kry en niks bereik nie, is 'n roeterings- of vuurmuurprobleem.

Kontrole drie: soek na 'n roete tussen die twee eweknieë

Elke tonnel wat op die router eindig, is sy eie koppelvlak, gewoonlik ppp0, ppp1 en so meer. Verkeer van een kliënt na die ander moet tussen daardie koppelvlakke geroteer word, en die router moet bereid wees om dit aan te stuur. Voer ip route op die router uit en soek na 'n gasheerroete vir elke gekoppelde eweknie wat na die bypassende PPP-koppelvlak wys. As 'n eweknie 'n roete kort, is die tonnel nie heeltemal op nie, ongeag wat die kliënt se statusskerm beweer.

Twee gasheerroetes na twee aparte ppp-koppelvlakke is die vorm wat jy wil hê voordat jy verder gaan.

Kontrole vier: ondersoek die FORWARD-ketting, nie INPUT nie

Kliënt-tot-kliënt-verkeer word aangestuur, nie plaaslik aanvaar nie, so die INPUT-ketting is die verkeerde plek om te kyk. Voer iptables -L FORWARD -v -n uit en soek na 'n drop-reël wat die PPP-koppelvlakke vang, plus die pakkettellers wat wys of enigiets hoegenaamd by die ketting aankom. 'n Verstek-dropbeleid sonder 'n aanvaardingsreël vir tonnelverkeer lewer presies die simptoom waarmee jy begin het: elke kliënt alleen is reg, saam is hulle onsigbaar vir mekaar.

As klein pings werk en groot oordragte vasdraai, word die tonnel gefragmenteer eerder as geblokkeer. PPTP oor PPP wil gewoonlik 'n MTU en MRU van omtrent 1450 hê, en om hulle op 1500 te los gee jou 'n skakel wat handskuddings slaag en op werklike loonvragte faal.

Kontrole vyf: besluit wat internettoegang moet doen

Kliënte wat veronderstel is om deur die kantoor te blaai, het bronadresvertaling na die WAN-koppelvlak nodig. Kliënte wat net die LAN moet bereik, het 'n roete en niks anders nodig nie. Dit is verskillende bedoelings met verskillende reëlstelle, en die maskervraag versteek hierdie tweede besluit heeltemal. Skryf neer watter gedrag jy wou hê voordat jy 'n enkele reël byvoeg, want 'n kliënt wat onverwags deur die kantoorlyn uitgaan, is 'n verrassing wat in 'n vergadering opduik eerder as in 'n log.

Een laaste nota, los van die regstelling: PPTP is verouderd en sy verifikasie is al jare lank gebreek. Die kontrolelys hierbo verduidelik steeds wat 'n PPP-skakel doen, en dieselfde redenasie geld as jy die kliënte later na 'n moderne tonnel skuif.

Verwante artikels