Dotaz: Sit pres vice geolokaci

[Tom]

Dobry den,

chtel bych se zeptat, jakym zpusobem by se mela navrhnout sit tak, aby byla rozprostrena pres vice geolokaci. Tyto lokace budou propojene treba pomoci site-2-site VPN (pomoci hlavnich routeru).

Cil snazeni je, aby bylo mozne presunout server (nebo virtual) z jedne lokace do druhe a aby byl funkcni bez potreby zmeny lokalni IP adresy, a aby stroje v tech lokacich komunikovali s ostatnimi, jako by slo o jednu velkou lokalni sit.

Momentalne si hraju s propojenim dvou lokaci pomoci OpenVPN, lokaceA 10.128.128.0/23 a lokaceB 10.128.130.0/24. VPN bezi, komunikace zarizeni mezi lokacemi jede obousmerne, to bych relk, ze je v poradku. Ale nemohu prenest server do druhe lokace aniz bych mu musel prenastavit IP parametry.

Je toto nejak realne zprovoznitelne? Muzete me trochu nasmerovat, nebo trochu vysvetlit jak se to dela?

Dekuji.

Odpovědi

[motyq]

bez blizsich informaci: openvpn bych zahodil a nasadil wireguard

a nasledne se podivej na to jak funguji vxlany

pokud nepujde jinak, muzou mit ty virtualky snad dve adresy, ne? (kazdou z jednoho rozsahu).

ale je to ciste nastrel, co bych zkusil, pokud bych nemel pod palcem komplet sitovou cestu na strane sitovych prvku.

[Max]

Fakt mi uniká doporučování řešení alá wireguard, jehož snad jediná výhoda oproti ipsecu je jednodušší konfigurace. Pak už to s ním jde z kopce.
Osobně bych se držel odzkoušených technologií, tj. řešení alá vxlan (tunelování L2 skrz IP) + ipsec, případně podobné alternativy jako např. Mikrotik s jeho EOIP, nebo MPLS/VPLS.
Zdar Max

[Michal Kubeček]

Protože panuje všeobecné přesvědčení, že IPsec je strašně složitý, naprosto nepochopitelný a vůbec úplně špatně navržený akademiky (jako všechno, co souvisí s IPv6). Takže je pořád potřeba vymýšlet nová a nová řešení: CIPE, vtun, openvpn, … a teď holt přichází do módy wireguard.

[Filip Jirsák]

Každý server bude mít několik IPv6 adres (jak je u IPv6 běžné). Link-local adresu (fe80::/10) platnou jen v místní síti, Unique-local adresu (fc00::/7) platnou ve vašich spolupracujících sítích a pak běžnou veřejnou IPv6 adresu.

[vencour]

Jo jo geografická redundance.
Má o ní zákazník vědět nebo ne?
Zákazník chodí na co, na IP adresu, DNS nebo něco jiného?
Dost často je to tak, že se "shodí" primár" (třeba router v cestě), nahodí "záloha" a jede se.
Uchováváte sešny, stav objednávek?

[Tom]

Dobry den, dekuji za odpovedi.

Ted jsem potreboval prenes jednu malou NASku do te druhe lokace, takze jsem ji musel prekonfigurovat IP. Vim, to je banalita, ale prave me tedy napadlo, co udelat pro to, abych ji mohl prenaset a a by ji mohla zustat porad ta sama adresa. Takze spis minimum konfigurace primo na zarizeni a spis to nejak zaridit konfiguraci cele site. Treba na te NAS nedam 2 IP, IPv6 uz vubec, nebo cely Proxmox serverik u ktereho je zmena IP pry docela problem (zatim jsem nezkousel).

U nekterych zarizeni bych prozatim asi vystacil s temi dvemi IP na jedne sitovce a pristupovat pomoci DNS jmena.

Koukam na to VXLAN, ale vzhledem k mym zkusenostem, to bude asi hudba hodne vzdalene budoucnosti....

Tak jeste jednou dekuji, snad se k tomu nekdy dopracuji

[Filip Jirsák]

