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

Dva se prijenosnika spajaju na PPTP poslužitelj na DD-WRT uređaju, svaki dobije adresu, a nijedan ne može pingati onaj drugi. Dijeljene mape se nikad ne pojave i prva je pomisao da maska 255.255.255.255 koju usmjerivač dijeli mora biti pogrešna. Nije to uzrok, i promjena toga neće stvoriti ni jednog novog susjeda. Prođite pet provjera ispod redom i zaustavite se čim jedna padne, jer svaka ima drukčiji lijek.

Prva provjera: /32 nije greška

PPTP nosi PPP, a PPP veza spaja točno dvije krajnje točke: vašeg klijenta i poslužitelj. 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 veze. 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 njezino stavljanje na PPP sučelje također ne bi učinilo drugu stranu tunela susjedom.

Druga provjera: pročitajte vrijednosti na stranici PPTP poslužitelja

Sve što je važno nalazi se pod Usluge, VPN, PPTP poslužitelj. Uključite poslužitelj, postavite adresu poslužitelja na LAN adresu usmjerivača i držite raspon klijenata izvan DHCP poola, da klijent koji se uvezuje i žičani stroj 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 usmjerivač 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 usmjerivaču 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 usmjerivač ga mora biti voljan prosljeđivati. Pokrenite ip route na usmjerivaču 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 vezu koja 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 zapisniku.

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