Klienci PPTP na DD-WRT nie widzą się nawzajem: pięć kontroli

Dwa laptopy łączą się z serwerem PPTP na urządzeniu DD-WRT, każdy dostaje adres, i żaden nie potrafi pingować drugiego. Udostępnione foldery nigdy się nie pojawiają, a pierwsza myśl jest taka, że maska 255.255.255.255 rozdawana przez router musi być błędna. To nie jest przyczyna, a jej zmiana nie stworzy ani jednego nowego sąsiada. Wykonaj pięć kontroli poniżej po kolei i zatrzymaj się, gdy któraś zawiedzie, bo każda ma inne lekarstwo.

Kontrola pierwsza: /32 nie jest błędem

PPTP przenosi PPP, a łącze PPP łączy dokładnie dwa końce: twojego klienta i serwer. Maska sieci opisuje, które adresy dzielą segment lokalny, a tutaj segmentu nie ma, jest tylko peer na drugim końcu jednego przewodu. Maska z samych jedynek mówi dokładnie to, więc DD-WRT podaje poprawną wartość dla tego typu łącza. Adres to adres peera, nie adres interfejsu w sieci LAN.

Maska 255.255.255.0 należy do wspólnego medium z setkami urządzeń, a umieszczenie jej na interfejsie PPP też nie zrobi z drugiej strony tunelu sąsiada.

Kontrola druga: odczytaj wartości na stronie serwera PPTP

Wszystkie istotne ustawienia są w Usługi, VPN, Serwer PPTP. Włącz serwer, ustaw adres serwera na adres LAN routera i trzymaj zakres klientów poza pulą DHCP, aby klient dial-in i maszyna przewodowa nie dostały tego samego adresu. W sekcji CHAP-Secrets dodaj jeden wiersz na konto w postaci username * password *, bez spacji w nazwie. Zastosuj, a potem połącz się profilem, który wskazuje router i jedno z tych kont.

Miejsce, w którym klient się zatrzymuje, mówi, którą warstwę oglądać. Klient, który się uwierzytelnia, ale nie dostaje adresu, to problem puli lub sekretów; klient, który dostaje adres i nic nie osiąga, to problem routingu lub zapory.

Kontrola trzecia: poszukaj trasy między dwoma peerami

Każdy tunel kończący się na routerze to własny interfejs, zwykle ppp0, ppp1 i tak dalej. Ruch od jednego klienta do drugiego musi być routowany między tymi interfejsami, a router musi być gotów go przekazywać. Uruchom ip route na routerze i poszukaj trasy do hosta dla każdego połączonego peera, wskazującej odpowiedni interfejs PPP. Jeśli peerowi brakuje trasy, tunel nie jest w pełni podniesiony, cokolwiek twierdzi ekran stanu klienta.

Dwie trasy do hostów przez dwa osobne interfejsy ppp to kształt, którego chcesz, zanim ruszysz dalej.

Kontrola czwarta: obejrzyj łańcuch FORWARD, nie INPUT

Ruch między klientami jest przekazywany, a nie przyjmowany lokalnie, więc łańcuch INPUT to złe miejsce. Uruchom iptables -L FORWARD -v -n i poszukaj reguły odrzucania, która łapie interfejsy PPP, oraz liczników pakietów pokazujących, czy cokolwiek do łańcucha dociera. Domyślna polityka odrzucania bez reguły akceptacji dla ruchu tunelu daje dokładnie ten objaw, od którego zacząłeś: każdy klient osobno jest w porządku, razem są dla siebie niewidoczni.

Jeśli małe pingi działają, a duże transfery się zacinają, tunel jest fragmentowany, a nie blokowany. PPTP nad PPP zwykle chce MTU i MRU około 1450, a pozostawienie ich na 1500 daje łącze, które przechodzi uzgadnianie, ale zawodzi przy rzeczywistym obciążeniu.

Kontrola piąta: zdecyduj, co ma robić dostęp do internetu

Klienci, którzy mają przeglądać przez biuro, potrzebują translacji adresu źródłowego w stronę interfejsu WAN. Klienci, którzy mają docierać tylko do LAN, potrzebują trasy i niczego więcej. To różne zamiary z różnymi zestawami reguł, a pytanie o maskę całkowicie ukrywa tę drugą decyzję. Zapisz, jakiego zachowania chciałeś, zanim dodasz choć jedną regułę, bo klient, który niespodziewanie wychodzi przez linię biurową, jest niespodzianką, która wychodzi na spotkaniu, a nie w logu.

Ostatnia uwaga, niezwiązana z poprawką: PPTP jest przestarzały, a jego uwierzytelnianie jest zepsute od lat. Powyższa lista nadal wyjaśnia, co robi łącze PPP, i to samo rozumowanie obowiązuje, jeśli później przeniesiesz klientów na nowoczesny tunel.