Nejjednodušší a standardní je odkazovat se na ta zařízení přes DNS jména a zařízení konfigurovat přes DHCP. Když budete vymýšlet narovnáky na vohejbáky, aby tomu zařízení zůstala stejná IP adresa i v jiné síti, akorát si vše velmi zkomplikujete.

[vencour]

Tak, nekomplikovat si budoucí růst, nepřehánět složitost.
Dost často se používají různé balancery (proxy) pro usnadnění přístupu dovnitř/ven a zároveň pro zakrytí další komunikační vrstvy (kanálu).

[Jendа]

Jak se tohle dělá, když má to zařízení adresu z RFC1918 rozsahu? Některé resolvery je začaly blokovat jako ochranu proti DNS rebindingu.

[vencour]

A odkud na ně chcete komunikovat, z internetu? V korporaci to bývá všelijak, něco je na veřejné, něco na privátní. A dost často právě na balancerech.
Podstatné je, jak to naroutujete, zda přes internet, tunel nebo v rámci LAN.

[Jendа]

A odkud na ně chcete komunikovat, z internetu?

Z té VPN. Z Internetu se na RFC1918 adresy komunikovat samozřejmě nedá. Problém je v tom, že si nemůžu do zóny přidat

intranet.hrach.eu IN A 10.11.22.33

a pak nastavit klientovi VPN a jemu by to pak fungovalo.

Ale je pravda, že tazatel má site-to-site, takže má nejspíš resolver pod kontrolou.

[vencour]

Ježiš, když je to L2L, tak může i na vpn bráně dělat překlady (NAT), jak na vstupu, tak na výstupu.

[Jendа]

Cože? Ještě jednou, řeším DNS.

[vencour]

A co tedy řešíš? Přístup na DNS nebo podmíněný překlad?
O jaké síti se bavíme? Můžu mít DNS server pro vnitřní LAN nebo pro internet.
Pro jednoduchost aa jeden stroj bych to dal do host tabulky.
Jinak bych doménu hrach.eu poslal přeložit na internet a pro intranet.hrach.eu bych vrátil tu privátní IP.

[Jendа]

Tak znova.

A co tedy řešíš?

Řeším, jak se odkazovat se na zařízení ve vnitřní síti přes DNS jména, a to i v případě, kdy uživatelé nepoužívají resolver z té sítě - například protože public DNS zrovna frčí, nebo protože se tam připojují VPNkou z domova, kde používají svůj vlastní resolver.

Jinak bych doménu hrach.eu poslal přeložit na internet a pro intranet.hrach.eu bych vrátil tu privátní IP.

To právě nejde, protože některé resolvery je začaly blokovat jako ochranu proti DNS rebindingu.

[vencour]

Vím, že se to dá řešit doménou nedostupnou z internetu a použitou pouze ve vnitřní síti.
Pak se to ještě dělá definicí split tunelu v rámci vpn tunelu, něco jde do tunelu a něco ven na internet.
Tj. buď jde celý provoz v rámci vpn klienta do tunelu, nebo je výjimka (definice) na to, co se balí do tunelu nebo na to co do tunelu nepůjde.

[Filip Jirsák]

Problém je v tom, že si nemůžu do zóny přidat

intranet.hrach.eu IN A 10.11.22.33

a pak nastavit klientovi VPN a jemu by to pak fungovalo.

Proč by to nešlo?

[Jendа]

Protože některé resolvery je začaly blokovat jako ochranu proti DNS rebindingu. Například OpenWRT v defaultním nastavení.

[Filip Jirsák]

Takže to jde a problém je v tom resolveru.

[Jendа]

Ano, ale po mně většinou lidé chtějí, aby jim to fungovalo, nikoli aby se jenom dozvěděli, proč jim to nefunguje (s resolverem často nemohou nic dělat, například protože je to SOHO krabička s webovým nesmyslem, kde to nejde nastavit, neumí to nastavit, nebo to nemohou nastavit, protože resolver není jejich).

[Filip Jirsák]

