Kaksi kannettavaa soittaa DD-WRT-laitteen PPTP-palvelimeen, kumpikin saa osoitteen, eikä kumpikaan voi pingata toista. Jaetut kansiot eivät koskaan ilmesty, ja ensimmäinen ajatus on, että reitittimen jakama maski 255.255.255.255 on pakko olla väärä. Se ei ole syy, eikä sen muuttaminen luo yhtäkään uutta naapuria. Käy alla olevat viisi tarkistusta järjestyksessä läpi ja pysähdy heti, kun jokin epäonnistuu, sillä jokaisella on eri lääke.

Tarkistus yksi: /32 ei ole vika

PPTP kuljettaa PPP:tä, ja PPP-linkki yhdistää täsmälleen kaksi päätepistettä: asiakkaasi ja palvelimen. Verkkopeite kuvaa, mitkä osoitteet jakavat paikallisen segmentin, eikä tässä ole segmenttiä, vain vastapuoli yhden johdon toisessa päässä. Pelkistä ykkösistä koostuva peite sanoo juuri sen, joten DD-WRT jakaa tälle linkkityypille oikean arvon. Osoite on vastapuolen osoite, ei liitännän osoite lähiverkossa.

Maski 255.255.255.0 kuuluu jaettuun väliaineeseen, jossa on satoja laitteita, eikä sen laittaminen PPP-liitäntään tekisi tunnelin toisestakaan puolesta naapuria.

Tarkistus kaksi: lue PPTP-palvelimen sivun arvot

Kaikki merkitykselliset asetukset ovat kohdassa Palvelut, VPN, PPTP-palvelin. Ota palvelin käyttöön, aseta palvelimen osoitteeksi reitittimen lähiverkko-osoite ja pidä asiakasalue DHCP-poolin ulkopuolella, jotta sisäänsoittava asiakas ja kaapelilla kytketty kone eivät saa samaa osoitetta. Lisää CHAP-Secretsin alle yksi rivi kutakin tiliä kohden muodossa username * password *, ilman välilyöntejä nimen sisällä. Käytä ja yhdistä sitten profiililla, joka nimeää reitittimen ja jonkin noista tileistä.

Se, mihin asiakas pysähtyy, kertoo mitä kerrosta tutkia. Asiakas, joka todentuu mutta ei saa osoitetta, on poolin tai salaisuuksien ongelma; asiakas, joka saa osoitteen eikä tavoita mitään, on reitityksen tai palomuurin ongelma.

Tarkistus kolme: etsi reitti kahden vastapuolen väliltä

Jokainen reitittimellä päättyvä tunneli on oma liitäntänsä, yleensä ppp0, ppp1 ja niin edelleen. Liikenne asiakkaalta toiselle on reititettävä näiden liitäntöjen välillä, ja reitittimen on oltava halukas välittämään se. Aja ip route reitittimellä ja etsi jokaiselle yhdistetylle vastapuolelle isäntäreitti, joka osoittaa vastaavaan PPP-liitäntään. Jos vastapuolelta puuttuu reitti, tunneli ei ole täysin pystyssä, mitä asiakkaan tilanäyttö väittääkin.

Kaksi isäntäreittiä kahteen erilliseen ppp-liitäntään on se muoto, jonka haluat ennen kuin menet pidemmälle.

Tarkistus neljä: katso FORWARD-ketjua, ei INPUT-ketjua

Asiakkaiden välinen liikenne välitetään, ei hyväksytä paikallisesti, joten INPUT-ketju on väärä paikka. Aja iptables -L FORWARD -v -n ja etsi pudotus­sääntö, joka osuu PPP-liitäntöihin, sekä pakettilaskurit, jotka näyttävät tuleeko ketjuun ylipäätään mitään. Oletuspudotuskäytäntö ilman hyväksyntäsääntöä tunneliliikenteelle tuottaa täsmälleen sen oireen, josta aloitit: jokainen asiakas yksin on kunnossa, yhdessä ne ovat näkymättömiä toisilleen.

Jos pienet pingit toimivat ja suuret siirrot takkuavat, tunnelia pirstotaan eikä estetä. PPTP PPP:n päällä haluaa yleensä MTU:n ja MRU:n noin 1450, ja niiden jättäminen 1500:aan antaa linkin, joka läpäisee kättelyt ja epäonnistuu todellisella kuormalla.

Tarkistus viisi: päätä, mitä internet-yhteyden pitää tehdä

Asiakkaat, joiden on tarkoitus selata toimiston kautta, tarvitsevat lähdeosoitteen käännöksen WAN-liitäntää kohti. Asiakkaat, joiden on tarkoitus tavoittaa vain lähiverkko, tarvitsevat reitin eivätkä mitään muuta. Nämä ovat eri aikomuksia eri sääntöjoukoilla, ja peitekysymys kätkee tämän toisen päätöksen kokonaan. Kirjoita ylös, millaista käytöstä halusit, ennen kuin lisäät yhtäkään sääntöä, sillä asiakas, joka poistuu odottamatta toimiston linjan kautta, on yllätys, joka nousee esiin kokouksessa eikä lokissa.

Viimeinen huomautus, joka ei liity korjaukseen: PPTP on vanhentunut ja sen todentaminen on ollut rikki vuosia. Yllä oleva luettelo selittää silti, mitä PPP-linkki tekee, ja sama päättely pätee, jos siirrät asiakkaat myöhemmin nykyaikaiseen tunneliin.

Aiheeseen liittyvät artikkelit