MikroTik PPTP bumabagsak? Ayusin ang ruta papunta sa server

Ang isang PPTP client ng RouterOS ay kumokonekta, nagpapadala ng kaunting trapiko, at pagkatapos ay tahimik na, at ang log ay mukhang problema sa kredensyal o sa server. Karaniwang wala sa dalawa. Ang tunnel ay nagdadala ng sarili nitong mga packet ng transport dahil ang ruta papunta sa server ay tumutugma rin sa rutang inilagay ng tunnel. Humihinto ang kabilang dulo sa pakikinig sa router at namamatay ang sesyon habang ang interface ay nag-aangkin pa rin na ito ay nakaup.

Ang solusyon ay isang ruta, o isang setting, na nagpapanatili sa server na maabot sa pisikal na WAN. Alin sa dalawa ang depende kung ang router ay dapat maging gateway ng buong tunnel.

Sintomas: kumokonekta, nagpapadala ng trapiko, namamatay

Umuulit ang pattern sa bawat muling pagkonekta, at iyon ang unang kapaki-pakinabang na palatandaan. Ang tinanggihang password ay nabigo bago pa umangat ang interface, ang maling configuration ng firewall ay karaniwang humaharang sa isang direksyon, at ang routing loop ay hinahayaan ang interface na magtatag at pagkatapos ay sinasakal ito. Tingnan ang mga counter: nagpapakita ang tunnel ng bugso ng mga paunang packet at pagkatapos ay wala, habang ang WAN interface ay patuloy na nagpapadala ng mga nakabalot na kopya. Iyon ay isang router na ibinabalik ang sariling output papasok sa sarili nito.

Pinapadali ng PPTP na mapukaw ito dahil ang transport ay plain IP papunta sa address ng server, hindi isang tunnel na ang malayong dulo ay nasa ibang subnet. Anumang bagay na naglilihis sa address na iyon ay naglilihis din sa transport kasama nito.

Bakit nilulunok ng tunnel ang sarili nitong mga packet

Kapag kumonekta ang client, naglalagay ito ng ruta na ang gateway ay ang interface ng tunnel. Kung ang profile ay naglalagay din ng default na ruta, ang bawat destinasyon na walang mas tiyak na tugma, kasama ang pampublikong address ng server, ay nireresolba patungo sa tunnel. Binabalot ng router ang packet, iniaaddress ang panlabas na packet sa server, at hinahanap muli ang ruta: parehong destinasyon, parehong default, parehong tunnel. Depende sa release, ang rekursyong iyon ay itinatapon, ipinipila, o inuulit hanggang sumuko ang kabilang dulo at putulin ang sesyon.

Madalas awtomatikong nagdaragdag ang mga tagagawa ng appliance ng host route para sa sarili nilang server, para lang maiwasan ito. Hindi ito ipinapalagay ng RouterOS, kaya kailangang ipahayag ng operator ang pagbubukod o iwasan ang default na ruta sa simula pa lang.

I-pin ang address ng server sa WAN

Idagdag ang pinakamakitid na posibleng ruta: isang /32 para sa pampublikong address ng server, na ang gateway ng ISP ang susunod na hop, sa interface na umaabot sa internet. Tinatalo ng /32 ang anumang default sa haba ng prefix, at ang mas mababang distansya ang nananalo kung mayroon nang ibang ruta para sa parehong prefix. Pagkatapos ay kumonekta muli at tiyakin na ang ruta ay aktibo, hindi lang naroroon sa listahan.

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

Kung ang gateway ng ISP ay natututuhan sa pamamagitan ng DHCP, gamitin ang address ng gateway na inilagay ng DHCP, o itali ang ruta sa interface kung sinusuportahan ng release. Ang hardcoded na gateway na nagbabago sa susunod na lease ay isang naantalang pagkabigo. Suriin ang address pagkatapos ng muling pagkonekta sa WAN, dahil doon lumilitaw ang lumang gateway at nagsisimulang bumagsak muli ang tunnel.

O pigilan ang tunnel na kunin ang default

Ang sangay na nangangailangan ng isang malayong LAN ay dapat panatilihing malayo ang PPTP profile sa default na ruta. Patayin ang opsyong iyon sa profile ng client at sa halip ay magdagdag ng partikular na ruta para sa malayong prefix sa pamamagitan ng interface ng tunnel. Nananatili ang ordinaryong trapiko sa WAN, pinapanatili ng sariling transport ng tunnel ang natural nitong landas, at nagiging mas madaling ipaliwanag ang routing table. Ito ang mas mahusay na disenyo para sa sangay na nangangailangan ng isang subnet, hindi para sa router na dapat maging labasan ng site.

Ang buong tunnel ay may sariling mga pangangailangan: policy routing para sa mga piling pinagmulan, plano para sa pabalik na trapiko, at desisyon tungkol sa mangyayari kapag bumagsak ang tunnel. Wala sa mga iyon ang nasosolusyunan ng host route, na pinapanatili lamang na buhay ang transport.

I-verify nang pa-layer, pagkatapos isara ang butas sa pamamahala

Subukan nang pa-layer: i-ping ang pampublikong address ng server bago kumonekta, i-ping ang malayong gateway pagkatapos kumonekta, pagkatapos ay i-ping ang isang host sa malayong LAN. Magdagdag ng masquerade sa interface ng tunnel kung kailangan ng mga host sa likod ng router na bumalik ang mga sagot sa pamamagitan nito.

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

Pagkatapos ay i-reboot ang router o pilitin ang muling pagkonekta sa WAN at ulitin ang tatlong ping, dahil ang rutang umiiral lamang sa tumatakbong configuration ay hindi magtatagal. Ang isa pang lugar kung saan ito nasisira ay ang configuration na iniluluwas sa backup file at ibinabalik mamaya, dahil maaaring nawawala ang ruta sa export kung idinagdag ito habang tumatakbo.

Panghuli, limitahan ang Winbox at web management sa mga kilalang source address bago ilathala ang anumang pagbabago sa VPN o ruta. Ang router na nagtatapos ng mga tunnel ay isang target ng pamamahala, at ang port 80 na bukas sa buong mundo ay mas malaking natuklasan kaysa sa rutang inayos mo lang.