Dotaz: VPN - stejné IP rozsahy na obou stranách

[jan.rok]

Dobrý den,

z vnitřní LAN s rozsahem 192.168.1.0/24 se přes VPN (L2TP, Mikrotik) připojuju do vzdálené sítě (opět L2TP, Mikrotik), která má bohužel stejný rozsah IP adres 192.168.1.0/24.

Po připojení do VPN dostanu adresu z rozsahu 10.0.0.0/24. Problémem je, že když se potřebuju dostat na vzdálený interní fileserver běžící na adrese 192.168.1.1, dostanu se místo toho na svůj fileserver, který má totožnou IP adresu 192.168.1.1 jako ten vzdálený.

Samozřejmě čisté řešení je mít na každé straně jiný rozsah, ale toho nemůžu teď hned dosáhnout. Vzdálenou stranu neovlivním, u sebe je to organizačně náročné a přistoupil bych k tomu až v okamžiku, kdy nebude jiné technické řešení.

Tak se jen ptám, jestli se tohle nějak dá vyřešit. Díky. J.R.

---

---

Odpovědi

[Josef Kufner]

Můžeš zkusit nastavit routu pro tu konkrétní IP adresu, aby to nešlo na lokální síť, ale do VPN. Samozřejmě se pak nepřipojíš na oba servery současně.

[jan.rok]

Současné spojení na oba servery by potřeba nebylo.

route -p add 10.0.0.55 mask 255.255.255.255 192.168.1.1, kde

192.168.1.1 je adresa fileserveru na vzdálené straně,

10.0.0.55 je adresa , kterou mi přidělí vzdálený VPN server

Chápu to správně?

[trekker.dk]

Ta VPN je natažená mezi těmi mikrotiky (jeden jako server, druhý jako klient), nebo dostáváte IP VNP adresu přímo na tom stroji, ze kterého se připojujete?

Jestli mezi těmi mikrotiky, tak si musíte nastavit routu na tom stroji tak, aby nutila provoz k cílovému serveru přes mikrotik na vaší straně: ip route add 192.168.1.1/32 via 192.168.1.254, přičemž 192.168.1.254 odhaduji, že je vaše výchozí brána. Na tomhle mikrotiku pak budete muset nastavit, že provoz na 192.168.1.1 nemá hnát do sítě, ve které sedí, ale přes tu VPN (tj. pokud na své straně taky máte stroj s IP 192.168.1.1, tak se s tím mikrotikem nedomluví.) Nejspíš taky budete potřebovat NAT, aby pakety odcházející do té VPN neměly vaší IP adresu 192.168.1.x, ale adresu VPN, jinak vám ten vzdálený server nebude schopný odpovědět.

Jako když se budete hodně snažit, tak ta data nakonec nějak protlačíte, ale osobně bych se tomu, pokud by to jen trochu šlo, pokusil vyhnout. Ať vymyslíte cokoliv, tak vás to s velkou pravděpodobností jednoho krásného dne klepne přes prsty.

[jan.rok]

Dostávám IP VPN adresu přímo na tom stroji, ze kterého se připojuju. Routery VPNkou spojené nejsou.

[trekker.dk]

Tak to je o něco lepší, v takovém případě ip route add 192.168.1.1/32 via 10.0.0.X - místo IP adresy z VPN na vaší straně je potřeba tam dát IP adresu ve VPN toho stroje, který vidí na cílový server. NAT potřebujete i tak - pakety odcházející do té VPN musí mít jako zdrojovu adresu 10.0.0.55 (zajistí jednoduché pravidlo masquerade v nastavení firewallu)

[a1bert]

tady pomuze IMHO jedine SNAT+DNAT , adresuj tu vzdalenou sit jinym rozsahem a prekladej SNATem zdrojovou adresu na lokalnim routeru a cilovou na vzdalenem routeru)

napr:

ping na vzdaleny server (skutecna ip 192.168.1.1) fiktivni 192.168.10.1

                           src ip         dst ip