Ty SOHO krabičky takhle rozbité nebudou, protože se většinou vyskytují právě v sítích s těmito privátními rozsahy. Jsou jen tři možnosti – buď sehnat dostatek veřejných IPv4 adres, abyste nemusel používat ty privátní, nebo opravit ten DNS resolver, a nebo změnit používaný resolver (třeba za resolver v té VPN síti). A tlačit na rozšíření IPv6, abychom se konečně zbavili těch privátních IPv4 adres.

[Filip Jirsák]

Privátní adresy se v lokálních sítích používají běžně, bohužel IPv6 ještě není tak rozšířené. A velmi často se používají i s DNS (často bohužel s různými lokálními doménami, což také způsobuje problémy). Takže DNS resolver, má-li být použitelný, musí umět tu ochranu pro určitou doménu vypnout, nebo jí umět vypnout alespoň globálně.

[vencour]

Nápověda: v korporacích se zpravidla používají pro web různé proxy a proxy.pac soubory, takže pak privátní sítě nemusí být přímo routované. Tolik pro přesnost.

[Filip Jirsák]

Nepsal jsem jen o korporacích. Proxy se používají především pro přístup ven, zatěžovat proxy i vnitřním provozem by bylo zvláštní. Ale hlavně – řeč nebyla o routování, ale o DNS. I při použití proxy překládá prohlížeč DNS název na IP adresu, takže kdyby to mělo fungovat tak, jak naznačujete svou „nápovědou“, musely by se interní DNS názvy překládat na veřejné IP adresy – a pak už by bylo jedno, zda tam je nebo není proxy. Jediný typ proxy, kde je možné použít DNS proxyserveru a ne lokální, je SOCKS5, který se používá velmi výjimečně. A tahle možnost navíc z rozšířených prohlížečů funguje jen ve Firefoxu a nejde nastavit přes proxy.pac.

[vencour]

Co pamatuju, tak proxy.pac socks 5 rozumí a Google mi to potvrzuje.
K tématu: proxy dělají přístup tam, kam to běžně nejde. Dobnitř i ven.
DNS lze použít pro interní i veřejné domény.
A ještě jedna věc: i veřejné IP adresy podle rozsahu nemuusí být záměrně v internetu routované.
Takže je na záměru tazatele, co potřebuje, jakou aplikaci a jakým způsobem vytunit.

[Filip Jirsák]

Co pamatuju, tak proxy.pac socks 5 rozumí a Google mi to potvrzuje.

Řeč ale nebyla o SOCKS5 obecně, ale o tom, že se požadavky na SOCKS5 proxy posílají s DNS názvy a ne s IP adresami, takže DNS názvy pak překládá ten proxy server. Tedy to, co dělá Firefox, když zapnete volbu „Použít proxy server pro DNS při použití SOCKS v5“. Jak se tohle nastavuje v proxy.pac?

[vencour]

Když budu mít nějaký proxy.pac a v něm (zdroj zde) mj.

return "SOCKS5 localhost:8080; SOCKS5 localhost:8081";

pro jistotu schéma větvení (zdroj)

