MikroTik - VPN Client pro určité lokální IP

Podle toho, jakou VPN použiješ. Když použiješ policy based IPSec VPN (jako, že mikrotik, stejně jako cisco, router based neumí), tak můžeš do pravidel VPNky nastavit konkrétní IP adresu v tvojí vnitřní síti, aby její provoz smerem ke konkrétní vzdálené adrese (adresám) byl směrován do konkrétního tunelu. Nebo postavit všech VPN a firewallem do nich směrovat provoz. A nebo si tu VPN rozjet na těch počítačích.

Mohl bych trošku víc osvětlit, k čemu má ono řešení sloužit?

tak takovou divočinu jsem ještě neviděl. K čemu to má sloužit?

Jedná se o získání více veřejných adres pro přístup do internetu z lokálních strojů. Každý PC by měl vlastní veřejnou IP adresu. Případně serverové aplikace běžící na lokálních strojích, přístupné naopak každý na jiné IP z internetu.

Řešení s firewallem mě nenapadlo, ale jak o tom tak přemýšlím, nejspíš je to nejsnadnější řešení, navíc neomezené typem tunelu. Potom by stačilo v podstatě do jakéhokoliv tunelu (PPTP, OVPN či IPSec) přesměrovat veškerý provoz z určité IP v lokální síti. Jeví se to jako docela dobrý nápad, i když někdo by řekl, že je to trošku nabastlené

Nepletu se tedy, pokud předpokládám, že mi stačí připojit na routeru (jedno či Mikrotik, Cisco či jiný systém) požadovaný počet tunelů a do nich potom pomocí FORWARDů přesměrovávat provoz odcházející a směřující na konkrétní IP v lokální síti.

Mohli byste prosím jen tak orientačně nahodit, jak by takové pravidlo vypadalo? Jen pro představu.

Díky

promiň, ale tohle se přece řeší natem 1:1..

Máš pravdu, začal jsem vymýšlet kolo... Díky za nasměrování správným směrem. Určitě se ještě ozvu, protože v průběhu nastavování jistě něco nepoběží nebo nastane jiný problém. Zatím ještě jednou děkuji.

Tak jak jsem předpokládal, samozřejmě při realizaci nastaly očekávané problémy.

Mikrotik mi dělá domáci gateway jako PPPoE Client. Nastavena maškaráda a DHCP server.

Mimo to je Mikrotik připojený jako PPTP klient, který má lokální IP adresu 172.95.1.108, která je v současnosti dynamicky přidělovaná (testovací provoz), ale nemyslím si, že to by byl problém.

V lokální síti za maškarádou je počítač se statickou IP adresou 192.168.0.155 na jednom zařízení a 192.168.0.156 na druhém.

Na Mikrotiku mám přidány pravidla:

nat chain=dstnat dst-address=172.95.1.108 action=dst-nat to-addresses=192.168.0.155

nat chain=srcnat src-address=192.168.0.155 action=src-nat to-addresses=172.95.1.108

Snažím se docílit toho, aby po zobrazení externí IP z počítače 192.168.0.155, byla uváděna IP adresa PPTP serveru (je na něm nastaven ip forward a maškaráda), stejně jako když se připojím jako klient z Windows.

Nemohu toho však tímto dosáhnout, stále se zobrazuje externí adresa, kterou mám přidělenou mým providerem.

Díky za případnou pomoc

A ty ostatní adresy jsou také přidělované providerem? Pokud je chcete NATovat, tak musí "fyzicky" být na nějakém rozhraní toho mikrotiku. Jak by jinak věděla vnější síť, kam ten který provoz narvat? Jo, a co se source NATu týče, tak Masquerade by mělo být jako poslední pravidlo, aby fungovala ta ostatní.

Ostatní IP ve vnitřní síti mi přiděluje DHCP server, který běží na gateway. Mám PPPoE klienta, který má přidělenou adresu providerem (88.103.200.44). Všechny adresy ve vnitřní síti jsou za maškarádou a externí adresu mají tedy tuto (88.103.200.44).

Říkáte tedy, že aby mi to běželo, tak dst a src -naty musí být před tou maškarádou?

Dobře, tím se vyřešil problém ze včera, tedy že se nešlo připojit do internetu na jakémkoliv počítači v síti.
Když jsem ty dst a src pravidla dal před maškarádu, na všech pc v síti to běží, ale na 192.168.0.155 se teď nedostanu už nikam dál než na gateway.

// Ještě bych doplnil, aby bylo úplně jasno. Běží to na ADSL lince. Modem je v Bridge a do jednoho portu Mikrotiku je veden jeden kabel od modemu. Druhý kabel vede do switche do vnitřní sítě.

172.95.1.108 a tahle veřejná adresa se jako vezme kde? Jak routry v internetu vědí, kam ji mají posílat?

