MikroTik PPTP bie? Rregullo rrugën drejt serverit

Një klient PPTP i RouterOS lidhet, lëviz pak trafik dhe pastaj vdes, ndërsa regjistri duket si problem kredencialesh ose serveri. Zakonisht nuk është as njëra as tjetra. Tuneli po mbart paketat e veta të transportit, sepse rruga drejt serverit përputhet edhe me rrugën që vendosi tuneli. Pala tjetër nuk e dëgjon më ruterin dhe sesioni vdes, ndërkohë që ndërfaqja vazhdon të pohojë se është e ngritur.

Zgjidhja është një rrugë, ose një cilësim, që e mban serverin të arritshëm përmes WAN-it fizik. Cila prej tyre varet nga fakti nëse ruteri është menduar si portë me tunel të plotë.

Simptoma: lidhet, lëviz trafik, vdes

Modeli përsëritet në çdo rilidhje, dhe kjo është e dhëna e parë e dobishme. Fjalëkalimi i refuzuar dështon para se ndërfaqja të ngrihet, konfigurimi i gabuar i firewall-it zakonisht bllokon një drejtim, ndërsa një cikël rrugëtimi lejon që ndërfaqja të vendoset dhe pastaj e mbyt. Shiko numëruesit: tuneli shfaq një shpërthim paketash fillestare dhe pastaj asgjë, ndërsa ndërfaqja WAN vazhdon të transmetojë kopje të enkapsuluara. Ky është një ruter që e kthen daljen e vet përsëri në vetvete.

PPTP e bën këtë të lehtë për t'u shkaktuar, sepse transporti është IP e thjeshtë drejt adresës së serverit, jo një tunel, skaji i largët i të cilit ndodhet në një nënrrjet tjetër. Çdo gjë që e ridrejton atë adresë ridrejton bashkë me të edhe transportin.

Pse tuneli i gëlltit paketat e veta

Kur klienti lidhet, ai vendos një rrugë, portë e së cilës është ndërfaqja e tunelit. Nëse profili vendos edhe një rrugë të paracaktuar, atëherë çdo destinacion pa një përputhje më specifike, përfshirë adresën publike të serverit, zgjidhet drejt tunelit. Ruteri e enkapsulon paketën, e adreson paketën e jashtme drejt serverit dhe e kërkon rrugën përsëri: e njëjta destinacion, e njëjta e paracaktuar, i njëjti tunel. Varësisht nga versioni, ai rekurzion hidhet, vihet në radhë ose përsëritet, derisa pala tjetër të dorëzohet dhe ta prishë sesionin.

Prodhuesit e pajisjeve shpesh shtojnë automatikisht një rrugë hosti për serverin e tyre, pikërisht për ta shmangur këtë. RouterOS nuk e supozon këtë, prandaj operatori duhet ta shprehë përjashtimin ose ta shmangë rrugën e paracaktuar që në fillim.

Fikso adresën e serverit në WAN

Shto rrugën më të ngushtë të mundshme: një /32 për adresën publike të serverit, me portën e ISP-së si hop tjetër, në ndërfaqen që arrin internetin. Një /32 e mund çdo rrugë të paracaktuar sipas gjatësisë së prefiksit, dhe një distancë më e ulët fiton nëse ekziston tashmë një rrugë tjetër për të njëjtin prefiks. Pastaj rilidhu dhe konfirmo që rruga është aktive, jo thjesht e pranishme në listë.

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

Nëse porta e ISP-së mësohet përmes DHCP, përdor adresën e portës që vendosi DHCP, ose lidhe rrugën me ndërfaqen nëse versioni e mbështet. Një portë e koduar fort që ndryshon në qiranë tjetër është një dështim i shtyrë. Kontrollo adresën pas një rilidhjeje WAN, sepse atëherë shfaqet një portë e vjetruar dhe tuneli fillon të bjerë përsëri.

Ose ndalo tunelin të marrë të paracaktuarën

Një degë që ka nevojë për një LAN të vetëm të largët duhet ta mbajë profilin PPTP plotësisht larg rrugës së paracaktuar. Fike atë opsion në profilin e klientit dhe shto në vend të tij një rrugë specifike për prefiksin e largët përmes ndërfaqes së tunelit. Trafiku i zakonshëm mbetet në WAN, transporti i vetë tunelit mban rrugën e tij natyrore, dhe tabela e rrugëtimit bëhet më e lehtë për t'u shpjeguar. Ky është dizajni më i mirë për një degë që ka nevojë për një nënrrjet, jo për një ruter që duhet të jetë dalja e sitit.

Tuneli i plotë ka kërkesat e veta: rrugëtim sipas politikës për burime të zgjedhura, një plan për trafikun e kthimit dhe një vendim për atë që ndodh kur tuneli bie. Asnjëra nga këto nuk zgjidhet nga rruga e hostit, e cila mban gjallë vetëm transportin.

Verifiko me shtresa, pastaj mbyll vrimën e menaxhimit

Testo me shtresa: bëj ping adresës publike të serverit para lidhjes, bëj ping portës së largët pas lidhjes, pastaj bëj ping një hosti në LAN-in e largët. Shto masquerade në ndërfaqen e tunelit nëse hostet pas ruterit kanë nevojë që përgjigjet të kthehen përmes tij.

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

Pastaj rindiz ruterin ose detyro një rilidhje WAN dhe përsërit tre ping-ët, sepse një rrugë që ekziston vetëm në konfigurimin e rrjedhshëm nuk do të mbijetojë. Vendi tjetër ku kjo prishet është konfigurimi i eksportuar në një skedar rezervë dhe i rikthyer më vonë, sepse rruga mund të mungojë në eksport nëse u shtua gjatë punës.

Së fundi, kufizo Winbox dhe menaxhimin në web vetëm në adresa burimore të njohura, përpara se të publikosh çdo ndryshim VPN ose rruge. Një ruter që përfundon tunelet është objektiv menaxhimi, dhe porta 80 e hapur ndaj botës është një gjetje më e madhe sesa rruga që sapo rregullove.