HTTPS na privátní adrese

[Stilett]

Narazil jsem na jeden problém. Jak spolehlivě provozovat HTTPS na privátní IP adrese?

Situace: V síti některých poskytovatelů máme umístěný server, který posílá data uživatelům z dotyčné sítě, a tento server z důvodu omezení zátěže NATu vystupuje na privátní adrese (obvykle 10.x.y.z). Když detekuji, že uživatel přichází z dotyčné sítě, pošlu ho na privátní adresu serveru v té síti.

Zároveň chci použít HTTPS s důvěryhodným certifikátem. Přiřadil jsem tedy serveru doménové jméno z naší subdomény směřující na privátní adresu a získal důvěryhodný certifikát (přes DNS validaci).

Všechno to funguje. Až na to, že se ukázalo, že existuje jisté malé procento uživatelů, kteří mají doma router, který blokuje DNS překlad jmen na privátní adresy. Jedná se obvykle o zařízení s OpenWRT s dnsmasq, které má zapnutou volbu stop-dns-rebind. Tato volba blokuje překlady doménových jmen na privátní IP adresy, které přicházejí z upstream nameserverů (tedy nejsou lokálně nakonfigurované v dnsmasq). Pokud tedy popis volby správně chápu. Což je pro mé použití docela problém.

Smysl má být udajně ochrana před útokem DNS rebinding, ale blokuje to poněkud více věcí. Prý existuje RFC, které tvrdí, že takovéto směrování domén na privátní adresy se nemá dělat. Ale vždyť např. BIND má podporu split-horizon (split-view) DNS, který se používá částo právě pro přiřazování privátních IP adres, když přichází dotaz z privátní sítě.

Je to tedy pitomé chování toho routeru (dnsmasq), nebo by se taková věc opravdu neměla dělat? Jak mám tedy používat HTTPS na privátní IP adrese?

Na routeru lze obvykle nastavit výjimku pro určitou doménu, ale není to zrovna hromadné řešení problému.

[Reklama]

[n]

A kdyz detekujes ze to nefunguje, tak udelej dalsi fallback na neco s verejnou adresou. Vykon bude sice suboptimalni, ale sluzba bude dorucena. Pokud tedy to "jiste male procento" neni veskutecnosti dost velke na to, aby si zaslouzilo vetsi mentalni investici do vyzkumu jak to resit jinak/lepe.

[Filip Jirsák]

Ano, IP adresy z privátních rozsahů by se ve veřejném DNS neměly objevovat, tvrdí RFC. Správné řešení je používat IPv6, kde je dost veřejných IP adres. Ostatní řešení jsou špatná – a z těch špatných je to nejméně špatné používat veřejné domény směřující na privátní IPv4 adresy.

Je to tedy pitomé chování toho routeru a řešením je uživatelům to vysvětlit a přesvědčit je, aby si ten router přenastavili (uživatelé OpenWRT to snad budou umět). Když nás takových bude víc, třeba autoři OpenWRT pochopí, že není ani rok 1998 ani 2038 a že je potřeba se s veřejnými doménami směřujícími na privátní IPv4 adresy smířit.

Další možnosti jsou používat vlastní certifikační autoritu nebo self-signed certifikáty, nebo HTTPS nepoužívat vůbec – všechno nesrovnatelně horší možnosti oproti privátním IPv4 adresám ve veřejném DNS, které jsou pouze kosmetickým problémem (DNS rebind je pouze zástěrka – pokud nějaký server zveřejňuje něco, co veřejné být nemá, je to bezpečnostní problém bez ohledu na to, jestli ten server má nebo nemá jméno).

[Miroslav Šilhavý]

Když nás takových bude víc, třeba autoři OpenWRT pochopí, že není ani rok 1998 ani 2038 a že je potřeba se s veřejnými doménami směřujícími na privátní IPv4 adresy smířit.

To podle mě není dobré řešení. Přebíjet DNS odpovědi je "nebezpečné" - ve smyslu hledání problémů. Na takové řešení si po roce už nikdo nevzpomene a pak se obvykle v síti honí duchy.