function FindProxyForURL(url, host) { // variable strings to return var proxy_yes = "PROXY 10.130.16.60:8082";
var proxy_no = "DIRECT";
if (shExpMatch(url, "http://finance.yahoo.com*")) { return proxy_no; }
if (shExpMatch(url, "http://news.yahoo.com*")) { return proxy_no; }
if (shExpMatch(url, "http://www.google.com*")) { return proxy_no; }
if (shExpMatch(url, "http://video.google.com*")) { return proxy_no; }
if (shExpMatch(url, "http://zh-cn.facebook.com*")) { return proxy_no; }
if (shExpMatch(url, "http://10.130.16.150/*")) { return proxy_no; }
// Proxy anything else return proxy_yes;

tak by to na proxy mělo odesílat ten provoz, co je definovaný, ať už to je IP nebo nějaké FQDN.

[Filip Jirsák]

Dobře, zeptám se na to samé ještě potřetí – jak přes PAC zajistíte, aby prohlížeč nepřekládal názvy přes lokální DNS ale nechal překlad až na SOCKS5 proxy serveru? Tedy to, co při ruční konfiguraci proxy serveru ve Firefoxu dělá volba „Použít proxy server pro DNS při použití SOCKS v5“? Zejména by mne zajímalo, jak konkrétně by to fungovalo třeba při použití funkcí isResolvable(), isInNet() nebo dnsResolve().

[vencour]

Co pamatuju, tak takhle to funguje, že se provoz posílá na proxy, nedělá se (nezjišťuje) DNS překlad cíle na klientu.
Pokud chcete sestavit proxy.pac pro konkrétní implementaci, tak dejte zadání.

[Jendа]

Takže DNS resolver, má-li být použitelný, musí umět tu ochranu pro určitou doménu vypnout, nebo jí umět vypnout alespoň globálně.

Mně šlo o to, když se do VPN připojují vzdáleně uživatelé, u kterých netuším, jaký resolver používají (a může se to měnit když se přesunou). Jediné co mě napadlo je nastavit jim (např. v OpenVPN přes push dhcp-option DNS) svůj resolver pro všechno…

[Filip Jirsák]

Jediné co mě napadlo je nastavit jim (např. v OpenVPN přes push dhcp-option DNS) svůj resolver pro všechno…

To se přeci s VPN běžně dělá. Jinak by vám nefungovaly při připojení přes VPN DNS názvy v místní síti. Bohužel je pořád ještě doba, kdy jsou naprosto běžné IPv4 NATy, privátní IPv4 adresy a domény .local.

[Jendа]

To se přeci s VPN běžně dělá.

Mně to přijde jako prasárna: 1) šmíruju tím nesouvisející aktivity uživatele, 2) uživatel nemůže být (bez fakt husté konfigurace zahrnující vlastní resolver a delegace) připojen do dvou VPN současně.

Jinak by vám nefungovaly při připojení přes VPN DNS názvy v místní síti.

Já strkám názvy z vnitřní sítě do veřejného DNS stromu.

Bohužel je pořád ještě doba, kdy jsou naprosto běžné IPv4 NATy

Řešení „hurá, zahodíme openvpn a všude bude ipsec“, které navrhuje Michal Kubeček výše, a které by se mi taky docela líbilo, podle mě narazí na to, že zatímco pro openvpn stačí povolený jeden TCP nebo UDP port, ipsec bude z různých veřejných sítí blokován buď úmyslně, nebo chybnou konfigurací.

privátní IPv4 adresy

Trochu se bojím, že to někoho napadne i u fc00::/7.

[Filip Jirsák]

Prasárna to je, ale dokud se budou používat domény .local a podobné, není jiné řešení. Ono je dokonce běžné do VPN směrovat celý provoz, oproti tomu jsou DNS dotazy prkotina. A i když to tak není, připojení do dvou VPN bude často problém i z důvodu konfliktu rozsahů privátních adres. IPv4 způsobuje mnohem víc problémů, než jenom NAT…

Já strkám názvy z vnitřní sítě do veřejného DNS stromu.

Já to tak také dělám. Když už musíme používat privátní IPv4 adresy, je to pořád lepší, než používat ještě privátní domény. Blokovat privátní rozsahy v DNS resolverech je chyba a je potřeba to řešit v těch resolverech.

[vencour]

Bavíte se o funkčnosti nebo o čistotě návrhu? Když řešíte přístup někam přes VPN.
Když už někomu přístup umožníte, jak si můžete být jisti, co vám zavleče do sítě, co kam zkopíruje a kde zaškodí?
Aneb že se pohoršujete že "je dokonce běžné do VPN směrovat celý provoz".

[Filip Jirsák]

Bavíme se o funkčnosti. Jak přesně přesměrování veškerého provozu do VPN zabrání nákaze počítače před připojením do VPN? A nebo když bude počítač nakažen před připojením do VPN, připojení do VPN mu nějak zabrání ve škodění?

[vencour]

V principu se tohle řeší jako "End Point Security", zadáte nějaké podmínky, které chcete mít splněny, aktuální databázi antiviru, verzi programů, uživatele bez admin práv.
Tudíž když bude např. nakažen a antivir to pozná, tak se nepřipojí.

[Filip Jirsák]

Jak to souvisí se směrováním veškerého provozu do VPN?

[vencour]

