PPTP-ul MikroTik cade? Reparați ruta către server

Un client PPTP din RouterOS se conectează, mută puțin trafic și apoi moare, iar jurnalul arată ca o problemă cu acreditările sau cu serverul. De obicei nu este niciuna. Tunelul transportă propriile pachete pentru că ruta către server se potrivește și cu ruta pe care a instalat-o tunelul. Cealaltă parte nu mai aude routerul, iar sesiunea moare în timp ce interfața încă susține că este activă.

Remedierea este o rută, sau o setare, care ține serverul accesibil prin WAN-ul fizic. Care dintre ele depinde de dacă routerul trebuie să fie o poartă de tunel complet.

Simptomul: se conectează, mută trafic, moare

Modelul se repetă la fiecare reconectare, iar acesta este primul indiciu util. O parolă respinsă eșuează înainte ca interfața să urce, o configurație greșită a paravanului blochează de obicei o singură direcție, iar o buclă de rutare lasă interfața să se stabilească și apoi o sugrumă. Uitați-vă la contoare: tunelul arată o rafală de pachete inițiale și apoi nimic, în timp ce interfața WAN continuă să trimită copii încapsulate. Acesta este un router care își hrănește propria ieșire înapoi în sine.

PPTP face acest lucru ușor de declanșat pentru că transportul este IP simplu către adresa serverului, nu un tunel al cărui capăt îndepărtat se află într-o altă subrețea. Orice redirecționează acea adresă redirecționează și transportul odată cu ea.

De ce tunelul își înghite propriile pachete

Când clientul se conectează, instalează o rută a cărei poartă este interfața tunelului. Dacă profilul instalează și o rută implicită, atunci fiecare destinație fără o potrivire mai specifică, inclusiv adresa publică a serverului, este rezolvată către tunel. Routerul încapsulează pachetul, adresează pachetul exterior către server și caută din nou ruta: aceeași destinație, același implicit, același tunel. În funcție de versiune, această recursie este aruncată, pusă în coadă sau buclată până când cealaltă parte renunță și închide sesiunea.

Producătorii de echipamente adaugă adesea automat o rută de gazdă pentru propriul server, exact pentru a evita acest lucru. RouterOS nu presupune acest lucru, așa că operatorul trebuie să exprime excepția sau să evite ruta implicită de la început.

Fixați adresa serverului pe WAN

Adăugați cea mai îngustă rută posibilă: un /32 pentru adresa publică a serverului, cu poarta furnizorului ca următor salt, pe interfața care ajunge la internet. Un /32 bate orice implicit prin lungimea prefixului, iar o distanță mai mică câștigă dacă există deja o altă rută pentru același prefix. Apoi reconectați-vă și confirmați că ruta este activă, nu doar prezentă în listă.

/ip route add dst-address=198.51.100.10/32 gateway=192.0.2.1 distance=10

Dacă poarta furnizorului este învățată prin DHCP, folosiți adresa de poartă instalată de DHCP, sau legați ruta de interfață dacă versiunea o acceptă. O poartă codificată fix care se schimbă la următoarea închiriere este o defecțiune amânată. Verificați adresa după o reconectare a WAN-ului, pentru că atunci apare o poartă învechită și tunelul începe din nou să cadă.

Sau împiedicați tunelul să revendice ruta implicită

O sucursală care are nevoie de o singură rețea LAN îndepărtată ar trebui să țină profilul PPTP complet departe de ruta implicită. Dezactivați acea opțiune în profilul clientului și adăugați în schimb o rută specifică pentru prefixul îndepărtat prin interfața tunelului. Traficul obișnuit rămâne pe WAN, transportul propriu al tunelului își păstrează calea naturală, iar tabelul de rutare devine mai ușor de explicat. Acesta este designul mai bun pentru o sucursală care are nevoie de o subrețea, nu pentru un router care ar trebui să fie ieșirea sitului.

Tunelul complet are propriile cerințe: rutare bazată pe politică pentru surse selectate, un plan pentru traficul de retur și o decizie privind ce se întâmplă când tunelul cade. Nimic din toate acestea nu este rezolvat de ruta de gazdă, care doar ține transportul în viață.

Verificați pe straturi, apoi închideți gaura de administrare

Testați pe straturi: faceți ping către adresa publică a serverului înainte de conectare, ping către poarta îndepărtată după conectare, apoi ping către un host din LAN-ul îndepărtat. Adăugați masquerade pe interfața tunelului dacă gazdele din spatele routerului au nevoie ca răspunsurile să se întoarcă prin ea.

/ip firewall nat add chain=srcnat out-interface=pptp-out1 action=masquerade

Apoi reporniți routerul sau forțați o reconectare a WAN-ului și repetați cele trei ping-uri, pentru că o rută care există doar în configurația aflată în rulare nu va supraviețui. O configurație exportată într-un fișier de rezervă și restaurată mai târziu este celălalt loc unde se rupe, deoarece ruta poate lipsi din export dacă a fost adăugată în timpul rulării.

În final, limitați Winbox și administrarea web la adrese sursă cunoscute înainte de a publica orice modificare de VPN sau de rută. Un router care termină tuneluri este o țintă de administrare, iar portul 80 deschis către lume este o constatare mai mare decât ruta pe care tocmai ați reparat-o.