To je IP adresa PPTP klienta, který je připojený z Mikrotiku k PPTP serveru, který provoz z klienta posílá do a z internetu.. Pro testy jsem použil vpnbook, ale v budoucnu to bude VPN server se statickou IP nainstalovaný na VPS.

A druhy protikus toho PPTP pripojeni je co?

Mam totiz pocit, ze to, ceho se snazis dosahnout bude (ne ze by to neslo) dost tvrdy sitarsky orisek. V tom puvodnim dotazu totiz zrejme chybely nektere informace.

V tom routru existuje routovaci tabulka, a ta ma vychozi branu a ta rozhodne neni smerem tech PPtP tunelu. Tim smerem samozrejme proudi veskera data ktera nemaji "lokalni zaznam", tedy i provoz, ktery se pokousis smerovat pres tyhle verejne IP adresy.

Mohl by si sem dat nejakou maluvku, jak to mas vlastne zapojene (vcetne tech PPtP - a kam vlastne vedou), vypis z konfigurace mikrotiku (promazat hesla a klice, bacha na to) nebo tak?

Myslím, že celá ta situace je složitější ještě o to, že jsem se to snažil směrovat přes veřejnou VPN, kam se připojuje tisíce uživatelů a má více rozsahů adres. Objednal jsem vlastní VPS, až přijde root, nakonfiguruju ho jako PPTP server a pak přidám kompletní informace včetně reálných IP adres a nákresu.

Moc díky za zájem. Do večera to sem hodím.

A nebylo by jednodušší změnit poskytovatele, který by ti ty veřejné adresy prostě dal, než to tahat někde přes hosting (s buhvíjakým výpočetním výkonem)? Nebo ty služby naopak vyvést na hosting? Ono ADSL nedisponuje zrovna oslnivou rychlostí na uploadu na to, aby se na něj daly věšet nějaké veřejné služby.

Žádný poskytovatel mi nedá větší rozsah IP adres, některé VPS hostingy právě ano. Jak už jsem psal, tohle je testovací provoz. Hodlám to potom celé pověsit na nějakou rychlejší linku.

Já mam od svého poskytovatele 8 adres k dispozici (routovaně - tedy můj router má v síti neveřejnou adresu, ale nadřazený router - poskytovatele - směruje mým tento rozsah, jehož využití je čistě na mě) na symetrické 10Mb lince.

Jenom dotaz, co na těch veřejných adresách bude běžet, že musí mít každý sever svojí separátní IP adresu?

Experimentuji se službami, které vyžadují přístup z různých IP adres. 8 je málo, plánuji 128-192 adres. Je mi jasné, že ADSL není pro toto vhodné, ale chci to na něm zprovoznit a pak už by neměl být problém přenést nastavení na rychlou linku.

Výpis z MK je zde
Bqeccvra

Nákres zde
ip8jkyaa.png

Opravdu moc děkuji

z ruznych adres se da pristupovat na sluzby i na jedne verejne adrese. Cely Ccko je docela drahy, pri takovem mnozstvi verejnych adres je jednoducha odpoved. Server primo v housingu.

Pokud to hodláš mít takhle enormní, a zarytě propojené běžným internetem kamsi na hosting, takto bych postupoval já:

Domluvit se s poskytovatelem hostingu o přidělení celého veřejného rozsahu s maskou 24 s tím, že IP adresy nebudou součástí jeho sítě, ale budou schované za tvým routrem. Jak jsem to popisoval výše, tedy poskytovatel přesměruje veškerý rozsah přes tvuj router. V routovací tabulce u providera by to mohlo vypadat třeba takto (IP adresa 1.2.3.4 je adresa tvého routru v poskytelovatelově síti):
route add 1.2.4.0 netmask 255.255.255.0 1.2.3.4 (píšu to v syntaxi windows, nepředpokládám ovšem, že provider používá router windows)

Ty na hostingu buď budeš mít virtuální router nebo vlastní v housingu (Router-hosting).