LAN se považuje zpravidla ze více bezpečnou než nějaká stanice, která se někde toulá s obchodníkem po světě. Když mu omezíte možnosti nakazit svůj počítač, omezíte i možnost přenesení nákazy dál.

Mimochodem, kdo je tady vlastně tazatel, že se to celé vlákno nějak zamotalo a zabloudilo?

[Filip Jirsák]

Tak ještě jednou. Jak to, že omezíte možnosti nakažení počítače při připojení přes VPN, omezí možnosti nakažení počítače, když není připojen do VPN? Nebo vy počítáte s tím, že počítač je do VPN připojen trvale?

[vencour]

Obecně byste měl vědět, čeho chcete dosáhnout.
Na klientovi máte nějakou detekci a chcete mít požadovaný stav. Aktualizovaný software, antivirovou databázi. Poučené uživatele. Minimalizujete riziko.
A ve vlastní síti pak ještě sbíráte data do SIEMu i třeba z té VPN brány a podle provozu pak případně zaříznete toho, kdo se nějak provinil. A sjednáte nápravu. Minimalizujete následky.

[Filip Jirsák]

Já vím, čeho chci dosáhnout. Mně není jasné, čeho chcete dosáhnout vy.

[vencour]

Já si tu tak pindal na téma tazatele a pak reagoval na nějaké drobnosti. Když tazatel mlčí, tak mi je zbytek vlákna fuk, stejně jsem se nic nového nedozvěděl.

[Max]

Mno, přesměrování celého provozu do VPN má dvě výhody :
1) u spousty řešení lze nastavit, aby byl klient do vpn připojen trvale, tzn. jakmile je nějaký interface on, snaží se vpn klient o spojení s vpn server a až po úspěšném připojení povolí klientovi přístup na internet. Tzn. funguje to jako prevence v případě, že by se na klienta mělo něco dostat z netu, což bývá nejčastější případ
2) pokud máte nakaženého klienta a provoz jde přes vás, tak to můžete zjistit (pokud máte nasazenou nějakou analýzu / IDS)

Dále pokud se hodně bojíte a klient nepotřebuje flashky, lze zakázat připojení jakýchkoli storage přes usb, případně lze povolit jen konkrétní.

Pokud jde o dns veřejný vs směrování uživatele na lokální. Zakládat záznamy s lokálními IP do veřejného dns by mohlo vypadat jako řešení, ale to se odvíjí od nastavení sítě, kdy to v některých případech není možné, např. server je v lan síti a pro klienty v lan nelze nastavit vhodný routing pro natovanou veřejnou ip.
Zdar Max

[vencour]

Dík, Maxi, že jsi napsal.
a) možná ne tak natvrdo, ale snad jsem napsal to samé, co Ty.
b) ad DNS: snad vždy by se měl admin snažit, aby měl svou síť ve své správě. U DNS lze mít nějakou svou vnitřní doménu dostupnou pouze na privátních/vnitřních adresách. A co neni vnitřní forwardovat na veřejné DNS servery.
c) původní dotaz byl na jiné téma, asi není vůle, důvod či moc, která by tohle vlákno pročistila a rozsekala na víc kusů? Ať v tom neni takovej bordel. Na každou otázku se dá odpovědět všelijak, já se snažim odpovídat v kontextu tématu. Což se tady dost měnilo.

[Michal Kubeček]

Řešení „hurá, zahodíme openvpn a všude bude ipsec“, které navrhuje Michal Kubeček výše, a které by se mi taky docela líbilo, podle mě narazí na to, že zatímco pro openvpn stačí povolený jeden TCP nebo UDP port, ipsec bude z různých veřejných sítí blokován buď úmyslně, nebo chybnou konfigurací.

Ať čtu původní dotaz jak chci, vyznívá mi jako dotaz na implementaci permanentního propojení dvou (nebo více) firemních poboček, ne jako dotaz na to, jak umožnit lidem připojení do sítě tak, aby to nějak fungovalo i z všelijakých podivných hotelových, letištních či obchoďákových sítí. A pro takový účel mi vxlan + IPsec připadá jako zdaleka nejvhodnější (pokud nestačí IPsec samotný).