SSTP VPN után IPSec Site-To-Site VPN-en keresztül route-olás - MikroTik

Hálózatok egyéb

Üdvözlet!

Van 2 db MikroTik hAPac3-as router, amelyek IPSec Site-To-Site VPN-en vannak összekötve. Mind a 2 router rendesen elérhető és a belső hálózatok is (https://forum.mikrotik.com/viewtopic.php?t=182923).

"A" router belső LAN: 192.168.1.0/26

"B" router belső LAN: 192.168.2.0/26

A "B" router-en be lett állítva az SSTP VPN Let's Encrypt tanúsítvánnyal. A 2 router publikus IP címmel rendelkezik. A "B" router-re be lehet SSTP-vel VPN-ezni. A 172.16.2.0-as hálózatból kap IP címet a be VPN-ező felhasználó. A 172.16.2.0-ból minden gond nélkül lehet ping-elni a 192.168.2.0-ás hálózatot ("B" router). A cél az lenne, hogy SSTP VPN-en keresztül el lehessen érni a 192.168.1.0-ás hálózatban ("A" router) található erőforrásokat (pl. nyomtató). Viszont SSTP VPN csatlakozás után nem lehet elérni a 192.168.1.0-ás hálózatot, a ping sem megy. Akkor se ha mind a 2 helyen ki van kapcsolva a tűzfal. Valszeg route hiba lesz.

Hogyan szükséges beállítani a route szabályokat a router-eken, hogy a SSTP VPN csatlakozás után el lehessen érni a 192.168.1.0-ás hálózatot? Ami az "A" router LAN része.

Köszönöm!

  • 517 megtekintés

( bennyh | 2023. 07. 18., k – 14:46 )

Biztos route hiba. Milyen kliens? Alapból Windows-ról bejelentkezve inkább az szokott a gond lenni, hogy az lesz az alapértelmezett átjáró és be kell lőni a split tunelling-et. 

Mikor él a VPN kapcsolat ha kézzel megadod parancssorban, hogy a VPN alagút túloldala az átjáró a másik hálózathoz, akkor se jó?

 

PS: jók azok a netmaskok?

( KicsiBocs | 2023. 07. 18., k – 15:02 )

Szerkesztve: 2023. 07. 18., k – 15:03

Basszus, jogos. Pedig 2x-er is átolvastam. 192.168.1.0/26 és 192.168.2.0./26

A kliens sima Windows-ba épített kliens.

Az A router biztosan tudja, hogy merre van a 172.16.2.0-es tartomány?

A B az látja a saját lábait, de az A már nem lát rá. Ha nincs valami routing protokoll vagy nincs jól beállítva vagy épp a statikus routing nincs jól beállítva, az is okozhat gondokat.

Traceroute is van a RouterOS-ben.

?

A Split tuneling egy nagyon jól hangzó történet, de ott van jelentősége, ahol a kliens több VPN-t használ, vagy csak bizonyos forgalmat akar a VPN-be routolni. Ettől függetlenül abban a hálózatban, ahova a kliens bécsatlakozott minden pontján tudni kell, hogy melyik hálózatot hol kell keresni, és ez sok esetben nem a default route-on lesz.

Végső soron a split tuneling egy jól hangzó név az igény szerint útválasztáshoz. :)

"Ettől függetlenül abban a hálózatban, ahova a kliens bécsatlakozott minden pontján tudni kell, hogy melyik hálózatot hol kell keresni, és ez sok esetben nem a default route-on lesz."

Erre tetsztett gondolni? Mert ez valszin maga a megoldás. Az OP-nek kell végignéznie a hálózatát, hogy hol melyik pontról mi látszik, erről többen írtak. Azt hogy a split tuneling épp itt hogy merült fel, az nem világos nekem, ezért próbáltam a mellékvágányról elterelni.

( Zs | 2023. 07. 20., cs – 08:51 )

Az IPSec konfig az SSTP VPN tartományát átviszi? Tehát az A oldali router tud arról, hogy a B router mögött nem csak a 192.168.2.0/26 érhető el, hanem most már a 172.16.2.0/24-et is?

A ping nem megy, az egy tünet. De jó lenne pontosan tudni, hogy hol/hogy nem megy? tcpdump a megfelelő interface-kre és lássuk: kimegy az icmp echo request? Túloldalon megérkezik? Válasz hol megy ki rá? Jó interface-n?

Itt lesz a gond. A sima IPsec a routing-on "kívül" működik, a policy-k mondják meg, hogy milyen src-dst IP tartományok közötti forgalmat tol bele a tunnel-be. Mindkét oldalon fel kell venni a megfelelő IPsec policy-t az SSTP VPN tartományra vonatkozólag is.

Pont az ilyen szopások elkerülése miatt használok inkább L2TP+IPsec-et, ami húz egy Layer2-t az IPsec tunnelbe, amin meg már azt és úgy route-olok, meg tűzfalazok, vagy akár OSPF-ezek, amit és ahogy akarok. - Tisztább, szárazabb, biztonságosabb érzés.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"