lokalni sit           192.168.1.123  192.168.10.1
vpn                   192.168.11.123 192.168.10.1
vzdalena sit          192.168.11.123 192.168.1.1
 

[j]

A nebylo by mnohem jednodussi se vykaslat na vyrabeni VPNky? Pokud ti jde o jednorazovej pristup z jednoho stroje, tak je mnohem efektivnejsi, kdyz cil (server) forwardnou z nejakyho portu (ssh/rdp/...), klidne s omezenim ze jen ze tvoji IP, a ty se proste pripojis na verejnou IP a ten port.

Jinak budes resit strasny vopicarny ktery stejne nebudou fungovat.

BTW: Reseni (jediny spravny a bezproblemovy) je ipv6.

[Max]

Bavíme se tu čistě o L2TP? Nebo je to L2TP over IPSEC?
Jinak standardně se split tunneling nedělá, třeba Windows by default vše routujou do tunelu. Kolizní síť pak nevadí, protože prio má tunel (routa 0.0.0.0 -> tunel).
Takže by to chtělo aspoň výpis ip route, případně i info o nastavení na straně toho Mikrotiku.
Zdar Max

[jan.rok]

Měl jsem to upřesnit hned: jde o L2TP over IPSEC.

Prosím o vysvětlení tohoto:

Ta informace o Windows, že by default vše routujou do tunelu: má tím být myšleno, že po ustavení VPN se na svou lokální síť nedostanu? Tak to ale není: když to ve Windows zkusím, tak můžu jak na lokální síť, tak přes VPN na vzdálenou. A kdyby kolizní síť na druhé straně nevadila (kdyby měla prioritu routa 0.0.0.0 --> tunel), pak bych se na vzdálený fileserver 192.168.1.1 dostal. Ale já se dostanu na lokální 192.168.1.1.

Takže tomu tvrzení nerozumím.

Jestliže jsou na obou stranách vpn tunelu stejné rozsahy a neroutuješ všechno do tunelu, tak potom nějak nechápu, jak se na druhou stranu toho tunelu vůbec dostaneš... Nebylo by lepší sem hodit výpis routovací tabulky?

[panika]

Příloha:

• vpn default gw.JPG (99128 bytů)

snad myslime oba to samy - widle udelaj na vpn default gateway, da se to vypnout viz priloha a pak to jede podle routovaci tabulky..

// ja bych teda sel cestou dnatu a snatu

[j]

Ted to ovsem vypada, ze ty netusis, co je to default a jak funguje routovani.

Na default GW se provoz posila AZ v pripade, ze neni znama exaktni routa = vzdy az nakonec. Tudiz pokud jde provoz do lokalni site, kterou ten stroj primo zna, tak to jde vzdy naprimo. Ostatne bez toho bys ani tu VPNku vubec nezprovoznil, kam bys asi tak chtel posilat provoz toho tunelu, do nej?

Jinak receno, to co ti widle (a ostatne kazdej tunel) umoznuje, je pochopitelne poslat default skrz nej, ale to nijak neresi problem stejnych rozsahu.

[j]

Kolizni sit samozrejme vadi zcela vzdy. Viz nekde kolem, jak bys asi tak chtel napojit ten tunel, kdyz veskerej provoz posles do nej. Ano, muzes do nej poslat default, ale lanka ti pude naprimo. A pokud do toho tunelu rucne preroutujes i ten lankovej rozsah, tak se ti pochopitelne obratem ten tunel rozpadne.

Japa bys chtel systemu vysvetlovat, ze na cojavim 192.168.1.1 v lance ma posilat provoz toho tunelu, ale ze zaroven, ma pozadavky na 192.168.1.1 posilat dovnitr toho tunelu? Tohle se da delat tema vopicarnama s NATem. Na kterym si nabijes hubu hned o krok dal.

Pri routovani plati, ze se vzdy nejdriv pouzije nejmensi prefix. Default = "vsechno co nevim kam".