Z tohoto routru vytvoříš JEDEN VPN tunel do routru, který bude předřazen té farmě serverů(Router-doma).
Router-doma nebude mít v routovací tabulce výchozí bránu směrem ke svému poskytovateli. Směrem k poskytovateli bude směrováná pouze a jenom adresa 1.2.3.4 (jako koncový bod VPN). Výchozí brána bude směrem do vytvořeného VPN tunelu (tím odpadne nutnost vytvářet pro provoz serveru na routru-doma samostatnou routovací tabulku.

Vnitřní adresy serverů (a vnitřní rozhraní routeru-doma) mohou být klíďo píďo rovnou veřejné (z přiděleného rozsahu). Samozřejmě, že mohou být také překládané. Na routru-doma pak vytvoříš na firewallu security pravidla.

Jestli se ti to zdá složité nebo přitažené za vlasy, tak není. Je to nejjednodušší řešení v podmínkách, které si tu nastínil (touchwood doufám potvrdí). Přitažený za vlasy je totiž celý koncept.

Fakticky pro aplikace, které využívají tak velké množství veřejných adres je blbost mít doma. Na takovém množství veřejných adres fungují třeba malí poskytovatelé a ještě jim zbývá. Spíš bych přehodnotil celý koncept.

Tak ono je to skutečně trochu překombinované to mít doma, ale cenově to vychází podstatně nejlevněji. Na 3 serverech mi doma běží momentálně 144 virtuálů, u nich platím jen elektřinu a linku, kterou v budoucnu plánuji vyměnit. To je cenově úplně jinde, než je mít v housing centru. (virtuály proto, že mi přijde jednodušší je spravovat - samozřejmě to někomu může připadat přitažené za vlasy)

Na iwstacku můžu mít 128 ip adres za 126 euro společně dvěma servery a virtuálním routerem, které budou obstarávat tunelový provoz. To je dohromady s elektřinou a linkou cca 5-6k.

Pokud jde takhle levně získat místo v housingu i s podobným rozsahem adres, bylo by to samozřejmě velice pohodlné a nejlepší řešení. Pokud jsem však dobře zkoumal nabídku tuzemských a především Pražských center, ceny jsou úplně někde jinde..

Upozorňuji, že se nejedná o žádné profi nasazení, ale spíše o experimenty pro vlastní využití.

// Tvůj příspěvek mě ponouknul znovu prozkoumat trh a možná, že máš skutečně pravdu. Například na superhostingu by se dalo podobné řešení sehnat za cca 4k. Zajímavé.. Rozhodně to teď musím lépe promyslet..

Urcite nerob nic take doma, okrem pripadnych problemov s elektrickou energiou musis zalohovat internetove pripojenie, proste garantovat istu stabilitu, co doma nemas sancu spravit. Taketo nieco ti poskytne len profi hosting (zalozna linka, diesel generator a pod).
Predpokladam, ze pri sluzbach, kde mesacne vrazas niekolko tisic sa nejedna o studentsky experiment, ale o nieco komercne, takze by to malo mat istu uroven.

Predpokladam, ze pri sluzbach, kde mesacne vrazas niekolko tisic sa nejedna o studentsky experiment

No, já mám také doma profi síť, do které investuju svoje peníze.. Ale nevydělává nic, provozuju to pro sebe (jako koníčka) a částečně pro skauty, takže čistě nekomerční. Také vždy hledám nejvýhodnější řešení.

Teď se mi hooodně moc líbí nové serverové atomy od Intelu. Myslím, že už mám rozhodnuto o podobě svých příštích serverů. 8core na 2,4GHz se spotřebou 20W, to je sen . K tomu navíc čtyři integrované 1Gbps síťovky, 6SATA konektorů a 8xPCIx.

http://www.supermicro.com/products/motherboard/Ato m/X10/A1SAi-2750F.cfm

144 virtualov urcite nebude konicek, bud uchylka, alebo zle spraveny projekt;o).
Ja sa nerad hram na serverove vs neserverove riesenia, Atom tam nema co hladat a nehovoriac o tom, ze doteraz som vzdy riesil len zavady znackove hw, kdezto neznackove home made servre mi vsetky bezia bez zavad (najstarsi uz vyse 10 rokov).

Intel tuhle řadu vede jako serverovou (pro mikro servery)
U téhle řady udělali jednu podstatnou změnu. Tyhle atomy umí spracovávat instrukce mimo pořadí (out-of-order), čímž stoupnul výkon na jádro prý až 2x až 3x. Sice za tuhle změnu zaplatil ztrátou hyper-thredingu, ale to při tomhle počtu jader tolik nevadí.

Recenze je tu:
https://ispforum.cz/viewtopic.php?f=62&t=13147&sid =ab0c899a9603e2ba2595acecce5b105e

O segmentu, kam tahle deska (CPU) patří ostatně hovoří i cena. Stojí 10000,- Intel ten procesor pozicuje proti rozmáhajícím se vícejádrovým ARM, což se mu, alespoň v oblasti mikroserverů (na mobilní zařízení to fakt není), myslím povedlo. Takový výkon s 20W příkonem? To nikde jinde fakt není.

144 virtualu? Jeste pořád tady nepadlo, co to je sakra za hroznou obludu. Mě běží doma virtuálů něco přes 10 (jeden host, iSCSI storage) a všechny jsou k něčemu (DNS/DHCP, fileserver, terminalovy server, mailserver, webserver, VPN koncentrator, WiFi manager, backup server, OpenTTD server, Minecraft server). Když experimentuju, tak běží maximálně dva na víc. Využívám 2, slovy dvě veřejné adresy a to jen proto, že klientská VPNka využívá také port 443 (jako https), ale nedá se protáhnout přes reverzní proxy, jelikož to není HTTP provoz).

