MikroTik PPTP katkeaa? Korjaa reitti palvelimelle

RouterOSin PPTP-asiakas yhdistää, siirtää hieman liikennettä ja kuolee sitten, ja loki näyttää tunnistetieto- tai palvelinongelmalta. Yleensä se ei ole kumpikaan. Tunneli kantaa omat kuljetuspakettinsa, koska reitti palvelimelle osuu myös reittiin, jonka tunneli asensi. Vastapuoli lakkaa kuulemasta reititintä, ja istunto kuolee, vaikka liitäntä väittää yhä olevansa ylhäällä.

Korjaus on yksi reitti tai yksi asetus, joka pitää palvelimen tavoitettavissa fyysisen WANin kautta. Kumpi, riippuu siitä, pitäisikö reitittimen olla täyden tunnelin yhdyskäytävä.

Oire: yhdistää, siirtää liikennettä, kuolee

Kuvio toistuu jokaisella uudelleenyhdistämisellä, ja se on ensimmäinen hyödyllinen vihje. Hylätty salasana epäonnistuu ennen kuin liitäntä nousee, palomuurin väärä kokoonpano estää yleensä yhden suunnan, ja reitityssilmukka päästää liitännän muodostumaan ja kuristaa sen sitten. Katso laskureita: tunneli näyttää purskeen alustavia paketteja ja sitten ei mitään, kun taas WAN-liitäntä lähettää edelleen kapseloituja kopioita. Se on reititin, joka syöttää oman lähtönsä takaisin itseensä.

PPTP tekee siitä helposti laukaistavan, koska kuljetus on pelkkää IP:tä palvelimen osoitteeseen, ei tunneli, jonka toinen pää on toisessa aliverkossa. Kaikki, mikä uudelleenohjaa tuon osoitteen, ohjaa mukanaan kuljetuksen.

Miksi tunneli nielee omat pakettinsa

Kun asiakas yhdistää, se asentaa reitin, jonka yhdyskäytävä on tunnelin liitäntä. Jos profiili asentaa myös oletusreitin, jokainen kohde ilman tarkempaa osumaa, mukaan lukien palvelimen julkinen osoite, ratkeaa tunnelille. Reititin kapseloi paketin, osoittaa ulomman paketin palvelimelle ja etsii reitin uudelleen: sama kohde, sama oletus, sama tunneli. Versiosta riippuen tämä rekursio pudotetaan, jonotetaan tai kierrätetään silmukassa, kunnes vastapuoli luovuttaa ja katkaisee istunnon.

Laitevalmistajat lisäävät usein automaattisesti isäntäreitin omalle palvelimelleen juuri tämän välttääkseen. RouterOS ei oleta sitä, joten operaattorin on ilmaistava poikkeus tai vältettävä oletusreittiä alusta asti.

Kiinnitä palvelimen osoite WANiin

Lisää kapein mahdollinen reitti: /32 palvelimen julkiselle osoitteelle, palveluntarjoajan yhdyskäytävä seuraavana hyppynä, liitännällä, joka yltää internetiin. /32 voittaa minkä tahansa oletusreitin etuliitteen pituudella, ja pienempi etäisyys voittaa, jos samalle etuliitteelle on jo toinen reitti. Yhdistä sitten uudelleen ja varmista, että reitti on aktiivinen eikä vain luettelossa.

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

Jos palveluntarjoajan yhdyskäytävä opitaan DHCP:llä, käytä yhdyskäytävän osoitetta, jonka DHCP asensi, tai sido reitti liitäntään, jos versio tukee sitä. Kovalta koodattu yhdyskäytävä, joka vaihtuu seuraavalla vuokrakaudella, on viivästynyt vika. Tarkista osoite WANin uudelleenyhdistämisen jälkeen, sillä silloin vanhentunut yhdyskäytävä tulee esiin ja tunneli alkaa taas pudota.

Tai estä tunnelia valtaamasta oletusreittiä

Haaraliikkeen, joka tarvitsee yhden etä-LANin, pitäisi pitää PPTP-profiili kokonaan poissa oletusreitiltä. Kytke tämä asetus pois asiakasprofiilista ja lisää sen sijaan tarkka reitti etäetuliitteelle tunnelin liitännän kautta. Tavallinen liikenne pysyy WANilla, tunnelin oma kuljetus säilyttää luonnollisen polkunsa ja reititystaulukko on helpompi selittää. Tämä on parempi suunnittelu haaralle, joka tarvitsee yhden aliverkon, ei reitittimelle, jonka on tarkoitus olla toimipisteen ulospääsy.

Täydellä tunnelilla on omat vaatimuksensa: käytäntöpohjainen reititys valituille lähteille, suunnitelma paluuliikenteelle ja päätös siitä, mitä tapahtuu, kun tunneli putoaa. Mitään näistä ei ratkaise isäntäreitti, joka pitää hengissä vain kuljetuksen.

Varmista kerroksittain ja sulje sitten hallintareikä

Testaa kerroksittain: pingaa palvelimen julkista osoitetta ennen yhdistämistä, pingaa etäyhdyskäytävää yhdistämisen jälkeen ja pingaa sitten isäntää etä-LANissa. Lisää masquerade tunnelin liitäntään, jos reitittimen takana olevat isännät tarvitsevat vastausten palaavan sen kautta.

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

Käynnistä sitten reititin uudelleen tai pakota WANin uudelleenyhdistäminen ja toista kolme pingiä, sillä reitti, joka on olemassa vain käynnissä olevassa kokoonpanossa, ei säily. Kokoonpano, joka viedään varmuuskopiotiedostoon ja palautetaan myöhemmin, on toinen paikka, jossa tämä hajoaa, koska reitti voi puuttua viennistä, jos se lisättiin ajon aikana.

Rajoita lopuksi Winbox ja verkkohallinta tunnettuihin lähdeosoitteisiin ennen minkään VPN- tai reittimuutoksen julkaisemista. Tunneleita päättävä reititin on hallintakohde, ja maailmalle avoin portti 80 on suurempi löydös kuin juuri korjaamasi reitti.