MikroTik PPTP pārtrūkst? Salabojiet maršrutu uz serveri

RouterOS PPTP klients pieslēdzas, pārvieto nedaudz trafika un pēc tam apklust, un žurnāls izskatās pēc akreditācijas datu vai servera problēmas. Parasti tas nav ne viens, ne otrs. Tunelis nes savas transporta paketes, jo maršruts uz serveri sakrīt arī ar maršrutu, ko tunelis instalēja. Otra puse pārstāj dzirdēt maršrutētāju, un sesija mirst, kamēr saskarne joprojām apgalvo, ka ir aktīva.

Labojums ir viens maršruts vai viens iestatījums, kas uztur serveri sasniedzamu caur fizisko WAN. Kurš no tiem, atkarīgs no tā, vai maršrutētājam jābūt pilna tuneļa vārtejai.

Simptoms: pieslēdzas, pārvieto trafiku, mirst

Modelis atkārtojas katrā atkārtotā pieslēgumā, un tas ir pirmā noderīgā norāde. Noraidīta parole neizdodas pirms saskarnes pacelšanās, nepareiza ugunsmūra konfigurācija parasti bloķē vienu virzienu, un maršrutēšanas cilpa ļauj saskarnei izveidoties un pēc tam to nožņaudz. Vērojiet skaitītājus: tunelis parāda sākotnējo pakešu uzliesmojumu un pēc tam neko, kamēr WAN saskarne turpina sūtīt iekapsulētas kopijas. Tas ir maršrutētājs, kas savu izvadi atkal padod sev pašam.

PPTP to padara viegli izraisāmu, jo transports ir vienkāršs IP uz servera adresi, nevis tunelis, kura tālais gals atrodas citā apakštīklā. Viss, kas novirza šo adresi, novirza arī transportu.

Kāpēc tunelis norij savas paketes

Kad klients pieslēdzas, tas instalē maršrutu, kura vārteja ir tuneļa saskarne. Ja profils instalē arī noklusējuma maršrutu, tad katrs galamērķis bez precīzākas atbilstības, tostarp servera publiskā adrese, tiek atrisināts uz tuneli. Maršrutētājs iekapsulē paketi, adresē ārējo paketi serverim un atkal meklē maršrutu: tas pats galamērķis, tas pats noklusējums, tas pats tunelis. Atkarībā no versijas šī rekursija tiek izmesta, ievietota rindā vai ievilkta cilpā, līdz otra puse padodas un pārtrauc sesiju.

Ierīču ražotāji bieži automātiski pievieno resursdatora maršrutu savam serverim, tieši lai no tā izvairītos. RouterOS to nepieņem, tāpēc operatoram ir jāizsaka izņēmums vai jāizvairās no noklusējuma maršruta jau no sākuma.

Piespraudiet servera adresi WAN

Pievienojiet šaurāko iespējamo maršrutu: /32 servera publiskajai adresei, ar pakalpojumu sniedzēja vārteju kā nākamo lēcienu, saskarnē, kas sasniedz internetu. /32 uzvar jebkuru noklusējumu pēc prefiksa garuma, un mazāks attālums uzvar, ja tam pašam prefiksam jau pastāv cits maršruts. Pēc tam pieslēdzieties atkārtoti un apstipriniet, ka maršruts ir aktīvs, nevis tikai sarakstā.

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

Ja pakalpojumu sniedzēja vārteja tiek apgūta ar DHCP, izmantojiet vārtejas adresi, ko instalēja DHCP, vai piesaistiet maršrutu saskarnei, ja versija to atbalsta. Cieti iekodēta vārteja, kas mainās nākamajā nomā, ir aizkavēta kļūme. Pārbaudiet adresi pēc WAN atkārtotas pieslēgšanās, jo tieši tad parādās novecojusi vārteja un tunelis atkal sāk trūkt.

Vai arī neļaujiet tunelim piesavināties noklusējumu

Filiālei, kurai nepieciešams viens attāls LAN, PPTP profils pilnībā jātur prom no noklusējuma maršruta. Izslēdziet šo opciju klienta profilā un tā vietā pievienojiet konkrētu maršrutu attālajam prefiksam caur tuneļa saskarni. Parastais trafiks paliek WAN, paša tuneļa transports saglabā dabisko ceļu, un maršrutēšanas tabulu kļūst vieglāk izskaidrot. Tas ir labāks risinājums filiālei, kurai vajag vienu apakštīklu, nevis maršrutētājam, kuram jābūt vietas izejai.

Pilnam tunelim ir savas prasības: politikas balstīta maršrutēšana atlasītiem avotiem, atgriezeniskā trafika plāns un lēmums par to, kas notiek, kad tunelis nokrīt. Nevienu no tiem neatrisina resursdatora maršruts, kas tikai uztur transportu dzīvu.

Pārbaudiet pa slāņiem, pēc tam aizveriet pārvaldības caurumu

Pārbaudiet pa slāņiem: pingojiet servera publisko adresi pirms pieslēgšanās, pingojiet attālo vārteju pēc pieslēgšanās, pēc tam pingojiet resursdatoru attālajā LAN. Pievienojiet masquerade tuneļa saskarnei, ja resursdatoriem aiz maršrutētāja atbildes jāsaņem atpakaļ caur to.

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

Pēc tam restartējiet maršrutētāju vai piespiediet WAN atkārtotu pieslēgšanos un atkārtojiet trīs pingus, jo maršruts, kas pastāv tikai darbojošā konfigurācijā, neizdzīvos. Konfigurācija, kas eksportēta uz dublējuma failu un vēlāk atjaunota, ir otra vieta, kur tas lūzt, jo maršruts var trūkt eksportā, ja tas tika pievienots izpildlaikā.

Visbeidzot, ierobežojiet Winbox un tīmekļa pārvaldību ar zināmām avota adresēm pirms jebkādu VPN vai maršruta izmaiņu publicēšanas. Maršrutētājs, kas izbeidz tuneļus, ir pārvaldības mērķis, un pasaulei atvērts ports 80 ir lielāks atradums nekā tikko salabotais maršruts.