No, "jen elektřina a linka". Jenže ta elekřina, pokud nemáš vlastní elektrárnu není zase málo. To beru hodně rezervních 100W na server (ve skutečnosti to bude víc) to je 300Wh /hodinu to je za 30 dní 216kWh a při ceně 4.8 za kWh přes tisícovku měsíčně.

K tomu si přiber věci jako stabilní nízká teplota a bezprašné prostředí v housingu. Nedodržením těchto podmínek totiž snižuje životnost serveru, čímž se zase domácí nasazení o něco prodraží. V housingu se, narozdíl od tebe doma, nedívají na skutečný příkon serveru (to co ti točí elektroměrem), ale pouze na štítkový příkon zdroje (přeloženo maximální příkon zdroje), takže tam můžeš narvat hyperžravou mrchu (jednu), která by tě doma sežrala, ale která v klidu uhostuje všechny tvoje desítky virtuálů.

Samozřejmě dávám jen argumenty na zvážení, abys měl co nejvíc informací k rozhodování.

Omlouvám se za prodlevu, přes svátky jsem to nechtěl řešit.

Jedná se mi traffic exchange, konkrétně HitLeap. Můj projekt je v začátku a aplikace vyvíjená HitLeapem běží pouze pod windows. Do ověření funkčnosti se mi samozřejmě nechce pořizovat x licencí windows, takže používám nelicencované, navíc upravené (win7mini). Nepotřebuji, aby mi někdo v datacentru šťoural, co používám za systémy, případně nějaké popotahování s licencemi. Jak říkám, jedná se zatím o zkušební provoz. V budoucnu je určitě lepší pro ostré nasazení investovat do licencí a umístit stroje do centra, to je ovšem jiná pohádka.

Proto tedy i 144 virutálů, zbyly mi z minulého nakonec nefunkčního pokusu, využívajícího také unikátní ip adresy. Na každém běží jen jedna aplikace, přijde mi to elegantnější a robusnější řešení (i když stále nabastelné), než používat sandbox a více tunelů a ip ještě pro windows systémy.

Tak, teď, když víte o co mi jde, snad bude snazší nalézt řešení

Začněme pro začátek třeba s 16 počítači v mé lokální síti, je jedno jestli virtuálními nebo fyzickými. Ty mají adresy 192.168.0.100-192.168.0.115.

K nim máme 16 vzdálených počítačů s veřejnými ip adresami, na každém z nich běží pptp server, který je dostupný na jejich veřejné adrese. Přiřaďme jim třeba 89.88.87.1-89.88.87.16.

Jak pomocí routeru (jedno jestli to bude na mikrotiku nebo jiném linuxovém systému), směrovat provoz z tunelů a do tunelů, na a z pc v lokální síti. Tak aby pc 192.168.0.100 vystupoval do internetu pod ip 89.88.87.1, 192.168.0.101 pod adresou 89.88.87.2 atd. atd.

Jde o to, aby po zapnutí lokálních strojů nebylo nic třeba nastavovat a rovnou se do internetu dostávali přes tyto veřejné nesdílené ip. Pokud by to bylo možné, zároveň bych na ně chtěl přistupovat pomocí vnc nebo rdp z lokální sítě, ale nutností to není.

Doufám, že jsem to zase nepopsal moc zamotaně a jde to pochopit.

Stále platí to o NAT 1:1. Pokud potřebuješ tunelovat, je vhodnější (režie, spolehlivost, efektivita) tunel jeden a v něm ten NAT.

Už jsem se o to pokoušel, ale nejde mi to zprovoznit. Provoz se tam prostě nesměruje, počítač ve vnitřní síti se po nastavení pravidel pro 1:1 vůbec nedostane na internet. Jde 1:1 použít pro směrování tunelem? Jako out a in interface potom použiju interface tunelu, ne? A src a dst adresu potom adresu, kterou dostanu jako pptp klient nebo adresu, na které server běží?

samořejmě že jde vše. Co používáš? Z hlediska iptables je nejlepší použít netmap:

http://capcorne.wordpress.com/2009/03/24/natting-a -network-range-with-netmapiptables/

Počítač, který má v mé vnitřní síti ip 192.168.0.111.

Na mikrotiku mám vytvořený nyní už L2TP tunel na server s adresou 89.88.87.1, který vytvořil na mém mikrotiku interface L2TP_CLIENT1 a to má adresu 192.168.10.10 a je v síti 192.168.10.1.

Používám tyhle pravidla na Mikrotiku

add chain=srcnat out-interface=L2TP_CLIENT1 src-address=192.168.0.111 action=src-nat to-address=192.168.10.1
add chain=dstnat in-interface=L2TP_CLIENT1 dst-address=192.168.10.1 action=dst-nat to-address=192.168.0.111

Je to tak správně nebo mám u srcnat použít to-address 192.168.10.10 a u dstnat dst-address 192.168.10.10?

