MikroTik PPTP falas? Riparu la itineron al la servilo

PPTP-kliento de RouterOS konektiĝas, transdonas iom da trafiko kaj poste silentiĝas, kaj la protokolo aspektas kiel problemo pri akreditaĵoj aŭ la servilo. Kutime ĝi estas nek unu nek la alia. La tunelo portas siajn proprajn transportajn pakaĵojn, ĉar la itinero al la servilo ankaŭ kongruas kun la itinero, kiun la tunelo instalas. La kontraŭulo ĉesas aŭdi la enkursigilon, kaj la seanco mortas dum la interfaco ankoraŭ asertas, ke ĝi funkcias.

La solvo estas unu itinero, aŭ unu agordo, kiu tenas la servilon atingebla tra la fizika WAN. Kiu el la du, dependas de tio, ĉu la enkursigilo estu pordego de plena tunelo.

La simptomo: konektiĝas, transdonas trafikon, mortas

La ŝablono ripetiĝas ĉe ĉiu rekonekto, kaj tio estas la unua utila indico. Rifuzita pasvorto fiaskas antaŭ ol la interfaco leviĝas, misagordo de fajroŝirmilo kutime blokas unu direkton, kaj itinera buklo lasas la interfacon establiĝi kaj poste sufokas ĝin. Rigardu la nombrilojn: la tunelo montras eksplodon de komencaj pakaĵoj kaj poste nenion, dum la WAN-interfaco daŭre sendas enkapsuligitajn kopiojn. Tio estas enkursigilo, kiu nutras sian propran eligon reen en sin mem.

PPTP faciligas tion, ĉar la transporto estas plata IP al la adreso de la servilo, ne tunelo, kies malproksima fino situas en alia subreto. Ĉio, kio redirectas tiun adreson, redirectas ankaŭ la transporton kun ĝi.

Kial la tunelo glutas siajn proprajn pakaĵojn

Kiam la kliento konektiĝas, ĝi instalas itineron, kies pordego estas la tunela interfaco. Se la profilo ankaŭ instalas defaŭltan itineron, tiam ĉiu celo sen pli specifa kongruo, inkluzive la publika adreso de la servilo, solviĝas al la tunelo. La enkursigilo enkapsuligas la pakaĵon, adresas la eksteran pakaĵon al la servilo kaj denove serĉas la itineron: sama celo, sama defaŭlto, sama tunelo. Depende de la versio, tiu rekursio estas forĵetata, vicigata aŭ buklata ĝis la kontraŭulo rezignas kaj disŝiras la seancon.

Fabrikantoj de aparatoj ofte aldonas gastigitan itineron por sia propra servilo aŭtomate, ĝuste por eviti tion. RouterOS ne supozas tion, do la operatoro devas esprimi la escepton aŭ eviti la defaŭltan itineron dekomence.

Fiksu la servilan adreson al la WAN

Aldonu la plej mallarĝan eblan itineron: /32 por la publika adreso de la servilo, kun la pordego de la provizanto kiel sekva salteto, sur la interfaco, kiu atingas la reton. /32 venkas ĉiun defaŭlton laŭ prefiksa longo, kaj pli malgranda distanco venkas, se alia itinero por la sama prefikso jam ekzistas. Poste rekonektu kaj konfirmu, ke la itinero estas aktiva, ne nur ĉeesta en la listo.

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

Se la pordego de la provizanto lerniĝas per DHCP, uzu la pordegan adreson, kiun DHCP instalas, aŭ ligu la itineron al la interfaco, se la versio subtenas tion. Fikskribita pordego, kiu ŝanĝiĝas ĉe la sekva luo, estas prokrastita paneo. Kontrolu la adreson post WAN-rekonekto, ĉar tiam aperas kaduka pordego kaj la tunelo denove ekfalas.

Aŭ haltigu la tunelon postuli la defaŭlton

Filio, kiu bezonas unu malproksiman LAN, devas teni la PPTP-profilon tute for de la defaŭlta itinero. Malŝaltu tiun opcion en la klienta profilo kaj aldonu anstataŭe specifan itineron por la malproksima prefikso tra la tunela interfaco. Ordinara trafiko restas sur la WAN, la propra transporto de la tunelo konservas sian naturan vojon, kaj la itinera tabelo fariĝas pli facile klarigebla. Tio estas la pli bona dezajno por filio, kiu bezonas unu subreton, ne por enkursigilo, kiu estu la elirejo de la ejo.

Plena tunelo havas siajn proprajn postulojn: politika enkursigado por elektitaj fontoj, plano por reena trafiko kaj decido pri tio, kio okazas, kiam la tunelo falas. Nenion el tio solvas la gastigita itinero, kiu nur tenas la transporton viva.

Kontrolu laŭ tavoloj, poste fermu la administran truon

Testu laŭ tavoloj: pingu la publikan adreson de la servilo antaŭ konekti, pingu la malproksiman pordegon post konekti, poste pingu gastigon en la malproksima LAN. Aldonu masquerade sur la tunela interfaco, se gastigoj malantaŭ la enkursigilo bezonas, ke respondoj revenu tra ĝi.

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

Poste restartigu la enkursigilon aŭ devigu WAN-rekonekton kaj ripetu la tri pingojn, ĉar itinero, kiu ekzistas nur en la kuranta agordo, ne postvivos. Agordo eksportita al savkopio kaj poste restarigita estas la alia loko, kie tio rompiĝas, ĉar la itinero povas manki en la eksporto, se ĝi estis aldonita dum la funkciado.

Fine, limigu Winbox kaj retan administradon al konataj fontadresoj antaŭ publikigi ajnan ŝanĝon de VPN aŭ itinero. Enkursigilo, kiu finigas tunelojn, estas administra celo, kaj haveno 80 malfermita al la mondo estas pli granda trovo ol la itinero, kiun vi ĵus riparis.