Daleko lepší je dotaz na routeru, i za cenu více router-cyklů přechroustat SNATEM i DNATEM - tedy cíl přepsat DNATEM z veřejné IP adresy na privádní, a zdrojovou (aby se navrátila odpvěď) přepsat SNATEM naopak na veřejnou IP adresu routeru.

Pokud tedy máme:
10.0.0.45 (klient PC)
10.0.0.10 (server v privátním rozsahu)
10.0.0.1 (privátní IP routeru)
184.47.23.3 (veřejná IP routeru a zároveň veřejná IP serveru (NAT))


Takže z požadavku:
10.0.0.45 (klient) => 184.47.23.3 (server)
se v prvním kroku provede DNAT:
10.0.0.45 (klient) => 10.0.0.10 (server - privátní)
a v druhém kroku (kvůli zpětné cestě přes router, kvůli RP filtru)
10.0.0.1 (router-privátní) => 10.0.0.10 (server - privátní)

Takže požadavek bude:
10.0.0.45 => 184.47.23.3(<=DNAT+SNAT=>)10.0.0.1 => 10.0.0.10
a odpověď bude:
10.0.0.10 => 10.0.0.1 => 10.0.0.45

[MP]

Když nás takových bude víc, třeba autoři OpenWRT pochopí, že není ani rok 1998 ani 2038 a že je potřeba se s veřejnými doménami směřujícími na privátní IPv4 adresy smířit.

To podle mě není dobré řešení. Přebíjet DNS odpovědi je "nebezpečné" - ve smyslu hledání problémů. Na takové řešení si po roce už nikdo nevzpomene a pak se obvykle v síti honí duchy.

Daleko lepší je dotaz na routeru, i za cenu více router-cyklů přechroustat SNATEM i DNATEM - tedy cíl přepsat DNATEM z veřejné IP adresy na privádní, a zdrojovou (aby se navrátila odpvěď) přepsat SNATEM naopak na veřejnou IP adresu routeru.

Pokud tedy máme:
10.0.0.45 (klient PC)
10.0.0.10 (server v privátním rozsahu)
10.0.0.1 (privátní IP routeru)
184.47.23.3 (veřejná IP routeru a zároveň veřejná IP serveru (NAT))


Takže z požadavku:
10.0.0.45 (klient) => 184.47.23.3 (server)
se v prvním kroku provede DNAT:
10.0.0.45 (klient) => 10.0.0.10 (server - privátní)
a v druhém kroku (kvůli zpětné cestě přes router, kvůli RP filtru)
10.0.0.1 (router-privátní) => 10.0.0.10 (server - privátní)

Takže požadavek bude:
10.0.0.45 => 184.47.23.3(<=DNAT+SNAT=>)10.0.0.1 => 10.0.0.10
a odpověď bude:
10.0.0.10 => 10.0.0.1 => 10.0.0.45

To reknete tem poskytovatelum, u kterych je ten "privatni" server umisten?

[Reklama]

[Miroslav Šilhavý]

To reknete tem poskytovatelum, u kterych je ten "privatni" server umisten?

Ano, asi by jim to mělo být řečeno , protože server, který je z vnitřní sítě nedostupný, ač má být dostupný veřejně, je zjevná chyba.

S touto situací jsem se setkal jen v rámci jedné firmy, jedné přípojky, kdy zákazník má server ve vnitřní síti, a zvenčí je NAT a zevnitř je problém se na něj dostat (právě kvůli resolvování DNS na veřejnou IP adresu). U ISP, doufám, toto nenastává. Na hostingu je pořád standard veřejná IP adresa, pro tyto účely je jich pořád dostatek.

[samalama]

Když nás takových bude víc, třeba autoři OpenWRT pochopí, že není ani rok 1998 ani 2038 a že je potřeba se s veřejnými doménami směřujícími na privátní IPv4 adresy smířit.