V nejhorším nasadím ještě čistě linuxový router s iptables třeba na debianu, ale rád bych to dělal zatím na Mikrotiku, pokud by to šlo.

Zatím to berme tak, že budu překlápět jednu veřejnou adresu z jednoho tunelu na jednu adresu ve vnitřní síti.

Pro překlápění celého rozsahu musím mít domluvený rozsah s providerem, což zatím nemám.

Už vážně nevím. Na tom serveru s veřejnou ip adresou 89.88.87.1 je zapnutí forwarding a je tam nastavená maškaráda. Když se na něj vytvořím tunel z windows, veškerý trafik jde skutečně tunelem a vystupuju pod ip serveru tedy 89.88.87.1. Ale s těmi pravidly co mám nastaveny na mikrotiku mi to prostě nejede. Trafik pořád jede přes providera přímo do internetu.

no ale iptables jsou jedna věc, druhá věc je routovací tabulka..

Jak říkám, pokud se připojím z windows klienta, provoz se směruje, takže na serveru by problém být neměl. Řekl bych, že bude problém v tom, že systém na počítači 192.168.0.111 má nastavenou gateway na 192.168.0.2, což je mikrotik. Měla by být automaticky nastavována na 192.168.10.1, pokud se nepletu? Jak toho docílit?

Už fakt netuším, strávil jsem na tom několik hodin pročítáním všelijakých manuálů a examplů, ale nikam jsem se nehnul.
Konfigurace:
winbox.jpg
Nejede... z 192.168.0.111 ping max na 192.168.0.2,192.168.10.10,192.168.10.1. Nikam dál, ani na veřejnou adresu toho vpn serveru. Zajímavé je, že občas nepingnu ani 192.168.0.2 nebo 192.168.10.10 nebo 192.168.10.1 a časy dosahují mnohdy přes 100ms, jako kdyby to šlo někudy venkem. Všechny okolní lokální pc v pohodě pingnu, jen router a tunel občas nejde..

Jak říkám, pokud se připojím z windows klienta, provoz se směruje, takže na serveru by problém být neměl. Řekl bych, že bude problém v tom, že systém na počítači 192.168.0.111 má nastavenou gateway na 192.168.0.2, což je mikrotik. Měla by být automaticky nastavována na 192.168.10.1, pokud se nepletu? Jak toho docílit?

1. nastavením routovací tabulky
2. pomocí policy based routingu

ani jedno na tomto obrázku nevidím:

edit: a už vůbec nehovořím o tom, že jsi "opomněl" přiložit routovací tabulku toho VPN boxu. Zapomínáš, že defaultní routy, tak jak ti je sestaví systém pro místní subnety a výchozí bránu naprosto nestačí!

Na takove čachry je už potřeba hlubší vhled do síťařiny. Chápat souvislosti, znát možnosti, vědět, jak věci pracují. Nejjednodušší řešení je mnou nastíněný scénář (jeden tunel a v něm provoz všech těch veřejných adres), ale obávám se, že bez hlubšího pochopení, jak to vlastně pracuje, je na nic.

ale i s tím tunelem, pokud chce používat i běžné internetové připojení, bude muset to routování řešit. Leda by přesměroval do tunelu úplně vše...

Však to také v té mé odpovědí naznačuju - routa mimo tunel je jen na IP druhého VPN konce a defaultní routa je do tunelu.

edit: a už vůbec nehovořím o tom, že jsi "opomněl" přiložit routovací tabulku toho VPN boxu. Zapomínáš, že defaultní routy, tak jak ti je sestaví systém pro místní subnety a výchozí bránu naprosto nestačí!

default via 46.xx.yy.1 dev eth0
46.xx.yy.0/24 dev eth0 proto kernel scope link src 46.xx.yy.99
192.168.10.10 dev ppp0 proto kernel scope link src 192.168.10.1

IP tables
:PREROUTING ACCEPT [47:4105]
:INPUT ACCEPT [15:1879]
:OUTPUT ACCEPT [12:739]
:POSTROUTING ACCEPT [12:739]
-A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE
COMMIT

Se současným nastavením to chápu tak, že se provoz z 192.168.0.111 na mém mikrotiku 192.168.0.2 překlopí pomocí src-nat na 192.168.10.10. V routovací tabulce je pro tuto adresu natavena jako gateway L2TP tunel. Po průchodu tunelem se kvůli maškarádě na vpn boxu překlopí na 192.168.10.1 a díky routě projde přes 46.xx.yy.99, potažmo přes 46.xx.yy.1 ven do internetu. Pro provoz který přijde zpět na 46.xx.yy.99 je to opačné. Mýlím se snad? Nejspíše ano, ale netuším ve které části.

Samozřejmě bych se rád dostal do hlubšího náhledu na věc, bohužel však z manuálů nic moc nevyčtu. Čím tedy začít? Nějaká hodnotná literatura?