BTW: Pokud se nic zasadne nezmenilo, tak pokud je pravda, ze dotycny hodla tunel navazovat az z privatni site, a zaroven chce pouzivat ipsec, tak se ani nespoji. Protoze pokud mi skleroza slouzi, tak ipsec je prave jeden z tech protokolu, ktery IPcka posilaji primo uvnitr, a tudiz se da navazat pouze mezi strojema kde kazdej jeden ma verenou IP.

[Max]

To se bohužel trochu pleteš. A skoro ve všem.
Teď tu u sebe nemám kolizní sít, abych ti hodil přesný example, jak to funguje. Pokud si najdu čas, tak si doma překonfiguruju síť na kolizní a pak se na vpn připojím a pošlu ti info o routách apod.
Jinak provozuji IKEv2 byod VPN na Debianu+Strongswan asi pro 500 lidí a aktuálně vidím jednoho, který je připojen z kolizní sítě 192.168.1.0/24.

byod-ikev2[1017024]: ESTABLISHED 12 minutes ago, 172.xx.xx.20[vpn-ph.corp.domain.tld]...89.xxx.xxx.64[192.168.1.35]
byod-ikev2[1017024]: Remote EAP identity: user@domain.tld
byod-ikev2[1017024]: IKEv2 SPIs: a20c9c1ec771c123_i 5a627cc60c0aad4b_r*, public key reauthentication in 7 hours
byod-ikev2[1017024]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
byod-ikev2{1520034}:  INSTALLED, TUNNEL, reqid 878100, ESP in UDP SPIs: cc56a343_i 05c1f8fe_o
byod-ikev2{1520034}:  AES_CBC_256/HMAC_SHA2_256_128, 254 bytes_i (4 pkts, 424s ago), 720 bytes_o (4 pkts, 425s ago), rekeying in 42 minutes
byod-ikev2{1520034}:   10.xxx.xxx.0/16 10.xxx.xxx.0/14 192.168.1.0/24 192.168.83.0/24 === 192.168.83.250/32

Z aktivního spojení je vidět, že klient má ve vnitřní síti adresu "192.168.1.35", z VPN serveru dostal adresu 192.168.83.250/32 a připojuje se na servery, které jsou u nás v síti 192.168.1.0/24.
Na ipsec serveru mám (ipsec server má jinak jednu z ip taktéž ze subnetu 192.168.1.0/24):

...
leftsubnet=192.168.83.0/24,192.168.1.0/24,10.xxx.xxx.0/16,10.xxx.xxx.0/14
...
right=%any
rightid=%any
rightsourceip=192.168.83.0/24
...

+ mám nastavený SPLIT tunneling, takže k nám uživatel přistupuje na služby, ale na internet přistupuje přímo.
Je to odzkoušeno a funkční na Windows 7,8,8.1,10, Android 4.4 a vyšší (se strongswann app), iOS 9 a vyšší, Windows Mobile Phone 8.1 i 10.
Zdar Max

[lertimir]

Ale i když to řešit jde, tak je kolizní síť trochu ojeb. Když si na doma dám nejakou neobvyklejší jako třeba 172.27.14.0/24 tak pravděpodobnost kolize je značně malá a nemusím nic řešit. Jediný co může být problém je když z nějakého důvodu musím resetnout router, tak musím si pamatovat do jaké sítě se resetnul.

[Max]

Pokud neřeším site2site ipsec tunel, tak mně kolize moc nezajímají (viz ten příklad pro klienty). Pokud řeším site2site a mám kolizi, tak jen přihodím nat over ipsec a no problemo (osobní zkušenost z jobu, kdy jsem toto provozoval s jinou firmou).
Zdar Max

[lertimir]

Řešit to jde, ale je na tom celkem dost hezky vidět, že nechat default není dobrá strategie i u rozsahu interní sítě.

[jan.rok]

Díky všem za názory.

Že jsou stejné rozsahy problém, to jsem věděl/vyčetl. Spíš mě zajímalo, jestli zkušenější nemají nějakou chytrou obezličku, kterou bych mohl dočasně použít. Nějaké problematické možnosti tedy jsou.

