241
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
242
Sítě / Re:HTTP/HTTPS vyhradne len s proxy
« kdy: 16. 04. 2021, 09:41:14 »
Umi ten router nastavovat firewall pravidla? Jestli ne, tak to nevynutite. Maximalne to nastavite pres dhcp, ale kdokoli si to muze zmenit.
243
Sítě / Re:Google Play nefunguje po IPv6
« kdy: 03. 04. 2021, 10:18:17 »Potvrzuji problém. Na mém Pixel 3A XL po připojení do IPv6-only sítě bez podpory IPv4 funguje webová stránka play.google.com, ale nativní aplikace Obchod Play tvrdí, že připojení k internetu není k dispozici. Když do IPv6 sítě přidám NAT64 a DNS64, všechno funguje jak má. Aplikace tedy evidentně používá nějakou serverovou službu, která není po IPv6 dostupná.
Pane Caletko, diky za otestovani, tim padem to jiz zkoumat nemusim. To je mizerie, kolik veci na ipv6 nefunguje ani u velkych hracu...
A ano, slo o nativni aplikaci, to jsem puvodne zapomel uvest.
244
Sítě / Google Play nefunguje po IPv6
« kdy: 01. 04. 2021, 14:51:53 »
Ahoj,
mam tu takovou zahadu. Zkousim ipv6 nastavit primo pres L3 switche, takze veskere slaac/ra atd. je primo na nich. V ceste neni zadny firewall.
Dhcpv6 pool definuje dns apod pro dhcpv6 klienty.
A ted zajimave chovani android vs windows 10 - v obou pripadech maji zarizeni pouze ipv6 adresaci (windows dhcpv6, android slaac), route, dns...vse nastaveno
- windows 10 -> play.google.com = zobrazena stranka
- android -> play.google.com = no internet connection (pritom google maps, google mail atd atd funguji, pingy na public dns, preklady, vse funguje)
Nejake napady, nez vytahnu fyzicky wireshark, nebot spojeni jinak nezobrazim
mam tu takovou zahadu. Zkousim ipv6 nastavit primo pres L3 switche, takze veskere slaac/ra atd. je primo na nich. V ceste neni zadny firewall.
Kód: [Vybrat]
interface vlanifX
desc "wifi ipv6"
ipv6 enable
ipv6 address A:B:C::1/64
undo ipv6 nd ra halt
ipv6 nd ra dns-server 2001:4860:4860::8888
ipv6 nd ra dns-server 2001:4860:4860::8844
ipv6 nd ra dns-suffix somedomain.tld
ipv6 nd autoconfig other-flag
dhcpv6 server somepool
Dhcpv6 pool definuje dns apod pro dhcpv6 klienty.
A ted zajimave chovani android vs windows 10 - v obou pripadech maji zarizeni pouze ipv6 adresaci (windows dhcpv6, android slaac), route, dns...vse nastaveno
- windows 10 -> play.google.com = zobrazena stranka
- android -> play.google.com = no internet connection (pritom google maps, google mail atd atd funguji, pingy na public dns, preklady, vse funguje)
Nejake napady, nez vytahnu fyzicky wireshark, nebot spojeni jinak nezobrazim
245
Server / Re:Viac ako jeden web server za verejnou IP
« kdy: 19. 03. 2021, 14:11:37 »Nejak sa to tu zvrhlo.
Zatial sa mi podarilo nastavit haproxy na pfsense a zda sa, ze to celkom funguje. Takze aspon nemusim pouzivat exoticke porty. A ani neviem ci by certbot fungoval na inom ako standardnom porte
Nefungoval. Pri http overovani overuje textovy retezec na http(s)://, takze ocekava port 80(443)...
246
Sítě / Re:Zkušenosti s více IP na serveru
« kdy: 19. 03. 2021, 11:18:32 »Ne, zcela to nikdo nepochopil. Nejde o nejake legacy-based migrace (ano, castecne to vychazi z toho).Ale pochopili. Naopak vy jste nepochopil, jak to funguje.
Rekneme, ze mate webserver pro jeden typ aplikace. Ta aplikace je tam duplikovana mnohonasobne, s tim, ze kazda kopie ma vlastni fqdn. Nektere aplikace jsou pristupne na pres fqdn na interni ipv4, nektere jsou pristupne na verejne ipv4.
Ted na to nasadite ipv6. Vsechny aplikace nyni maji verejnou ipv6. Kdyz na firewallu povolim pristup na ipv6 serveru, tak tim umoznim pristup na vsechny aplikace (napr. curl https://b.internal.domain.tld --resolve-host="ipv6:443"), i kdyz interni domeny nejsou ve verejnem dns (ale muzou leaknout).
Máte různé IP adresy a různé domény. Buď máte webový server nastavený tak, že všechny domény jsou dostupné na všech IP adresách – pak se lze přes veřejnou IP adresu dostat i na privátní doménu. Nebo máte správně přiřazené interní domény jenom k interním IP adresám. Pak se přes veřejnou IP adresu k interní doméně nedostanete, protože server na veřejné IP adrese odpoví, že danou doménu nezná.
Jestli je to IPv4 nebo IPv6, na tom vůbec nezáleží. Jediný rozdíl je v tom, že v IPv4 je ta interní IPv4 adresa z interního rozsahu, takže to na ní vidíte na první pohled. Naproti tomu s IPv6 sit u „interní“ IPv6 vyrobíte tak, že k ní zakážete na firewallu přístup z internetu.
Až to budete hledat v dokumentaci webového serveru, hledejte IP based virtual host vs. name based virtual host. Dokumentace pro Apache: Apache Virtual Host documentation, u nginx začněte třeba u Server names a spojíte to s tím, že u listen můžete uvést i IP adresu/adresy.
Krucinal, ja neresim spojeni navazovane smerem na server. Ja resim spojeni navazovane ze serveru.
247
Server / Re:Viac ako jeden web server za verejnou IP
« kdy: 19. 03. 2021, 08:24:36 »
Drive to melo smysl - na 443 byl jen https, dnes je to bordel - dnes tam muze byt i ssh.
Kazdopadne jeden vliv je i sniffovani provozu - zkuste hledat problem pres vsechny porty vs port pro dany typ sluzby. Nemluve o standarizaci - kdyby si kazdy vymyslel port pro https, tak by za chvili odchozi firewally ztratily smysl.
Kazdopadne jeden vliv je i sniffovani provozu - zkuste hledat problem pres vsechny porty vs port pro dany typ sluzby. Nemluve o standarizaci - kdyby si kazdy vymyslel port pro https, tak by za chvili odchozi firewally ztratily smysl.
248
Sítě / Re:Zkušenosti s více IP na serveru
« kdy: 19. 03. 2021, 08:14:30 »Ja to asi chápu. Jde o replikaci legacy schématu server s veřejnou IP v DMZ a nějakou privátní adresou v nějaké sítí za firewallem, split-horizon DNS, atd.
A vlastně tady při konfiguraci s jen jedním interface je všechno jinak.
@czechsys: je to tak?
Vubec. Na tom serveru jsou vsechny ipv4 lokalni. Ale je to za proxy serverem. A kdyz se zbavim proxy serveru a nasadim na to jednu verejnou ipv6 (a presunu do dmz misto te proxy), tak vlastne vsechny aplikace budou pristupne pres tu verejnou ipv6, coz neni v pripade internich aplikaci zadouci. Jo, oddeleni internich do vlastniho serveru je sice reseni, ale taky tak trochu plytvani prostredky...
249
Server / Re:DNS v DMZ?
« kdy: 19. 03. 2021, 08:08:20 »
Interni zony muzou byt klidne i v public dns.
Pokud k nim nechcete dat pristup, tak proste nastavte acl tak, aby interni domeny/subnety mohly rezolvovat pouze definovane subnety.
Pokud k nim nechcete dat pristup, tak proste nastavte acl tak, aby interni domeny/subnety mohly rezolvovat pouze definovane subnety.
250
Sítě / Re:Zkušenosti s více IP na serveru
« kdy: 19. 03. 2021, 08:06:04 »
Ne, zcela to nikdo nepochopil. Nejde o nejake legacy-based migrace (ano, castecne to vychazi z toho).
Rekneme, ze mate webserver pro jeden typ aplikace. Ta aplikace je tam duplikovana mnohonasobne, s tim, ze kazda kopie ma vlastni fqdn. Nektere aplikace jsou pristupne na pres fqdn na interni ipv4, nektere jsou pristupne na verejne ipv4.
Ted na to nasadite ipv6. Vsechny aplikace nyni maji verejnou ipv6. Kdyz na firewallu povolim pristup na ipv6 serveru, tak tim umoznim pristup na vsechny aplikace (napr. curl https://b.internal.domain.tld --resolve-host="ipv6:443"), i kdyz interni domeny nejsou ve verejnem dns (ale muzou leaknout).
Nyni dam na kazdou fqdn vlastni ipv6, server tedy bude sam o sobe vlastnit celou /64. Na firewallu muzu ridit pristup per fqdn (misto per server). Spojeni inicovane smerem na server netreba resit. Spojeni iniciovane serverem ale resi problem, co vlastne bude zdrojova ipv6. Bude to ipv6 serveru? Bude to ipv6 nektere nahodne z fqdn? Na tom jednom interface muzou byt desitky ipv6 ze stejne /64.
Zakaznikovi se rekne, ze ma na api pristupovat na a.domain.tld. Ale pokud budeme z toho sameho serveru pristupovat k zakaznikovi my (spusti se php cronem), tak v ramci jeho projektu to muze byt defacto kterakoli ipv6 z toho /64, nejen primo ta a.domain.tld.
Policy Based Routing tohle castecne resi, ale neresi zcela ten cron pristup. Jak to pozna, ze to do sveta ma jit prave tou specifickou fqdn adresou pro a.domain.tld?
Rekneme, ze mate webserver pro jeden typ aplikace. Ta aplikace je tam duplikovana mnohonasobne, s tim, ze kazda kopie ma vlastni fqdn. Nektere aplikace jsou pristupne na pres fqdn na interni ipv4, nektere jsou pristupne na verejne ipv4.
Ted na to nasadite ipv6. Vsechny aplikace nyni maji verejnou ipv6. Kdyz na firewallu povolim pristup na ipv6 serveru, tak tim umoznim pristup na vsechny aplikace (napr. curl https://b.internal.domain.tld --resolve-host="ipv6:443"), i kdyz interni domeny nejsou ve verejnem dns (ale muzou leaknout).
Nyni dam na kazdou fqdn vlastni ipv6, server tedy bude sam o sobe vlastnit celou /64. Na firewallu muzu ridit pristup per fqdn (misto per server). Spojeni inicovane smerem na server netreba resit. Spojeni iniciovane serverem ale resi problem, co vlastne bude zdrojova ipv6. Bude to ipv6 serveru? Bude to ipv6 nektere nahodne z fqdn? Na tom jednom interface muzou byt desitky ipv6 ze stejne /64.
Zakaznikovi se rekne, ze ma na api pristupovat na a.domain.tld. Ale pokud budeme z toho sameho serveru pristupovat k zakaznikovi my (spusti se php cronem), tak v ramci jeho projektu to muze byt defacto kterakoli ipv6 z toho /64, nejen primo ta a.domain.tld.
Policy Based Routing tohle castecne resi, ale neresi zcela ten cron pristup. Jak to pozna, ze to do sveta ma jit prave tou specifickou fqdn adresou pro a.domain.tld?
251
Server / Re:.htaccess špatný redirect při vynuceném HTTPS
« kdy: 19. 03. 2021, 07:52:05 »
A proc ten redirect resite na urovni htaccess a nenastavite to primo v konfiguraci virtualhosta?
252
Sítě / Re:Zkušenosti s více IP na serveru
« kdy: 18. 03. 2021, 15:51:44 »
Teorii znam, spis me zajimaji poznatky z praxe (napr. Hetzner udajne dava /64 per VM).
Mam tu realny priklad - na webserveru jsou domeny verejne i interni. V pripade ipv4 to resi nastaveni listen na public ci rfc1918 ipv4. V pripade ipv6, kdy pouzivam zasadne GUA, uz mi obecny pristup na IP adresu ve firewallu nestaci - i kdyz v public dns interni preklad neni uveden, tak staci poslat request na ipv6 s nastavenou interni domenou a firewall by to pustil. Pred webserverem je momentalne proxy, takze to pokryvaji acl. Ale uvazoval jsem o zruseni te proxy a v tom okamziku se to riziko "spoofnuti" domeny objevi.
Mam tu realny priklad - na webserveru jsou domeny verejne i interni. V pripade ipv4 to resi nastaveni listen na public ci rfc1918 ipv4. V pripade ipv6, kdy pouzivam zasadne GUA, uz mi obecny pristup na IP adresu ve firewallu nestaci - i kdyz v public dns interni preklad neni uveden, tak staci poslat request na ipv6 s nastavenou interni domenou a firewall by to pustil. Pred webserverem je momentalne proxy, takze to pokryvaji acl. Ale uvazoval jsem o zruseni te proxy a v tom okamziku se to riziko "spoofnuti" domeny objevi.
253
Sítě / Zkušenosti s více IP na serveru
« kdy: 18. 03. 2021, 14:17:09 »
Ahoj,
opakovane narazim na problem soubehu vice IP v ramci jednoho serveru (napr. IP per domena na nginx). Pro prichozi spojeni neni co resit. Ale pro vytvoreni odchoziho spojeni a jeste z hlediska firewallu...
Teoreticky priklad s ipv6 /64 dedikovanou na server - odchozi spojeni muze pouzit libovolnou ip z defaultni routy (pripadne vliv metriky na vice rout).
gateway ::a:1
server ::a:2/64
a.domain.tld ::a:3/64
b.domain.tld ::a:4/64
Pro odchozi se tedy pouzije :2 ci :3 ci :4 (firewall - kazda ip musi byt povolena vsemi potrebnymi smery, popr. cela /64). Pokud v default route nastavim zdrojovou ip :2, tak prichozi budou chodit na :3 ci :4, ale odchozi bude :2 (skoro ideal pro firewall - 1 ip). No jo, ale pak nekdo bude narazet na to, ze sluzba ve firewallu bude mit odchozim smerem :2, v prichozim smeru :3 (:4)...
Nejake zkusenosti z praxe?
opakovane narazim na problem soubehu vice IP v ramci jednoho serveru (napr. IP per domena na nginx). Pro prichozi spojeni neni co resit. Ale pro vytvoreni odchoziho spojeni a jeste z hlediska firewallu...
Teoreticky priklad s ipv6 /64 dedikovanou na server - odchozi spojeni muze pouzit libovolnou ip z defaultni routy (pripadne vliv metriky na vice rout).
gateway ::a:1
server ::a:2/64
a.domain.tld ::a:3/64
b.domain.tld ::a:4/64
Pro odchozi se tedy pouzije :2 ci :3 ci :4 (firewall - kazda ip musi byt povolena vsemi potrebnymi smery, popr. cela /64). Pokud v default route nastavim zdrojovou ip :2, tak prichozi budou chodit na :3 ci :4, ale odchozi bude :2 (skoro ideal pro firewall - 1 ip). No jo, ale pak nekdo bude narazet na to, ze sluzba ve firewallu bude mit odchozim smerem :2, v prichozim smeru :3 (:4)...
Nejake zkusenosti z praxe?
254
Sítě / Re:VoIP nasazení v menší firmě
« kdy: 18. 03. 2021, 09:15:07 »Toto jsem řešil v naší firmě před pár lety:
1) Firemní switche zůstaly klasické, bez PoE. Používám switch z telefonu do PC, tam, kde jsou "klasické" pevné linky. Pak máme ještě Gigasety, které mají základnu a k ní se připojují bezdrátové "handsety". Tam je základna připojena zvlášť, jelikož nemá svůj interní switch.
2) Oddělenou VLAN jsem zvažoval, ale nakonec nepoužívám, není důvod (ale telefony umí nastavit taging).
3) Viz 1). S PoE bych se nezatěžoval. Stejně u uživatele vždy bude el. zásuvka.
1] Pokud lze PoE, je to lepsi, min kabelu na stolech. A switche s PeE nestoji dardu ve srovnani s nonPoE
2] Oddelena vlan ma vyhodu v tom, ze se tam da nastavit prioritizace a castecne oddelit provoz od standardniho provozu klientu
255
Server / Re:Viac ako jeden web server za verejnou IP
« kdy: 18. 03. 2021, 09:10:40 »Jen taková drobná poznámečka:
Kdyby se na implementaci hošani od webových prohlížečů nevys*ali, bývalo se to dalo řešit uvedením portů v záznamech SRV DNS.
No, už se vaří lepší náhrada s avizovanou podporou významnějších prohlížečů (Chrom*, Firefox, Apple): https://tools.ietf.org/id/draft-ietf-dnsop-svcb-https-02.html
To je hezky, a jak si s tim poradi firewally?