zase jsi zkysnul u firewallu, ale problém máš v routingu.

http://pc.poradna.net/a/view/308346-jak-diagnostik ujeme-a-resime-problemy-se-sitovymi-pripojenimi-di l-ii-routing-smerovani

Rád bych tu routovací tabulku viděl, a to na obou koncích. podle mě tvá teorie neodpovídá realitě, protože se maškaráduje úplně někde jinde, než si myslíš. ideální bude když to namaluješ a vyznačíš natování, protože pak většinou zjistíš, kde máš problém.

Směrovací tabulka toho boxu je

Adresát         Brána           Maska           Přízn Metrik Odkaz  Užt Rozhraní
default         1-37.xxxxxx.net 0.0.0.0         UG    0      0        0 eth0
localnet        *               255.255.255.0   U     0      0        0 eth0
192.168.10.10   *               255.255.255.255 UH    0      0        0 ppp0

a na mikrotiku je to

Adresát         Brána           Maska           Přízn Metrik Odkaz  Užt Rozhraní
 0 ADS  0.0.0.0/0                          88.xxx.yyy.44             1
 1 ADC  88.xxx.yyy.44/32   85.xx.y.155     ADSL                      0
 2 ADC  192.168.0.0/24     192.168.0.2     LAN_PORTS                 0
 3 ADC  192.168.10.1/32    192.168.10.10   L2TP_xxxxxxxxx.net        0

// edit: Je to trochu změť, ale při vložení příspěvku to vymaže to mezery..

musíš to dát do "code" (touchwood)

no vidíš.

1. Box nemá vůbec routu pro síť 192.168.10.0/24
2. Mikrotik má jen routu pro desítkovou síť, ale zbytek routuje rovnou do inetu (tj. chybí ti buď policy routing, nebo selektivní routa nebo default routa do VPN)

Selektivní routu mohu vytvořit pomocí mangle pravidla a mark routingu?

A na boxu mám nastavit gw pro 192.168.10.0/24 na 1-37.xxxxx.net, že?

// edit: na boxu jsem tedy vytvořil routu pro desítkový subnet

Adresát         Brána           Maska           Přízn Metrik Odkaz  Užt Rozhraní
default         1-37.xxxxx.net  0.0.0.0         UG    0      0        0 eth0
localnet        *               255.255.255.0   U     0      0        0 eth0
192.168.10.0    *               255.255.255.0   U     0      0        0 ppp1
192.168.10.10   *               255.255.255.255 UH    0      0        0 ppp1

ad PBR:
Policy_Base_Routing