Mezitím jsem se domluvil na vzdálené straně, kde je menší problém změnit síťový rozsah. Myslím, že debatu uzavřeme a budu si pamatovat, že je dobré změnit defaultní adresy, které nabízí běžný router na něco méně obvyklého, abych se tím vyhnul podobným kolizím.

[[Jooky]]

Mikrotik zvlada BCP (e.g. Bridge Control Protocol). Funguje to nad vacsinou PPP liniek. Idea je taka, ze namiesto klasickeho IP a routovania sa v tuneli posielaju L2 ramce a viacmenej sa spojenie tvari ako "ethernet". Tym padom vies spravit taku vec, ze VPN na oboch stranach "pichnes" do brigu/switchu pre LAN. Tym padom sa dve rozdielne lokality tvaria ako jeden broadcast segment (e.g. pre IP zariadenia je to transparentne). Ma to sice aj svoje negativa, ale funguje to dobre (vid dole). Ja som napr dlhu dobu tak pouzival povodny magio box od telekomu ... magio box (a aj telekom) si myslel, ze ho mam stale doma a ja som mal mobilnu kombinaciu s mikrotik routerom

MikroTik BCP

Druha moznost je si postavit klasicke IP spojenie a ponad neho dat EoIP. Logika je ta ista, ale ine "prevedenie". EoIP (Ethernet over IP) vytvara ethernet tunel, ktory je mozny pridat do lokalneho bridge, alebo switcha. Tym padom ako BCP vyraba transparetne spojenie. Akurat sa to inac konfiguruje a ma iny overhead. Ja pouzivam EoIP niekedy namiesto VLAN/VPN, na spojenia, kde nie je velky load (lahsie sa to nastavuje).

MikroTik - EoIP

... pri oboch si ale treba uvedomit, ze cez tunel bude chodit aj broadcast. Windows masiny niekedy broadcastuju netbios / cifs spojenia a rozne ilo/remote krabicky tiez vedia dost broadcastovat traffic. V takej situacii sa moze stat, ze sa bude tunel zahlcovat balastom. Druha vec je, ze napr duplikatnu IP budes musiet hladat nie na jednom mieste, ale na dvoch :D kedze to bude stale jeden segment ... a ked tie IP budu na roznych stranach, tak sa moze stat, ze "masina" bude vidiet vsetko lokalne, ale nebude davat zmysel, preco nejdu veci remote ... Ja by som bol za to, ze obe riesenia budu dobry workaround, ale finalne riesenie by mal byt routing.

(obe linky maju nielen detaily nastavenia, ale aj example konfiguracie presne na ten styl, ze 2x office na roznych miestach)

A nevznikne propojením dvou sítí se stejným ip rozsahem a se stejnými používanými ip adresami (jak píše tazatel) na síti poněkud maglajs?

[L]

Pokud je na tom počítači Linux, tak bych doporučil fyzické rozhraní přesunout do odděleného síťového jmenného prostoru, tunel sestavovat v tomto odděleném síťovém jmenném prostoru a do hlavního síťového jmenného prostoru přidat pouze virtuální rozhraní tunelu.

Pak tyto problémy kompletně odpadají a bonusem je i mnohem menší pravděpodobnost, že špatná konfigurace nebo nějaký jiný omyl způsobí degradaci bezpečnosti. Také je pak mnohem snadnější a čistší řešení autokonfigurace fyzického síťového rozhraní.

Používám to takto na OpenVPN, ale mělo by se to dát zprovoznit v podstatě s jakýmkoliv tunelem.

Nevýhodou je, že ač to v Linuxu funguje velmi dobře, tak na jiných systémech není pro síťové jmenné prostory podpora žádná.

[trekker.dk]

Tipnul bych si, že ten server potřebuje vidět i do své vlastní sítě, takže bych to udělal spíš obráceně a do jmenného prostoru přestěhoval to virtuální rozhraní od VPN. (Krom toho když přesunete fyzické rozhraní, tak v hlavním jmenném prostoru tu VPN nevyrobíte, protože se nebude mít jak připojit.)

[alkoholik]

OpenBSD ma routing domains. Ty by se daly nejspis taky pouzit.