To podle mě není dobré řešení. Přebíjet DNS odpovědi je "nebezpečné" - ve smyslu hledání problémů. Na takové řešení si po roce už nikdo nevzpomene a pak se obvykle v síti honí duchy.

Daleko lepší je dotaz na routeru, i za cenu více router-cyklů přechroustat SNATEM i DNATEM - tedy cíl přepsat DNATEM z veřejné IP adresy na privádní, a zdrojovou (aby se navrátila odpvěď) přepsat SNATEM naopak na veřejnou IP adresu routeru.

Pokud tedy máme:
10.0.0.45 (klient PC)
10.0.0.10 (server v privátním rozsahu)
10.0.0.1 (privátní IP routeru)
184.47.23.3 (veřejná IP routeru a zároveň veřejná IP serveru (NAT))


Takže z požadavku:
10.0.0.45 (klient) => 184.47.23.3 (server)
se v prvním kroku provede DNAT:
10.0.0.45 (klient) => 10.0.0.10 (server - privátní)
a v druhém kroku (kvůli zpětné cestě přes router, kvůli RP filtru)
10.0.0.1 (router-privátní) => 10.0.0.10 (server - privátní)

Takže požadavek bude:
10.0.0.45 => 184.47.23.3(<=DNAT+SNAT=>)10.0.0.1 => 10.0.0.10
a odpověď bude:
10.0.0.10 => 10.0.0.1 => 10.0.0.45

co samozrejme nebude fungovat, pretoze klientovi v tomto pripade pride odpoved z 10.0.0.1 a nie z 184.47.23.3...

[Miroslav Šilhavý]

co samozrejme nebude fungovat, pretoze klientovi v tomto pripade pride odpoved z 10.0.0.1 a nie z 184.47.23.3...

Cestou zpět se uplatní zase, takže jsem to měl napsat spíš jako:

10.0.0.10 => 10.0.0.1/184.47.23.3 => 10.0.0.45

[Filip Jirsák]

To podle mě není dobré řešení. Přebíjet DNS odpovědi je "nebezpečné"

Vaše řešení asi dobré nebude. V mém řešení se ale žádné přebíjení DNS odpovědí nevyskytuje.

Daleko lepší je dotaz na routeru, i za cenu více router-cyklů přechroustat SNATEM i DNATEM

To, že se musí vedle DNATu udělat ještě SNAT, je na tom celém to nejmenší. Podstatné je to, že tu komunikaci nuceně ženete přes router, přestože by mohla jít přímo. Když budete chtít mezi klientem a serverem přenášet větší objem dat, je dost podstatný rozdíl, zda budete ze serveru na klienta přímo přes switch stahovat třeba 800 Mbit/s, nebo jestli to poženete přes router, který tím pádem bude potřebovat odbavit 1,6 Gbit/s a ještě to bude prohánět NATem.

Vzhledem k tomu, že Stillet píše o omezení zátěže NATu, je ta vaše rada přesně to, čemu se chce vyhnout.

[Miroslav Šilhavý]

To, že se musí vedle DNATu udělat ještě SNAT, je na tom celém to nejmenší. Podstatné je to, že tu komunikaci nuceně ženete přes router, přestože by mohla jít přímo. Když budete chtít mezi klientem a serverem přenášet větší objem dat, je dost podstatný rozdíl, zda budete ze serveru na klienta přímo přes switch stahovat třeba 800 Mbit/s, nebo jestli to poženete přes router, který tím pádem bude potřebovat odbavit 1,6 Gbit/s a ještě to bude prohánět NATem.

Vzhledem k tomu, že Stillet píše o omezení zátěže NATu, je ta vaše rada přesně to, čemu se chce vyhnout.

Souhlasím, ale považuji to za menší zlo než jiná řešení.

[Vilith]

Nejsnazsi se domluvit s temi sitemi a pouzivat verejnou IP z jejich rozsahu.
A nemusite se drbat levou rukou za pravym uchem.

Ale asi bude problem v tom, ze to je neco, o cem ti spravcove siti nevedi...

