MikroTik PPTP megszakad? Javítsa a szerverhez vezető útvonalat

Egy RouterOS PPTP-kliens csatlakozik, átvisz egy kis forgalmat, majd elhal, és a napló hitelesítő adatokra vagy szerverproblémára utal. Általában egyik sem. Az alagút a saját átviteli csomagjait szállítja, mert a szerverhez vezető útvonal egybeesik az alagút által telepített útvonallal is. A partner már nem hallja a routert, és a munkamenet meghal, miközben az interfész továbbra is azt állítja, hogy működik.

A megoldás egy útvonal vagy egy beállítás, amely a szervert a fizikai WAN-on át elérhetővé tartja. Melyik, attól függ, hogy a routernek teljes alagút átjárójának kell-e lennie.

A tünet: csatlakozik, forgalmat visz, meghal

A minta minden újracsatlakozásnál megismétlődik, és ez az első hasznos nyom. Az elutasított jelszó még az interfész feljövetele előtt elbukik, a tűzfal hibás beállítása általában egy irányt blokkol, az útválasztási hurok pedig engedi az interfészt létrejönni, majd megfojtja. Figyelje a számlálókat: az alagút a kezdeti csomagok robbanását mutatja, majd semmit, miközben a WAN interfész tovább küldi a beágyazott másolatokat. Ez egy router, amely a saját kimenetét önmagába eteti vissza.

A PPTP ezt könnyen kiváltja, mert az átvitel sima IP a szerver címére, nem olyan alagút, amelynek túlsó vége más alhálózaton van. Bármi, ami átirányítja ezt a címet, az átvitelt is átirányítja vele.

Miért nyeli le az alagút a saját csomagjait

Amikor a kliens csatlakozik, olyan útvonalat telepít, amelynek átjárója az alagút interfésze. Ha a profil alapértelmezett útvonalat is telepít, akkor minden célpont, amelyre nincs pontosabb egyezés, beleértve a szerver nyilvános címét is, az alagútba kerül. A router beágyazza a csomagot, a külső csomagot a szerverhez címezi, és újra megkeresi az útvonalat: ugyanaz a cél, ugyanaz az alapértelmezés, ugyanaz az alagút. A verziótól függően ezt a rekurziót eldobják, sorba teszik, vagy hurokba viszik, amíg a partner fel nem adja és meg nem szakítja a munkamenetet.

Az eszközgyártók gyakran automatikusan hozzáadnak egy host útvonalat a saját szerverükhöz, éppen ennek elkerülésére. A RouterOS ezt nem feltételezi, ezért az üzemeltetőnek ki kell fejeznie a kivételt, vagy eleve el kell kerülnie az alapértelmezett útvonalat.

Rögzítse a szerver címét a WAN-hoz

Adja hozzá a lehető legszűkebb útvonalat: egy /32-et a szerver nyilvános címéhez, a szolgáltató átjárójával következő ugrásként, azon az interfészen, amely eléri az internetet. A /32 előtaghossz alapján legyőzi bármelyik alapértelmezést, és kisebb távolság nyer, ha már létezik másik útvonal ugyanahhoz az előtaghoz. Ezután csatlakozzon újra, és erősítse meg, hogy az útvonal aktív, nem csak szerepel a listában.

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

Ha a szolgáltató átjárója DHCP-n keresztül tanulható, használja a DHCP által telepített átjárócímet, vagy kösse az útvonalat az interfészhez, ha a verzió támogatja. A következő bérletnél változó, keményen kódolt átjáró késleltetett hiba. Ellenőrizze a címet a WAN újracsatlakozása után, mert akkor bukkan fel egy elavult átjáró, és az alagút újra elkezd megszakadni.

Vagy akadályozza meg, hogy az alagút igénybe vegye az alapértelmezést

Egy fióktelepnek, amelynek egyetlen távoli LAN-ra van szüksége, teljesen távol kell tartania a PPTP-profilt az alapértelmezett útvonaltól. Kapcsolja ki ezt a beállítást az ügyfélprofilban, és helyette adjon hozzá konkrét útvonalat a távoli előtaghoz az alagút interfészén keresztül. A szokásos forgalom a WAN-on marad, az alagút saját átvitele megtartja természetes útját, és az útválasztási tábla könnyebben elmagyarázható. Ez a jobb tervezés az egy alhálózatot igénylő fióktelepnek, nem annak a routernek, amelynek a telephely kijáratának kell lennie.

A teljes alagútnak megvannak a maga követelményei: házirend-alapú útválasztás kiválasztott forrásokhoz, terv a visszatérő forgalomra, és döntés arról, mi történik, ha az alagút leesik. Ezek egyikét sem oldja meg a host útvonal, amely csak az átvitelt tartja életben.

Ellenőrizze rétegenként, majd zárja be a felügyeleti rést

Teszteljen rétegenként: pingelje a szerver nyilvános címét csatlakozás előtt, pingelje a távoli átjárót csatlakozás után, majd pingeljen egy gazdagépet a távoli LAN-on. Adjon hozzá masquerade-et az alagút interfészéhez, ha a router mögötti gazdagépeknek a válaszokat ezen keresztül kell visszakapniuk.

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

Ezután indítsa újra a routert, vagy kényszerítsen WAN-újracsatlakozást, és ismételje meg a három pinget, mert a csak a futó konfigurációban létező útvonal nem éli túl. A biztonsági másolat fájljába exportált, majd később visszaállított konfiguráció a másik hely, ahol ez eltörik, mivel az útvonal hiányozhat az exportból, ha futásidőben adták hozzá.

Végül korlátozza a Winboxot és a webes felügyeletet ismert forráscímekre, mielőtt bármilyen VPN- vagy útvonalváltozást közzétenne. Az alagutakat lezáró router felügyeleti célpont, és a világ felé nyitott 80-as port nagyobb lelet, mint az útvonal, amelyet épp most javított meg.