PPTP-klanten op DD-WRT kinne elkoar net berikke: fiif kontrôles

Twa laptops dialle yn op de PPTP-tsjinner op in DD-WRT-kastke, elk krijt in adres, en gjinien kin de oare pingje. Dielde mappen ferskine nea en de earste gedachte is dat it masker 255.255.255.255 dat de router útdielt wol ferkeard wêze sil. It is net de skuld, en it feroarjen sil gjin inkelde nije buorman meitsje. Wurkje de fiif kontrôles hjirûnder yn folchoarder ôf en stop sa gau as ien falt, want elk hat in oare genêzing.

Kontrôle ien: de /32 is net de flater

PPTP draacht PPP, en in PPP-keppeling ferbynt krekt twa einpunten: jo klant en de tsjinner. In netmasker beskriuwt hokker adressen in lokaal segmint diele, en hjir is gjin segmint, allinnich de peer oan de oare kant fan ien tried. In masker fan allegearre ienen seit krekt dat, dus DD-WRT jout de krekte wearde foar dat type keppeling. It adres is in peer-adres, gjin ynterface-adres op in LAN.

In masker fan 255.255.255.0 heart op in dield medium mei hûnderttallen apparaten, en it op in PPP-ynterface setten soe ek de oare kant fan de tunnel gjin buorman meitsje.

Kontrôle twa: lês de wearden op de PPTP-tsjinnerside

Alle ynstellings dy't ta saken dogge steane ûnder Tsjinsten, VPN, PPTP-tsjinner. Skeakelje de tsjinner oan, set it tsjinneradres op it LAN-adres fan de router, en hâld it klantberik bûten de DHCP-pool, sadat in ynbeljende klant en in bekeabelde masine net itselde adres krije. Foegje ûnder CHAP-Secrets ien rigel per akkount ta yn 'e foarm username * password *, sûnder spaasjes yn 'e namme. Tapasse, en ferbyn dan mei in profyl dat de router en ien fan dy akkounts neamt.

Wêr't de klant stopt, fertelt jo hokker laach jo besjen moatte. In klant dy't autentisearret mar gjin adres krijt, is in pool- as geheimenprobleem; in klant dy't in adres krijt en neat berikt, is in routing- as firewallprobleem.

Kontrôle trije: sykje in rûte tusken de twa peers

Elke tunnel dy't op 'e router einiget is syn eigen ynterface, meast ppp0, ppp1 ensafuorthinne. Ferkear fan de iene klant nei de oare moat tusken dy ynterfaces rûte wurde, en de router moat ree wêze it troch te stjoeren. Rinnende ip route op 'e router en sykje foar elke ferbûne peer in hostrûte dy't nei it byhearrende PPP-ynterface wiist. As in peer in rûte mist, is de tunnel net folslein omheech, wat it statusbyld fan de klant ek beweart.

Twa hostrûtes nei twa aparte ppp-ynterfaces is de foarm dy't jo wolle foardat jo fierder gean.

Kontrôle fjouwer: besjoch de FORWARD-ketting, net INPUT

Ferkear tusken klanten wurdt trochstjoerd, net lokaal akseptearre, dus de INPUT-ketting is it ferkearde plak. Rinnende iptables -L FORWARD -v -n en sykje in drop-regel dy't de PPP-ynterfaces pakt, plus de pakketstellers dy't sjen litte oft der wol eat by de ketting oankomt. In standert drop-belied sûnder akseptregel foar tunnelferkear jout krekt it symptoom dêr't jo mei begûnen: elke klant allinnich is goed, tegearre binne se foar elkoar ûnsichtber.

As lytse pings wurkje en grutte oerdrachten fêstrinne, wurdt de tunnel fragmintearre ynstee fan blokkearre. PPTP oer PPP wol normaal in MTU en MRU fan omtrint 1450, en se op 1500 litte jout in keppeling dy't hânskuddings hellet en op echte ladingen falt.

Kontrôle fiif: beslute wat ynternet tagong dwaan moat

Klanten dy't troch it kantoar browse moatte, hawwe boarne-oersetting nei it WAN-ynterface nedich. Klanten dy't allinnich it LAN berikke moatte, hawwe in rûte nedich en fierder neat. Dat binne ferskate bedoelings mei ferskate regelsets, en de maskerfrage ferberget dy twadde beslissing hielendal. Skriuw op hokker gedrach jo woene foardat jo ien regel tafoegje, want in klant dy't ûnferwachts troch de kantoarline nei bûten giet is in ferrassing dy't yn in gearkomste boppedaalkomt, net yn in log.

In lêste notysje, los fan 'e reparaasje: PPTP is ferâldere en syn autentikaasje is jierrenlang stikken. De list hjirboppe ferklearret noch hieltyd wat in PPP-keppeling docht, en deselde redenearring jildt as jo de klanten letter nei in moderne tunnel ferhúzje.