MikroTik PPTP katkeb? Parandage marsruut serverini

RouterOS-i PPTP-klient ühendub, edastab veidi liiklust ja sureb siis, ning logi näeb välja nagu volituste või serveri probleem. Tavaliselt pole kumbki. Tunnel kannab omaenda transpordipakette, sest marsruut serverini kattub ka marsruudiga, mille tunnel paigaldas. Vastaspool lakkab ruuterit kuulmast ja seanss sureb, samal ajal kui liides väidab endiselt, et on üleval.

Parandus on üks marsruut või üks seade, mis hoiab serveri füüsilise WAN-i kaudu kättesaadavana. Kumb, sõltub sellest, kas ruuter peaks olema täistunneli lüüs.

Sümptom: ühendub, edastab liiklust, sureb

Muster kordub igal taasühendusel ja see on esimene kasulik vihje. Tagasi lükatud parool ebaõnnestub enne, kui liides üles tuleb, tulemüüri vale seadistus blokeerib tavaliselt ühe suuna, ja marsruutimise silmus laseb liidesel kinnituda ning kägistab selle seejärel. Jälgige loendureid: tunnel näitab algpakettide purset ja siis mitte midagi, samal ajal kui WAN-liides saadab edasi kapseldatud koopiaid. See on ruuter, mis söödab oma väljundi iseendale tagasi.

PPTP muudab selle kergesti esilekutsutavaks, sest transport on lihtne IP serveri aadressile, mitte tunnel, mille kaugem ots asub teises alamvõrgus. Kõik, mis selle aadressi ümber suunab, suunab ümber ka transpordi.

Miks tunnel oma paketid alla neelab

Kui klient ühendub, paigaldab see marsruudi, mille lüüs on tunneli liides. Kui profiil paigaldab ka vaikimisi marsruudi, siis iga sihtkoht ilma täpsema vasteta, sealhulgas serveri avalik aadress, laheneb tunnelisse. Ruuter kapseldab paketi, adresseerib välise paketi serverile ja otsib marsruudi uuesti: sama sihtkoht, sama vaikimisi marsruut, sama tunnel. Sõltuvalt versioonist jäetakse see rekursioon vahele, pannakse järjekorda või aetakse silmusesse, kuni vastaspool annab alla ja seansi lõpetab.

Seadmetootjad lisavad sageli automaatselt hostmarsruudi oma serverile, just selle vältimiseks. RouterOS ei eelda seda, seega peab operaator erandi väljendama või vaikimisi marsruuti juba algusest vältima.

Kinnitage serveri aadress WAN-i

Lisage kitsaim võimalik marsruut: /32 serveri avaliku aadressi jaoks, teenusepakkuja lüüsiga järgmise hüppena, liidesel, mis jõuab internetti. /32 võidab igat vaikimisi marsruuti prefiksi pikkuse järgi ja väiksem kaugus võidab, kui sama prefiksi jaoks on juba teine marsruut olemas. Seejärel ühenduge uuesti ja kinnitage, et marsruut on aktiivne, mitte ainult loendis olemas.

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

Kui teenusepakkuja lüüs õpitakse DHCP kaudu, kasutage lüüsi aadressi, mille DHCP paigaldas, või siduge marsruut liidesega, kui versioon seda toetab. Kõvakodeeritud lüüs, mis järgmisel rendil muutub, on edasilükatud rike. Kontrollige aadressi pärast WAN-i taasühendust, sest siis ilmub aegunud lüüs ja tunnel hakkab jälle katkema.

Või takistage tunnelil vaikimisi marsruuti endale võtmast

Filiaal, millel on vaja üht kaugvõrku, peaks hoidma PPTP profiili vaikimisi marsruudist täiesti eemal. Lülitage see valik kliendiprofiilis välja ja lisage selle asemel konkreetne marsruut kaugprefiksile läbi tunneli liidese. Tavaline liiklus jääb WAN-i, tunneli oma transport säilitab loomuliku tee ja marsruutimistabelit on lihtsam selgitada. See on parem lahendus filiaalile, mis vajab üht alamvõrku, mitte ruuterile, mis peaks olema koha väljapääs.

Täistunnelil on omad nõuded: poliitikapõhine marsruutimine valitud allikatele, tagasiliikluse plaan ja otsus, mis juhtub, kui tunnel katkeb. Midagi sellest ei lahenda hostmarsruut, mis hoiab elus ainult transpordi.

Kontrollige kihtide kaupa ja sulgege siis haldusauk

Testige kihtide kaupa: pingige serveri avalikku aadressi enne ühendamist, pingige kauglüüsi pärast ühendamist, seejärel pingige hosti kaugvõrgus. Lisage masquerade tunneli liidesele, kui ruuteri taga olevad hostid vajavad vastuseid selle kaudu tagasi.

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

Seejärel taaskäivitage ruuter või sundige WAN-i taasühendust ja korrake kolme pingi, sest marsruut, mis eksisteerib ainult jooksvas konfiguratsioonis, ei jää püsima. Varundusfaili eksporditud ja hiljem taastatud konfiguratsioon on teine koht, kus see katki läheb, kuna marsruut võib ekspordist puududa, kui see lisati tööajal.

Lõpuks piirake Winbox ja veebihaldus tuntud lähteaadressidega enne mis tahes VPN-i või marsruudi muudatuse avaldamist. Tunnelid lõpetav ruuter on haldussihtmärk ja kogu maailmale avatud port 80 on suurem leid kui just parandatud marsruut.