[Filip Jirsák]

Nejsnazsi se domluvit s temi sitemi a pouzivat verejnou IP z jejich rozsahu.

Když se chce Stilett vyhnout NATu, není asi moc dobrá rada napsat (a ještě ne otevřeně)  „nejsnazší je použít NAT“. Může to tak být, ale pak je asi potřeba napsat „to, co chcete dělat, není z toho a toho důvodu dobrý nápad“.

Navíc úplně stejný problém nastává i tam, kde žádná veřejná IPv4 adresa není – kde je server v lokální síti, který z venku nemá být dostupný a žádnou nadbytečnou veřejnou IPv4 adresu, kterou byste na něj dal, nemáte. Představte si třeba školní síť se serverem, a od ISP dostane ta škola v lepším případě jednu dynamickou veřejnou IPv4 adresu pro vnější rozhraní routeru, v horším případě se bude dělat NAT až u ISP.

[Miroslav Šilhavý]

Navíc úplně stejný problém nastává i tam, kde žádná veřejná IPv4 adresa není – kde je server v lokální síti, který z venku nemá být dostupný a žádnou nadbytečnou veřejnou IPv4 adresu, kterou byste na něj dal, nemáte. Představte si třeba školní síť se serverem, a od ISP dostane ta škola v lepším případě jednu dynamickou veřejnou IPv4 adresu pro vnější rozhraní routeru, v horším případě se bude dělat NAT až u ISP.

Ano, ale "uzváldat" SNAT+DNAT na routeru, např. ve školní síti, není zas až tak nepřekonatelný problém. Podle mě bude existovat jen málo skutečných situací, kdy nemáte možnost mít veřejnou IP adresu a zároveň nemáte ani možnost "ustíhat" NAT. Když si představím hraniční router takové sítě, podle mě na conntracku NATU má takové množství spojení, že ještě nějaká navíc zpět do vlastní sítě už nemohou hrát tak velkou roli. To řešení má velkou výhodu v tom, že je pro síťaře dobře čitelné a chová se vypočitatelně. Ale jak píšete, za cenu ztraceného výkonu na routeru.

[Filip Jirsák]

Ano, ale "uzváldat" SNAT+DNAT na routeru, např. ve školní síti, není zas až tak nepřekonatelný problém. Podle mě bude existovat jen málo skutečných situací, kdy nemáte možnost mít veřejnou IP adresu a zároveň nemáte ani možnost "ustíhat" NAT. Když si představím hraniční router takové sítě, podle mě na conntracku NATU má takové množství spojení, že ještě nějaká navíc zpět do vlastní sítě už nemohou hrát tak velkou roli. To řešení má velkou výhodu v tom, že je pro síťaře dobře čitelné a chová se vypočitatelně. Ale jak píšete, za cenu ztraceného výkonu na routeru.

Akorát že vůbec nejde o počet spojení, ale o datový tok. Pokud má ta síť připojení do internetu 100 Mbit/s, musí ten router umět uNATovat 100 Mbit/s. Pokud bude mít server s 1 Gbit/s síťovkou, měl by ten router umět uNATovat 2 Gbit/s. To je sakra rozdíl.

Navíc na tom serveru nepoznáte, odkud ta spojení jdou, všechna budou z routeru – nemůžete dělat QoS, nic nepoznáte z logu.

Že je to řešení pro síťaře čitelné a chová se vypočitatelně je snad vtip. Porovnáváte přímé spojení přes switch se spojením dvakrát NATovaným na routeru. Nechcete snad tvrdit, že ten dvojitý NAT to zpřehlední a vylepší…

[Vilith]

Zajimave, ze vsichni velci ISP to maji vyresene a radi urcite poradi s timto problemem (kazdy muze navrhnout jine reseni specificke pro jeho sit). V privatnich sitich v tom take neni problem, tam mate centralni spravu a vnutite klientum selfsigned certifikat a interni DNS
Cele to je o tom, ze se tady nejspis snazi nekdo s necim "vydrbat"...