PPTP klijenti na DD-WRT-u ne vide jedni druge: pet provjera

Dva laptopa se dial-in na PPTP server na DD-WRT uređaju, svaki dobije adresu, a nijedan ne može pingovati onaj drugi. Dijeljeni folderi se nikad ne pojave i prva pomisao je da maska 255.255.255.255 koju router dijeli mora biti pogrešna. Nije to uzrok, i promjena toga neće stvoriti ni jednog novog susjeda. Prođite pet provjera ispod po redu i zaustavite se čim jedna padne, jer svaka ima drugačiji lijek.

Prva provjera: /32 nije greška

PPTP nosi PPP, a PPP link spaja točno dvije krajnje točke: vaš klijent i server. Maska mreže opisuje koje adrese dijele lokalni segment, a ovdje segmenta nema, samo peer na drugom kraju jedne žice. Maska od samih jedinica kaže upravo to, pa DD-WRT daje ispravnu vrijednost za tu vrstu linka. Adresa je adresa peera, a ne adresa sučelja na LAN-u.

Maska 255.255.255.0 pripada zajedničkom mediju s više stotina uređaja, a njeno stavljanje na PPP sučelje također ne bi učinilo drugu stranu tunela susjedom.

Druga provjera: pročitajte vrijednosti na stranici PPTP servera

Sve što je važno nalazi se pod Usluge, VPN, PPTP server. Uključite server, postavite adresu servera na LAN adresu routera i držite raspon klijenata izvan DHCP poola, da dial-in klijent i žičana mašina ne dobiju istu adresu. Pod CHAP-Secrets dodajte po jedan redak za svaki račun u obliku username * password *, bez razmaka unutar imena. Primijenite, pa se povežite profilom koji imenuje router i jedan od tih računa.

Mjesto na kojem klijent stane govori vam koji sloj pregledati. Klijent koji se autentificira ali ne dobije adresu ima problem s poolom ili tajnama; klijent koji dobije adresu i ništa ne dosegne ima problem s usmjeravanjem ili vatrozidom.

Treća provjera: potražite rutu između dva peera

Svaki tunel koji završava na routeru ima svoje sučelje, obično ppp0, ppp1 i tako dalje. Promet od jednog klijenta prema drugom mora se usmjeravati između tih sučelja, a router ga mora biti voljan prosljeđivati. Pokrenite ip route na routeru i potražite host rutu za svaki povezani peer koja pokazuje na odgovarajuće PPP sučelje. Ako peeru nedostaje ruta, tunel nije do kraja podignut, što god tvrdio zaslon sa statusom klijenta.

Dvije host rute prema dva odvojena ppp sučelja oblik je koji želite prije nego što krenete dalje.

Četvrta provjera: pregledajte FORWARD lanac, ne INPUT

Promet između klijenata se prosljeđuje, a ne prihvaća lokalno, pa je INPUT lanac pogrešno mjesto za gledanje. Pokrenite iptables -L FORWARD -v -n i potražite drop pravilo koje hvata PPP sučelja, uz brojače paketa koji pokazuju dolazi li išta do lanca. Zadana drop politika bez pravila prihvata za tunelski promet daje upravo simptom s kojim ste počeli: svaki klijent sam je u redu, zajedno su nevidljivi jedan drugome.

Ako mali pingovi rade a veliki prijenosi zapinju, tunel se fragmentira, a ne blokira. PPTP preko PPP-a obično traži MTU i MRU oko 1450, a ostavljanje na 1500 daje link koji prođe rukovanje i padne na stvarnom teretu.

Peta provjera: odlučite što pristup internetu treba raditi

Klijentima koji trebaju pregledavati kroz ured potrebno je prevođenje izvorne adrese prema WAN sučelju. Klijentima koji trebaju dosegnuti samo LAN potrebna je ruta i ništa drugo. To su različite namjere s različitim skupovima pravila, a pitanje maske posve skriva tu drugu odluku. Zapišite kakvo ponašanje želite prije nego dodate i jedno pravilo, jer klijent koji neočekivano izađe kroz uredsku liniju iznenađenje je koje ispliva na sastanku, a ne u logu.

Posljednja napomena, nevezana uz popravak: PPTP je zastario i njegova autentifikacija je godinama slomljena. Popis iznad i dalje objašnjava što PPP link radi, a isto razmišljanje vrijedi i ako klijente kasnije premjestite na moderan tunel.