ad routing: to záleží, jak chceš, aby co kam šlo. Aktuálně (tak jak to máš nastaveno) bude fungovat pouze směr MTik -> 192.168.10.0/24 a ještě blbě, protože to máš blbě nastavené na druhé straně (tam musíš nasměrovat obě sítě 192.168.10.0/24 a 192.168.1.0/24 do tunelu. Pokud to nechceš řešit dál, budeš muset na serveru v internetu použít obousměrný NAT 1:1

Už jsem v tom úplně ztracený. Když čtu ten návod na wiki - nestačilo by tedy jen směrovat pomocí PBR všechen trafik do tunelu? Tak jako to dělají v tom návodu, jen s tím rozdílem, že nebudu posílat jen pakety obsahující něco, ale všechny, které mají zdrojovou adresu 192.168.0.111? Potom by stačila na tom boxu obyč. maškaráda, ne?

// edit: všechen trafik z 192.168.0.111 jsem měl na mysli. Z ostatních klientů by šel normálně defaultní routou směrem k poskytovateli.

jasně, nasměrovat si můžeš cokoli. (přiznám se, že jsem se už ztratil, co vlastně chceš dosáhnout)

Asi bude lepší to zkusit tedy popsat ještě jednou. Zkusím to i lépe nakreslit. Kašlu na L2TP a udělám to jednoduše přes PPTP.
Takhle je to teď

A takhle to chci

Začínám s nastavením na prvním obrázku.
Routovací tabulka v mikrotiku

 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
0 ADS  dst-address=0.0.0.0/0 gateway=88.xxx.yyy.44 gateway-status=88.xxx.yyy.44 reachable via  ADSL distance=1 scope=30 target-scope=10 
1 ADC  dst-address=88.xxx.yyy.44/32 pref-src=85.xx.y.155 gateway=ADSL gateway-status=ADSL reachable distance=0 scope=10 
2 ADC  dst-address=192.168.0.0/24 pref-src=192.168.0.2 gateway=LAN_PORTS gateway-status=LAN_PORTS reachable distance=0 scope=10 

NAT

0   chain=srcnat action=masquerade src-address=192.168.0.0/24

================================================== ==============

Tak a teď jak docílit druhého obrázku. Tedy aby všechen trafik z client1 putovat přes VPS, tedy přes PPtP tunel.

Pomocí PBR mě napadá jednoduché řešení a to tedy:
Vytvořím klienta PPtP

5  X  name="PPTP_plsikover.hukot.net" type="pptp-out" 

Addresses

 0   address=192.168.0.2/24 network=192.168.0.0 interface=LAN_PORTS actual-interface=LAN_PORTS 
 1 D address=85.xx.y.155/32 network=88.103.200.44 interface=ADSL actual-interface=ADSL 
 2 D address=10.0.99.10/32 network=46.xx.yy.99 interface=PPTP_xxxx.yyyy.net actual-interface=PPTP_xxxx.yyyy.net

Vytvořím mangle pravidlo na mikrotiku takto

 0   chain=prerouting action=mark-routing new-routing-mark=VPN_Tunnel passthrough=yes src-address=192.168.0.111

Přidám statickou routu takto

0   S  dst-address=0.0.0.0/0 gateway=PPTP_xxxx.yyyy.net gateway-status=PPTP_xxxx.yyyy.net reachable distance=1 scope=30 target-scope=10 routing-mark=VPN_Tunnel 
1 ADS  dst-address=0.0.0.0/0 gateway=88.xxx.yyy.44 gateway-status=88.xxx.yyy.44 reachable via  ADSL distance=1 scope=30 target-scope=10 
2 ADC  dst-address=88.xxx.yyy.44/32 pref-src=85.xx.y.155 gateway=ADSL gateway-status=ADSL reachable distance=0 scope=10 
3 ADC  dst-address=192.168.0.0/24 pref-src=192.168.0.2 gateway=LAN_PORTS gateway-status=LAN_PORTS reachable distance=0 scope=10

Tohle samo o sobě by mi dle mého mělo routovat veškerý trafik ze 192.168.0.111 do tunelu.

Na druhé straně (tedy na VPS, potažmo PPtP serveru) nastavím maškarádu a ipv4.forward. Mělo by to jet. Nebo je tam potřeba přidávat také statická routa?
Aktuální routovací tabulka na VPS

Adresát         Brána           Maska           Přízn Metrik Odkaz  Užt Rozhraní
default         1-37.xxxxx.net  0.0.0.0         UG    0      0        0 eth0
10.0.99.10      *               255.255.255.255 UH    0      0        0 ppp0
localnet        *               255.255.255.0   U     0      0        0 eth0

iptables

-A POSTROUTING -o eth0 -j MASQUERADE

=================================================

Tak, snad jsem teď poskytnul dostatek informací, abychom to dotáhli do nějakého konce

pokud jsem dobře četl ten mikrotik, tak ano, MTik máš IMHO správně.

Ale! Ve VPS stále nevidím správnou routovací tabulku, síť 10.0.99.0/24 má routu pouze pro hosta (UH), nikoli pro síť (UG), takže bys tam měl mít i něco jako

ip route add 192.168.0.0/24 dev ppp0
ip route add 10.0.99.0/24 dev ppp0

Musíš si představit, že jsi paket co dorazil na VPS z inetu. NAT jej zprocesuje, ale kam jej router v jádře pošle dál, když NAT říká, že jej má odeslat na IP 192.168.0.111?

Nic jiného jsem neměnil, jen jsem přidal routy do tabulky na VPS:

í
default         1-37.xxxxx.net  0.0.0.0         UG    0      0        0 eth0
10.0.99.0       *               255.255.255.0   U     0      0        0 ppp0
10.0.99.10      *               255.255.255.255 UH    0      0        0 ppp0
localnet        *               255.255.255.0   U     0      0        0 eth0
192.168.0.0     *               255.255.255.0   U     0      0        0 ppp0

Stejně to nejede, když pingnu třeba na na 46.xx.yy.99, tak je vidět, že někam ven jde trafik (na grafu rozhraní PPTP v mikrotiku), ale nic se nevrací. Stejně tak, když pingnu třeba google. Směrem tam to projde, ale nic se nevrátí. Přitom bych řekl, že ty routy už jsou teď správně.

Jinak díky za správné navedení, přesně něco takového bych potřeboval. Nějakou literaturu, kde to takhle polopaticky vysvětlujou: kdy se změní adresát na jakého, kdy se paket koho ptá kam se má odeslat atd. atd. Prostě celá cesta sítí, ale polopaticky.

ping je ti úplně k ničemu, potřebuješ tracert.. tam bude vidět kudy to jde a kde se to zastaví.

zkus wireshark, vyborny nastroj, lecos ti prozradi.. v prikazove radce pro linux existuje i tshark, ale i stary dobry TCPDUMP

Jenom takovy napad. Je vubec PPtP VPN schopna prenaset libovolne pakety libovolnych siti? Neni to neco jako policy based VPN u IPSecu, kde je presne definovane, jaky provoz muze tou VPN prochazet?

traceroute 46.xx.yy.99 skončí u 192.168.0.2, dál je request timed out.
traceroute 10.0.99.10 neprojde vůbec 192.168.0.2 a skončí na druhém řádku 10.0.99.10

Tracing route to 10.0.99.10 over a maximum of 30 hops

  1     *     30 ms     *     10.0.99.10
  2    96 ms  68 ms    50 ms  10.0.99.10

Trace complete.

Wireshark zkusím, uvidím, co vyhodí.

//edit: tracert posílám z 192.168.0.111

Další zájímavá věc je, že nepingnu ani z VPS na 10.0.99.10, takže už tomu vůbec nerozumím. Přeci, když je klient připojený a má IP 10.0.99.10, tak na něj musím z boxu pingnout.

Tak wireshark na mtiku na eth0: když pingnu 46.xx.yy.99, pakety se src 192.168.0.111 jdou jen tam, reply žádná.

Nikoho už nic nenapadá? Už jsem na tom strávil tolik času, že by mě dost otrávilo, kdybych to stejně nerozchodil

Jenom takovy napad. Je vubec PPtP VPN schopna prenaset libovolne pakety libovolnych siti? Neni to neco jako policy based VPN u IPSecu, kde je presne definovane, jaky provoz muze tou VPN prochazet?

Tak mohl bych to tam protlačit přes L2TP, jen si nejsem jist, jestli to není víc problémů než užitku.

já bych šel ověřenou cestou OpenVPN. http://wiki.mikrotik.com/wiki/OpenVPN#Why_to_use_O penVPN_.3F

No, upřímně, pro pokus bych se úplně vyprdnul na VPN a zkusil to přes GRE tunel, ten sice není zabezpečený (otázkou je, jestli je to vůbec potřeba), ale na 100% bude fungovat a nebude vůbec nic omezovat. Podmínkou je ovšem veřejná adresa na obou koncích.

To bude právě problém. Na jednom konci veřejná adresa není. O2 je už nějaký čas nedává ke každé lince.

Co se týče OpenVPN, v čem konkrétně spočívá jeho výhoda oproti PPTP, nakonfigurovat se to bude muset stejně, ne?

Fuuu, tak konečně úspěch. Běhá to!

Prohnal jsem to L2TP tunelem. Ještě jsem měl problém s DNS - ms-dns mám nastavené v konfiguráku xl2tpd na boxu správně - nevím, proč jich tunel nevyužívá. Nebo možná tunel ano, ale 192.168.0.111 ne. Což je vlastně logické. Vyřešil jsem to povolením DNS serveru na MTiku.

Zítra sepíšu komplet návod, jak jsem to nastavil, aby to běhalo, kdyby to někdo v budoucnu potřeboval. Díky za rady pánové, nakonec mě přeci jen dovedly k cíli.

PS: Kdyby někdo věděl, jak na Mtiku nastavit, aby 192.168.0.111 používal DNS servery, jako tunel, klidně ještě nějakou radu. Myslím, že by bylo čistší řešení používat DNS servery VPN boxu.

Tak té otázce moc nerozumím, snad je na tobě, jaké DNS servery bude používat jaký server. Podle toho, jaké tam nastavíš.

Jde o to, že bez DNS překladu v MTiku mi jde ping z 192.168.0.111 přes tunel a VPN box jen ip adresy, třeba 173.194.113.66 pro google. Když dám ping google.com, nenajde ho.

Podle mě je to způsobeno proto, protože dostal IP adresu od DHCP serveru, který si bere informace od DNS z ADSL linky, tedy DNS servery O2. Nicméně, protože gateway pro 192.168.0.111 je nastavena do tunelu, vůbec se k těm DNS O2 nedostane.

Samozřejmě bych mohl přímo na stanici 192.168.0.111 nastavit natvrdo DNS servery VPN boxu, ale to už by zase bylo v systému. Já to chci mít všechno na jednom místě v MTiku, abych nemusel neustále měnit nastavení pro každou stanici zvlášť při jakékoliv nepatrné změně.

L2TP klient na MTiku má DNS správně, tedy VPN Boxu, nicméně nevím, jak docílit, aby tyto DNS měl automaticky i 192.168.0.111. Pokud to vůbec lze.

Není problém mít v DHCP přidělený DNS server, který je až za tunelem. Případně ho ručně nastavit v serveru, jak linux, tak windows toto umožňují (tedy IP z DHCP, ale DNS fixně).

Tohle já vím, tady opět ale narážíme na to, že část klientů ve vnitřní síti má gateway klasicky přes O2.

ad2: To také vím a jak jsem psal, nechci to dělat systémově. Jistě, několik pc takto nastavit lze, ale jestli se mi projekt rozjede, nehodlám na několika desítkách systémů měnit DNS.

Nejjednodušší tedy bude asi nechat dělat MTik DNS server.