IPv6 - správa vlastní podsítě

10. 4. 2008 | Pavel Šimerda | Sítě | 11607×

Pokud jste se prokousali prvními dvěma díly a zajistili si IPv6 konektivitu, máte stroj s IPv6 adresou. Nastal čas si pořídit a nakonfigurovat podsíť (subnet).

Podle toho, jak jste se připojili k IPv6, zkuste získat od poskytovatele podsíť, pokud ji ještě nemáte. Používáte-li 6to4, získáváte ji automaticky. Pokud máte SixXS tunel, nechte ho běžet, dokud nemáte dostatek bodů na žádost o subnet.

Vaše podsíť by měla při troše štěstí mít prefix délky 48 bitů. Dalších 16 bitů je vám k dispozici pro rozdělení na více lokálních podsítí a pořád vám ještě zbude 64 bitů na identifikaci počítačů a ostatních síťových uzlů.

Rozdělování podsítě

Když je na váš router směrována podsíť, je čas dostat na Internet ostatní počítače. K tomu je potřeba nastavit IP adresu rozhraní routeru pro vnitřní síť a pustit démona, který bude do sítě posílat Router Advertisements. Ty umožní automatickou konfiguraci klientů.

Máme prefix xxxx:xxxx:xxxx::/48 a dáváme síťovému zařízení routeru adresu xxxx:xxxx:xxxx:1::1 (neboli xxxx:xxxx:xxxx:0001:0000:0000:0000:0001). Protože je to už koncová podsíť, kde budeme používat autokonfiguraci, dáme ji délku prefixu 64. Pokud máte více síťových rozhraní, můžete to udělat na každém (změníte první jedničku, která identifikuje vaši /64 podsít).

Záměrně vynechávám konfiguraci rozhraní do Internetu (například eth0 na Linuxu a ether5 na RouterOS) a výchozí brány. Pokud nemáte na vašem routeru připravenou IPv6 konektivitu, měl by vám pomoci předchozí díl.

Ruční konfigurace Linuxu by vypadala takto:

# ip address add xxxx:xxxx:xxxx:1::1 dev eth1
# ip link set eth1 up
# ip address add xxxx:xxxx:xxxx:2::1 dev eth2
# ip link set eth2 up

Na Gentoo přidáte adresy do souboru /etc/conf.d/net. Můžete nastavovat IPv6 adresy společně s IPv4. Nezapomeňte na příslušné symlinky v /etc/init.d. Rozhraní do Internetu je eth0.

config_eth1=(
    "192.168.1.1/24"
    "xxxx:xxxx:xxxx:1::1/64"
)
config_eth2=(
    "192.168.2.1/24"
    "xxxx:xxxx:xxxx:2::1/64"
)

Na Debianu to bude /etc/network/interfaces.

auto eth1
iface eth1 inet static
        address 192.168.1.1
        netmask 255.255.255.0
iface eth1 inet6 static
        address xxxx:xxxx:xxxx:1::1
        netmask 64
auto eth2
iface eth2 inet static
        address 192.168.2.1
        netmask 255.255.255.0
iface eth2 inet6 static
        address xxxx:xxxx:xxxx:2::1
        netmask 64

Mikrotik RouterOS se konfiguruje velmi podobně. Aby nám hezky vycházela čísla, budeme mít rozhraní do světa třeba na ether5.

> /ipv6 address add interface=ether1 address=xxxx:xxxx:xxxx:1::1/64 advertise=yes
> /interface enable ether1
> /ipv6 address add interface=ether2 address=xxxx:xxxx:xxxx:2::1/64 advertise=yes
> /interface enable ether2

Zatím ještě nikdo neřekne počítačům na síti o našem routeru (Router Advertisements), kromě RouterOS, kde to zajistí parametr advertise=yes. Nainstalujte si proto program radvd a upravte /etc/radvd.conf.

interface eth1 {
        AdvSendAdvert on;
        prefix xxxx:xxxx:xxxx:1::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
};
interface eth2 {
        AdvSendAdvert on;
        prefix xxxx:xxxx:xxxx:2::/64 { 
                AdvOnLink on; 
                AdvAutonomous on; 
                AdvRouterAddr on; 
        };
};

Nastavili jsme posílání RA (AdvSentAdvert) pro dvě rozhraní a nastavili jsme každému jeden /64 prefix. Router oznámí počítačům svoji adresu (používá se link-local adresa jeho síťového rozhraní pro daný segment). Navíc jim řekne, že počítače se stejným prefixem jsou na stejném segmentu (AdvOnLink) a že adresu si můžou zvolit samy (AdvAutonomous).

Takovéto jednoduché nastavení na hraní si s IPv6 postačí, v manuálové stránce najdete další volby, včetně například MTU, směrování, DNS serverů, Mobile IPv6 a dalších. DNS volba je experimentální a radvd ji podporuje od verze 1.0. Pokud Router Advertisements z nějakého důvodu nevyhovují nebo nestačí, můžete použít protokol DHCPv6. Oba způsoby se dají s úspěchem kombinovat.

Bezstavová automatická konfigurace

Jak jste již poznali, IP adresy se dají konfigurovat ručně, pomocí protokolu DHCP(v6) nebo (v IPv6 nově) pomocí bezstavové automatické konfigurace (RFC 4862). Každá z možností má své použití. Počítač, který automaticky konfiguruje své síťové zařízení, může poslat žádost (Router Solicitation) na k tomu určenou multicast adresu (all-routers). Router posílá pravidelně i na žádost již zmíněné Router Advertisements. Koncový počítač mezi informacemi dostane /64 prefix, druhou část adresy si nastaví sám. Obvyklou metodou je odvození z EUI-64 identifikátoru (MAC adresa doplněná na 64 bitů).

Pro ty, kdo chtějí své soukromí chránit více a nechtějí prozrazovat světu svoji MAC adresu, jsou tu Privacy Extensions (RFC 3041). Pomocí náhodných čísel a pravidelných změn IP adres zabrání sledování počítače při pohybu mezi sítěmi. Rovněž znemožní zjišťování počtu počítačů v síti a jejich jednoznačnou identifikaci.

U klienta by mělo stačit povolit rozhraní a na něm IPv6 autokonfiguraci. Na Linuxu obvykle stačí mít v jádře podporu IPv6 a povolit zařízení:

# ip link set eth0 up

Pokud navíc chcete používat privacy extensions, zapněte je ještě předtím pomocí sysctl:

# sysctl net.ipv6.conf.eth0.use_tempaddr=2

Linkové a lokální adresy

IPv4 i IPv6 mají speciální automaticky konfigurované adresy pro komunikaci v rámci spoje nazývané link-local addresses (169.254.0.0/16 a fe80::/64). Většina IPv4 implementací tyto adresy zaváděla jen jako poslední možnost, když vše ostatní selže. IPv6 každému zařízení jednu takovou adresu přidělí. Druhá polovina adresy se opět řídí MAC adresou zařízení (tentokrát nejsou žádné privacy extensions potřeba).

Rovněž jsme zvyklí používat privátní rozsahy adres, většinou ke zprostředkování lokální komunikace a k překládání na společnou veřejnou adresu a port. Komunikaci po místním segmentu zajišťují všudypřítomné link-local adresy a pro vnější svět máme dostatek globálních adres. Pokud přesto chceme takový rozsah používat, máme možnost si vytvořit vlastní lokální /48 prefix podle RFC 4193, Unique Local IPv6 Unicast Addresses. Ten pak začíná binárně 11111101 (FD00::/8), pokračuje 40 náhodnými bity, které mají (s velkou pravděpodobností) zajistit unikátnost. Opět nám zbývá 16 bitů na podsítě a 64 bitů na identifikaci koncových počítačů. Těmto adresám se říká lokální kvůli tomu, že nejsou směrovány do Internetu. Na druhou stranu se dají pro účely privátních sítí považovat za unikátní. Tím pádem odpadají problémy při propojování těchto sítí a používání VPN a tunelů mezi nimi. Pravděpodobnost kolizí je při takovémto použití mizivá.

Jestliže ve své síti používáte lokální adresy, neměli byste je routovat mimo vaši síť a případné další sítě, se kterými jste ji propojili. Jak již bylo zmíněno v diskuzi k předchozímu dílu, v současném schématu IPv6 adres platí, že všechny adresy, u kterých není řečeno jinak, jsou globálně směrované. Ve skutečnosti není rozsah pro lokální adresy FD00::/8, ale FC00::/7. To proto, že FC00::/8 je rezervovaný pro případný další mechanismus volby síťového prefixu (všimněte si, že FC00::/8 a FD00::/8 dávají dohromady FC00::/7).

Nastavení DNS serverů a záznamů

IPv6 síť už je připravená, ale možná vám chybí doménová jména. Pravděpodobně máte nějakou doménu a k ní i DNS službu, ale nejspíš vám nebudou chtít poskytovat reverzní překlad. Může být výhodné používat stejné servery na oba směry překladu, na některých serverech se vytvoří reverzní záznamy automaticky. Pokud nemáte vlastní DNS servery, poohlédněte se po nějaké službě dostupné na Internetu (z těch bezplatných například editdns.net nebo xname.org). V každém případě je potřeba udržovat správně nastavené seznamy DNS serverů u poskytovatele IPv6 podsítě i poskytovatele domény. V případě SixXS tunelů můžete přidávat nameservery v jejich webovém rozhraní (pozor, přidání nebo smazání DNS stojí bod, tak neupravujte moc divoce).

6to4 a reverzní DNS

I na 6to4 je možné upravovat seznam nameserverů pro reverzní záznamy. Slouží k tomu webové rozhraní 6to4.nro.net, které vám umožní nastavit reverzní DNS z adresy vašeho 6to4 rozsahu. Kromě toho můžete nastavit heslo, které vám dovolí provádět nastavení i z jiné adresy. Služba je v testovacím provozu; přečtěte si informace o službě, než se do toho pustíte. Nastavit delegování je možné z libovolné adresy, neautorizovaným změnám můžete zamezit firewallem.

Linux:

# ip6tables -A forward -d 6to4.nro.net -j REJECT \
 --reject-with=adm-prohibited

RouterOS:

> /ipv6 firewall filter add chain=forward dst-address=FC00::/7 \
 action=reject reject-with=icmp-admin-prohibited

Toto pravidlo zajistí, že počítače z místní sítě nemají ke službě vůbec přístup. Není to úplně hezké řešení, ale funguje. Nastavovat pak musíte buď přímo z routeru (aspoň na Linuxu to není problém) nebo specificky povolit některou z místních IP.

DNS záznamy

Adresy se definují pomocí AAAA záznamů. Upravte zónový soubor domény.

orange.example.net. 86400 IN AAAA xxxx:xxxx:xxxx:1:iiii:iiii:iiii:iiii
apple.example.net.  86400 IN AAAA xxxx:xxxx:xxxx:1:jjjj:jjjj:jjjj:jjjj
carrot.example.net. 86400 IN AAAA xxxx:xxxx:xxxx:2:kkkk:kkkk:kkkk:kkkk

Přidáme si ještě pár serverů s hezkými staticky nastavenými adresami z rozsahu xxxx:xxxx:xxxx::/64 (xxxx:xxxx:xxxx:0000::/64).

mouse.example.net.  86400 IN AAAA xxxx:xxxx:xxxx::2
cat.example.net.    86400 IN AAAA xxxx:xxxx:xxxx::3
turtle.example.net. 86400 IN AAAA xxxx:xxxx:xxxx::4

A nakonec nastavíme reverzní DNS záznamy (každý A/AAAA záznam má mít odpovídající PTR záznam). Na rozdíl od IPv4, kde se staví adresy po bajtech, dělíme zóny po jednotlivých šestnáctkových číslicích. Číslice píšeme pozpátku (stejně jako bajty v IPv4). Pokud nemáte reverzní záznamy vytvořené automaticky, upravte zónový soubor pro váš prefix.

i.i.i.i.i.i.i.i.i.i.i.i.i.i.i.i.1.0.0.0.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa. 86400 IN PTR orange.example.net.
j.j.j.j.j.j.j.j.j.j.j.j.j.j.j.j.1.0.0.0.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa. 86400 IN PTR apple.example.net.
k.k.k.k.k.k.k.k.k.k.k.k.k.k.k.k.2.0.0.0.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa. 86400 IN PTR carrot.example.net.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa. 86400 IN PTR mouse.example.net.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa. 86400 IN PTR cat.example.net.
4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa. 86400 IN PTR turtle.example.net.

Závěrem

Tímto dílem jsme uzavřeli naši síťovou konfiguraci. Těším se na vaše připomínky, opravy a náměty pro případné další články.

       

Komentáře

[zde]

Reverzní AAAA-čka jsou ještě větší hnus než zbytek fau-sexu. :/

[xm]

Heh, a to jako proč? Jdi se bodnout :-P Hnus je stará IPv4

[Michal Kubeček]

Naopak, líbí se mi, že je tam granularita po čtyřech bitech, takže se dá očekávat mnohem méně problémů obdobných těm, které nastaly u IPv4 po zavedení beztřídních delegací, a nutnosti krkolomných workaroundů typu RFC 2317.

[l.]

Tenhle ten "workaround" vznikl protoze dns - jako logicka nadstavba nad IP - a ne kvuli samotne IPv4. IPv4 - classless+VLMS tzn adresa rozsirena o masku libovolne delky je pomerne elegantni a flefibilni reseni. DNS je ten pruser. Taky co byste chteli, kdyz cela myslenka je zalozena za "distribuovanych" seznamech, popisujice relaci mezi classful adresou (rozumej svazanou prisnymi pravidly) a "libovolnym" jmenem.

BTW veci kolem prekladu jmen a "kompletni kompatibilita nezi dns/ipv4/dns6/ipv6" jsou duvod, proc nejde ipv6 naimplementovat plosne a "ihned".

[pavlix]

BTW veci kolem prekladu jmen a "kompletni kompatibilita nezi dns/ipv4/dns6/ipv6" jsou duvod, proc nejde ipv6 naimplementovat plosne a "ihned".

Můžu poprosit o trochu víc detailů?

[Michal Kubeček]

Ten workaround vznikl proto, že model řešení reverzního lookupu byl navržen ještě před příchodem CIDR a s prefixy nedělitelnými osmi nepočítal. Kdyby se s tím počítalo předem, šlo by to navrhnout o něco elegantněji.

[Kroko]

njn, když autor nevyužívá výhod prefixů tak je to pak opravdu hnus to takto rozepisovat

[pavlix]

Autor píše záznamy tak, jak ve skutečnosti jsou.

Kdyby je psal zkráceně (o prefix), musel by ještě vysvětlovat rozdíl mezi konfiguračním souborem a skutečnými záznamy a to považoval za zbytečnou komplikaci.

[pavlix]

Reverzní A v IPv4 se obvykle řeší tak, že i když máš rozsah, nemáš vlastní nameserver, ale říkáš si upstream providerovi o každou změnu (pokud se jedná o malý rozsah, což se v případě IPv4 často jedná).

Větší granularita je v případě IPv6 jenom výhodou.

Na druhou stranu bych očekával, že použiješ stejný primární nameserver pro oba směry a necháš nameserver, ať se postará o reverzní směr sám.

[Ondrej 'SanTiago' Zajicek]

Reverzní A v IPv4 se obvykle řeší tak, že i když máš rozsah, nemáš vlastní nameserver, ale říkáš si upstream providerovi o každou změnu

Standardni reseni je to, ze provider (nebo ten, kdo ma nadrazeny /24 rozsah) zridi v rozsahy poddomenu a pro vsechna reverzni jmena v udela CNAME do dane poddomeny. Poddomena se pak deleguje na tvuj DNS server. Viz RFC 2317

[pavlix]

Jde o to jestli slovem standardní myslíš *běžné* nebo *podle RFC*. To je velký rozdíl.

[Ondrej 'SanTiago' Zajicek]

No nevim, my mame konektivitu od dvou poskytovatelu a u oba na nas deleguji reverzni DNS podle daneho RFC.

[pavlix]

Fajn, tak to už máme dva :).

[Ondrej 'SanTiago' Zajicek]

A ty vis o nejakych ISP, kteri to tak nedelaji?

[pavlix]

Tak minimálně pro náš server si říkáme o nastavení reverzů jednotlivě, tak tiše předpokládám, že to nedelegují, jinak by se mě už Michal ptal, jestli nepojedem na vlastích DNS serverech. Ale možná je to jenom okrajový problém.

[zde]

Docela standarní taky je, že se na reverzy kašle a nejsou vůbec- k čemu taky .-)

[pavlix]

Třeba k tomu, aby tvůj mailserver dokázal například doručit mail na abclinuxu.cz :D.

[Filip Jirsák]

K čemu potřebuje poštovní server vědět jméno počítače, který mu chce předat e-mail?

[pavlix]

Tak to zkus :D.

[Filip Jirsák]

Z pouhého pokusu nezjistím, k čemu je to dobré. Žádný poštovní server, který jsem kdy konfiguroval, ne potřeboval nikdy vědět jméno počítače, od kterého přijímal e-mail. Napadá mne jediný způsob použití jména odesílajícího počítače – „obrana“ proti spamu (postavená na myšlence, že když zahodím dostatečné množství libovolných e-mailů, mezi zahozenými e-maily bude s jistou pravděpodobností i nějaký spam).

[alkoholik]

Ta "obrana" samozrejme funguje. Hlavne, kdyz nekdo mail server bez reversu napraska spamcopu. Dokonce jsme byli blacklistovani, kdyz kvuli natu na routeru nesedel s heloname. Zakaznici jedine oceni, kdyz se budete obtezovat reversem. Usetri to problemy v budoucnosti.

[Filip Jirsák]

Ta "obrana" samozrejme funguje.

Jistěže funguje – způsobem, který jsem popsal v závorce.

[pavlix]

Může se ti to líbit nebo nelíbit, ale používá se to a je to velmi efektivní, společně s dalšími podobnýmy způsoby, které nevyžadují filtrování pošty.

[Filip Jirsák]

Efektivitu by bylo možné zjistit jedině tak, že by se přijaly všechny e-maily, pouze by se označkovaly. Pak by se zjišťovalo, jaká byla korelace mezi označkováním a spamem. Jinak víte akorát to, že se něco nepřijme.

Navíc když takhle e-maily zahazuje jen primární SMTP server, a záložní takový e-mail klidně přijmou, je to spíš pravý opak efektivity – když se vám někdo bude pokoušet poslat normální e-mail, zkusí nejprve primární SMTP server, tam bude kódem 4xx odmítnut a bude to zkoušet opakovaně, ale e-mail stejně neodešle. Zatímco spammer se s primárním serverem nebude obtěžovat, pošle to rovnou na záložní a ten e-mail přijme a přepošle. Jako metoda, jak e-maily roztřídit na spam a ham je to jistě zajímavé, akorát se obávám, že většinou bývá snahou spam zahodit a ham doručit, ne přesně opačně.

[pavlix]

Navíc když takhle e-maily zahazuje jen primární SMTP server,

Tak je admin pako, na to se nedá nic jinýho říct.

Pokud někdo neumí nastavit mailservery, tak je to jeho problém. A zvlášť blbě nastavenej backup mailserver je mnohem horší než žádnej.

[Filip Jirsák]

Pokud někdo neumí nastavit mailservery, tak je to jeho problém.

Právě že ne. Když někdo neumí nastavit mailservery, je to problém hlavně všech okolo. Dotyčný admin je zpravidla jediný, kdo je v klidu, protože o nedoručených e-mailech neví, a že jeho server rozesílá spam (jiný případ špatné konfigurace) ho netrápí. Já osobně považuji za špatné nastavení mailserveru i to, pokud se z existence či tvaru reverzního záznamu IP adresy jeho protějšku pokouší něco uhodnout. Většina spamu pochází z počítačů, které reverzní záznam mají.

[pavlix]

Většina spamu pochází z počítačů, které reverzní záznam mají.

Na mailserverech, které se nebaví se strojema bez reverzů určitě.

Ale jinak bys musel tohle tvrzení nečím podložit, podle mě nemáš obecně pravdu.

Já jsem většinu spamů odfiltroval na základě špatného chování při SMTP komunikaci.

Já osobně považuji za špatné nastavení mailserveru i to, pokud se z existence či tvaru reverzního záznamu IP adresy jeho protějšku pokouší něco uhodnout.

To já taky, já radši, když nic nehádá a prostě všecky, co se nechovaj rozumně pošle do háje. Oni si to velmi rychle opraví a když ne, jejich smůla, každopádně nemůžou předstírat, že si toho nevšimli.

[Filip Jirsák]

Ale jinak bys musel tohle tvrzení nečím podložit, podle mě nemáš obecně pravdu.

grep 'client=unknown' /var/log/mail/* | wc -l 
grep 'client=' /var/log/mail/* | wc -l 

a obě čísla podělit. Na jednom serveru jsem napočítal ani ne 40 % bez reverzu. Test, kterým mi projde více jak 60 % spamu a nijak neovlivní další testy, který ale bez varování může likvidovat i ham, ten nepotřebuju.

Oni si to velmi rychle opraví a když ne, jejich smůla, každopádně nemůžou předstírat, že si toho nevšimli.

Co by si opravovali? A proč by si toho museli všimnout? Myslíte si, že budu pokaždé pátrat po tom, zda můj e-mail došel? Většinou pokud není na e-mail adekvátní reakce, není problém obrátit se někam jinam, kde na e-mail zareagují.

[Pihhan]

Já mám pořád za to, že si nerozumíme. Tady nejde o to, jestli filtrace spojení z adres bez resolvu něco vyřeší, nebo nevyřeší. Tady jde úplně o jinou věc. Velmi časté je, že prostě od adres bez reverzů chodí samý spam. Pokud se mi server prohýbá pod náporem spamu, je řešení poměrně jednoduché, odříznout adresy bez reverzů, a chod se zrychlí. Dopustím se sice odmítnutí zadedbatelného množství zpráv, ale odmítnu velice rychle a na zdroje nenáročně.

Když tedy chcete čísla:

$ grep "SA: Action: temporarily rejected message:" rejectlog | grep "host=NULL" | wc -l
8
$ grep "SA: Action: temporarily rejected message:" rejectlog | wc -l
12
$ grep "SA: Action: permanently rejected message:" rejectlog | grep "host=NULL" | wc -l
57
$ grep "SA: Action: permanently rejected message:" rejectlog | wc -l
85

Jsme na malém serveru, kde neběží žádné komerční nasazení. Přesto v dnešním ani včerejším logu není jediný přijatý mail, který by byl doručen. Tedy přesněji každý den to byly 3. U všech třech se v logu píše:

SA: Action: flagged as Spam but accepted

Za celou historii logů nemám ani jeden přijatý mail bez reverzu. Jestli tohle vám nestačí, potom to asi umíte líp. Mě to stačí a dál to nepotřebuji řešit. Pokud uvažujete o reálném mailování, reverz prostě potřebujete.

[pavlix]

Hele, jaktože temporarily?

[Filip Jirsák]

Aby to bylo ještě více postavené na hlavu a ubíralo to zdrojů víc, než kdybyste ten e-mail přijal a označil jako spam. Jinak pokud tím nechcete eliminovat spam, ale jenom omezit provoz, můžete opravdu ukončovat třeba 40 % spojení náhodně, a efekt bude stejný.

[pavlix]

Tebe jsem se neptal, je mi jasný, že bych dostal jen další přihlouplou reakci.

[pavlix]

bez varování může likvidovat i ham

Likvidovat nemůže nic. A bez varování nemůže taky nic (nejen likvidovat).

[Filip Jirsák]

Adresátovi se e-mail nedoručí a nedozví se o tom, odesílatel se o tom zpravidla taky nedozví (a pokud mu o tom e-mail přijde, nerozumí mu – navíc mu přijde třeba až za týden). Můžete klidně říkat, že to není likvidace ani zahození, ale nedoručení – na podstatě věci to ale nic nemění.

[pavlix]

To co píšeš se stane jenom pokud je admin blbec a neumí to nastavit.

Vyměň admina :).

[pavlix]

Jinak... e-mail se nedoručí a odesílatel dostane okamžitě zprávu, že se e-mail nedoručil a s odůvodněním... zavolá adminovi a řekne mu, ať s tím něco udělá. Admin si najde někoho, kdo mu vysvětlí, jak se nastavuje e-mail a dns a opraví to.

[Filip Jirsák]

Pokud se e-mail nedoručí s chybou 4xx, nemusí odesílatel hned dostat žádnou zprávu. A pokud SMTP klient, který byl odmítnut, není přímo poštovní program odesílatele (např. pokud se budu řídit vaším doporučením použít SMTP relay ISP), nedostane chybovou zprávu nejspíš vůbec, protože chybové zprávy o nedoručeném e-mailu se dnes právě kvůli spamu a hlavně virům většinou neodesílají (protože by tím jen vznikal další spam). Taky máte trochu zvláštní představu o tom, co bude běžný uživatel dělat s případnou chybovou zprávou od SMTP serveru. Pokud to vyhodnotí jako skutečný e-mail (ne spam) a pochopí, že se má obrátit na admina, je to úspěch.

Navíc se celou dobu bavíme jenom o tom, jak moc odmítnutí takového e-mailu vadí, ale zatím jediný přínos, který tady někdo zmínil, je ušetření šířky pásma (které je navíc velmi diskutabilní a lze ho dosáhnout i jinými metodami). Já osobně tedy vidím ještě jeden přínos – omezování podle reverzního záznamu se na serverech děje ve vzácné shodě s kontrolou, jestli reverzní záznam není ošklivý, případně s antivirovou kontrolou, která o svých nálezech rozesílá spam na adresy zfalšovaných odesílatelů. A s takovými servery je lepší nekomunikovat…

[pavlix]

chybové zprávy o nedoručeném e-mailu se dnes právě kvůli spamu a hlavně virům většinou neodesílají

Chybové zprávy o nedoručení mailu se podle mě odesílají.

[Filip Jirsák]

Hm, moje věta „… se děje ve vzácné shodě s …“ evidentně padla na úrodnou půdu. Takže uživatel A má zavirovaný počítač, nějaký vir si vybere z jeho adresáře kontaktů náhodně uživatele B a na adresu C pošle sám sebe nebo nějaký spam s adresou odesílatele B (aby to vypadalo důvěryhodně, případně prošlo whitelisty založenými na e-mailových adresách odesílatele). Cílový server e-mail z nějakého důvodu odmítne a odešle zprávu o nedoručení e-mailu na adresu odesílatele – B. Takže B právě dostal další milý spam. Jenom si nejsem jistý, zda tohle bude účinná taktika proti spamerům. Obávám se, že je marné doufat, že se takhle vygeneruje spamu ještě daleko víc a spameři se půjdou do kouta stydět, jací jsou břídilové, a spamování nechají.

[pavlix]

Hm, moje věta „… se děje ve vzácné shodě s …“ evidentně padla na úrodnou půdu.

Evidentně vůbec.

Bavili jsme se o konfiguraci našeho mailserveru... a tento spam náš mailserver neodesílá ani nepřijímá, tudíš to není tak úplně náš problém.

[Filip Jirsák]

To je pak ale v rozporu s tvrzením, že se uživatel dozví o odmítnutí e-mailu. Protože jediný, kdo může uživatele o chybě informovat bez rozesílání takového druhu spamu je SMTP relay, který (přímo) používá uživatel. Každý další server už může jedině poslat e-mail se zprávou o chybě, ale zároveň nemá šanci zjistit, zda e-mail skutečně odeslal ten, za koho se e-mail vydává.

[Pihhan]

Právě proto mám například na mém serveru nastavení takové, že mailserver mail nepřijme od uživatele hned, ale antispamové prostředky použije ještě předtím, že uživateli potvrdí převzetí. Potom pokud zjistí, že se jedná o spam, vygeneruje do spammerem uskutečněného spojení chybový kód: Mail nebyl přijat, klasifikován jako spam. Tedy, pokud uživatel tento server použil jako svůj relay z klienta, klient obrdžel chybovou hlášku, aniž by se cokoliv odeslalo. Pokud nám to předává jiný mailserver, je zcela v jeho kompetenci s tímto mailem udělat, co uzná za vhodné. Je to také jeho problém, spam si přijal, ať si ho také nějak zpracuje. Pokud je to mailserver od ISP, vygeneruje uživateli hlášku. Ftip je v tom, že tento mailserver může vědět, kdo se přihlásil, jeho ověřovací údaje a poslat chybu na správné místo. Tedy pravděpodobně uloží do lokální schránky mail pro uživatele, že poslední zpráva nebyla doručena. Nebo to může ztopit, pokud neví, od koho to doopravdy přišlo. Pointa je v tom, že běžné spamy se připojují přímo na cílové servery a lejou přímým spojením SMTP email přímo adresátovi. Timto jsou tito regulérně odmítnuti, pokud se takto přímo připojuje člověk s programem, je mu vrácena ihned hláška, že mail nebyl odeslán.

[Filip Jirsák]

Tohle by fungovalo jedině v případě, že by uživatel ze svého poštovního klienta posílal e-mail přímo na váš server. Jakmile je mezi ním a vaším serverem alespoň jeden relay (což je téměř vždy), přestává to vaše řešení fungovat. Protože ten relay přijme e-mail a uloží jej do fronty. Teprve někdy později se jej pokusí z fronty odeslat a vy jej odmítnete. V tom okamžiku ten relay ale už dávno neví, kdo po něm to odeslání chtěl – leda že by si u každé zprávy ve frontě pamatoval i to, odkud se tam ten e-mail vzal. Znáte nějaký mail server, který si tyhle informace ve frontě ukládá? Tedy kromě obálkového odesílatele, což je ta informace, ovšem dnes na ní nelze spoléhat.

Ano, nakonfigurovat mailserver tak, že „když to ostatní budou mít udělané tak, jak chci, aby to měli, bude to nádherně fungovat“ je snadné. Ovšem nakonfigurovat mailserver tak, aby se vám ostatní přizpůsobovat nemuseli a stačilo se řídit RFC, to už je něco jiného.

[pavlix]

leda že by si u každé zprávy ve frontě pamatoval i to, odkud se tam ten e-mail vzal.

To si samozřejmě pamatuje. A nejen to, přidává tuto informaci do hlavičky mailu.

Tedy kromě obálkového odesílatele, což je ta informace

Což je úplně jiná informace, která s tím nemá nic společného.

[Filip Jirsák]

Jenže to není zaručená informace o tom, kde se ten e-mail vzal. To je informace, kterou o sobě řekne odesílatel a server ji (zpravidla) nijak nekontroluje. Takže když tam když tam vir nebo spammer napíše vaši adresu, budete chtít dostat e-mail o nedoručení od všech serverů, přes které se ten vir/spammer pokoušel něco odeslat?

[pavlix]

To jsi asi reagoval na někoho jinýho než na mě.

[pavlix]

Právě proto mám například na mém serveru nastavení takové, že mailserver mail nepřijme od uživatele hned, ale antispamové prostředky použije ještě předtím, že uživateli potvrdí převzetí.

Parse error.

[pavlix]

To je pak ale v rozporu s tvrzením, že se uživatel dozví o odmítnutí e-mailu.

Není.

[Filip Jirsák]

Někde mezi uživatelem a vaším serverem je nějaká fronta, kam se sypou e-maily. V té frontě je e-mail, čas, kdy se má e-mail znovu odeslat a počet neúspěšných pokusů o doručení e-mailu. K té frontě někdo přijde, vylosuje nějaký e-mail a pokusí se jej doručit na váš server – ten e-mail odmítne. Co může dotyčný „obsluhovač“ fronty udělat? Dát e-mail zpátky do fronty, nebo jej zahodit. Jedinou informaci o původním odesílateli, kterou má ten „obsluhovač“ fronty k dispozici je to, co odesílatel napsal do hlaviček e-mailu a obálky. A na to se nelze spoléhat, protože tam si odesílatel (vir) napíše, co ho napadne.

Takže byste musel u každého e-mailu ve frontě evidovat nějakého „zaručeného odesílatele“. Tedy ne u každého, ale alespoň u těch e-mailů, u kterých máte nějakou páku, jak to zjistit – takže třeba u e-mailů z vlastní sítě, pro které děláte relay. Tam můžete vyžadovat autorizaci. Jenomže vám nestačí nějaké autorizační údaje, vy potřebujete e-mailovou schránku. Takže třeba ISP by poskytnul relay svým zákazníkům s tím, že se budou přihlašovat jménem a heslem a do nějaké databáze toho ISP zapíšou ke svému jménu také e-mail, na který se mají doručovat zprávy o chybách. Takže uživatel Pepa Novák u svého ISP bude mít uvedeno, že chybové zprávy se mu mají posílat na e-mail novak@example.com. Pepa Novák bude odesílat přes relay svého ISP e-mail, přihlásí se jménem a heslem, server si ho najde v databázi a k e-mailu ve frontě poznamená, že pokud by došlo k chybě, má se chybová zpráva odeslat na novak@example.com. Při troše štěstí se bude relay ISP bavit přímo s cílovým serverem, ten e-mail odmítne hned během SMTP sezení, takže relay se podívá, kam má poslat chybovou hlášku a odešle jí. Teoreticky to bude v tomhle ideálním případě fungovat. Ale už jste někdy viděl takovéhle řešení použité v praxi?

[pavlix]

A na to se nelze spoléhat, protože tam si odesílatel (vir) napíše, co ho napadne.

Takže tebe trápí, že autor viru nedostane zprávu o nedoručení?

No to je mi líto...

[Filip Jirsák]

Opravdu jste tak naivní, že si myslíte, že do adresy odesílatele píše autor viru svou adresu? Nenapíše, vybere si náhodně nějakou adresu z kontaktů na počítači, kde vir zrovna operuje, a tu tam přidá. Takže to bude třeba vaše adresa. Opravdu chcete dostávat chybové zprávy o tom, že někdo, kdo vás má v kontaktech, má zavirovaný počítač?

[pavlix]

Opravdu jste tak naivní

Odpověz si sám.

Ad ostatní: to řešíš úplně jiný problém než o který šlo a než který se týká kontroly reverzních záznamů na cílovém serveru.

[Pihhan]

Ano, viděl. Protože obecně je to problém a problémy které popisujete existují, ale ideální řešení na ně ne, používá se zpravidla způsob, že se přihlásíte k svému providerovi emailové schránky a pomocí autorizace v SMTP potvrdíte, že to jste vy. Odpověď se prostě a jednoduše napíše do schránky uživatele, který se přihlašoval. Tu odesílající server ví, protože si ji obvykle sám přidá do hlaviček odesílaného mailu, takže až jej zpracovává, na tuhle informaci se spolehnout může, protože si ji přidal sám, pokud už tam byla, tak si ji zrušil/označil jako nedůvěryhodnou další hlavičkou. Většina ISP nabízí uživatelům i lokální email, potom na tento lokální email přijde chyba, ne na zpáteční adresu.

Zkrátka, server přebírající mail od uživatele údaje znát může, další servery v síti jsou obvykle cílového uživatele, takže pokud odmítne ten, mám adresu skutečného uživatele, kterému lokálně uložím chybovou zprávu. A relaye obvykle přeposílají jenom z důvěryhodné sítě, kde se předpokládá, že odtud podvržené maily nechodí. Aby nepřeposílaly spamy, mohou si přeposílané zprávy kontrolovat samy. Pokud to dělají s rozumnou účinností, šance, že mě odmítne druhý server se minimalizuje. Relay prostě odpovídá za to, že vadné maily odmítne sama a uživatel to tedy (opět) ví. To že server nepřeposílá bordel ale maily s důvěrohodnou zpáteční adresou zajišťuje správce nasazením filtrů a administrativním nařízením pro jeho síť. Potom systém jako celek funguje obstojně i bez černých děr pro uživatele. Samozřejmě v některých případech se přesto e-mail prostě ztratit může, ale s tím se hold už musí počítat.

[Filip Jirsák]

Pokud jde o nějakou firemní síť, pak relay může za odeslané e-maily zodpovídat a může odesílatelům rozumně doručovat chybové zprávy. Jenomže pavlix neustále doporučuje, že by se firemní relay raději neměl vůbec používat a měl by se používat relay ISP. A ten už nemá moc kontrolu nad tím, jestli přes jeho server nejde spam. Nějaká administrativní omezení si nemůže moc dovolit, protože by měl nějaká omezení, která konkurence nemá. Za druhé sice může doručovat chybové zprávy do schránky, kterou má zákazní u něj – ale kolik lidí takové schránky vybírá? Ano, zodpovědnost ISP za spam pocházející z jeho sítě je podmínka pro jeden ze způsobů, jak se spamem zatočit. Ale zatím to tak nefunguje. Těžko můžete předpokládat, že se zrovna vám v tomhle všichni přizpůsobí. Zvlášť když je tenhle typ boje proti spamu naprosto neúčinný. Vzhledem ke spoustě antispamových řešení si dnes konečný uživatel přečte promile spamu, který mu byl určen – a spammerům se to pořád vyplatí. Postavit jim do cesty filtr, který 60 % spamu propustí je k smíchu.

[pavlix]

Jenomže pavlix neustále doporučuje

Lžeš.

[Filip Jirsák]

Aha, tak to pardon. Takže každý má mít svůj vlastní relay server. Kvůli pavlixovi na něm navíc musí mít nějaký reverzní záznam (kvůli některým dalším dokonce „ne ošklivý“ reverzní záznam). To se zejména u dynamicky přidělovaných IP adres dobře realizuje.

[pavlix]

Aha, takže jednou jsem obviněn z toho, že zakazuju používat vlastní SMTP ve firmě, po druhé z toho, že zakazuju používat SMTP od ISP.

A že kvůli mě se používají reverzní záznamy na mailu :D. Teda já musím být slavný :).

Na dynamicky přidělovaný IP adrese nemá mailserver co dělat :D. Pokud chceš provozovat vlastní mailserver, je dobrý mít statickou adresu, MX záznam, A/AAAA záznam, reverzní záznam a dobře nakonfigurovaný mailserver. Nic z toho není problém sehnat.

[Filip Jirsák]

Pokud chceš provozovat vlastní mailserver, je dobrý mít statickou adresu, MX záznam, A/AAAA záznam, reverzní záznam a dobře nakonfigurovaný mailserver.

A hodinky s vodotryskem potřeba nejsou? K odeslání e-mailu není nic z vyjmenovaného potřeba. A nic z toho neodlišuje server rozesílající spam od serveru rozesílajícího normální poštu. Tak k čemu ty vaše dodatečné podmínky jsou?

[pavlix]

Asi jsi zaspal dobu, když si myslíš, že jsou to naše dodatečné podmínky.

Je milé, že chceš mě a Pihhanovi přiřknout vynalezení těchto věcí. Ale musím tě zklamat, náš vynález to není, je to běžný dnešní standard.

A až vynalezneš způsob, jak filtrovat spam bez heuristiky, dej mi určitě vědět :). Rád se přiučím.

[Filip Jirsák]

Asi jsi zaspal dobu, když si myslíš, že jsou to naše dodatečné podmínky.

Je milé, že chceš mě a Pihhanovi přiřknout vynalezení těchto věcí. Ale musím tě zklamat, náš vynález to není, je to běžný dnešní standard.

Tak to jistě nebude problém odkázat na nějaký úplný seznam těch dodatečných podmínek, nejlépe i nějak specifikovaných (třeba jako RFC). A určitě tam bude i popsáno, k čemu jsou takové dodatečné podmínky dobré (i když to zvládnu napsat sám – „aby to vypadalo, že se něco dělá“).

A až vynalezneš způsob, jak filtrovat spam bez heuristiky,

Heuristické filtrování spamu znamená analyzovat několik faktorů, zejména obsah e-mailu, a podle toho rozhodnout. Náhodné odmítání různých zpráv nemá s heuristikou nic společného, to je loterie.

[pavlix]

Náhodné odmítání různých zpráv nemá s heuristikou nic společného, to je loterie.

Právě proto se to náhodně nedělá.

[Pihhan]

To že ty počítače dnes už mají reverzní záznamy běžně asi souvisí s tím, že zrovna ve světě emailu se to docela často vyžaduje. Nevím jaké speciální postupy proti spamu používáte vy, ale já na svém serveru prostě adresy bez reverzů nepřijímám. Co mám dělat, spamu je všude plno, a v podstatě jde o plně legitimní poštu, kterou někdo odesílá někomu a já nemám co mu to nějak zahazovat. Opravte mě, pokud se mýlím, ale nějaký univerzální a 100% funkční metoda nefunguje a není. To co se pro boj se spamem používá je suma bonusů/postihů, kde odesílatele případně jeho zprávu nějak ohodnotíte a podle výsledku odhodnocení pošlete dál.

Na to, že ten kdo to myslí s mailem vážně, je schopen si to řádně nastavit a sehnat/vykřičet si na providerovi základní věci jako reverz a nějakou definovanou IP, nebo použije jako relay mailserver svého providera se jakž-takž spolehnout dá. Motivace je právě v tom, že dokud si nenastavíte něco jako vlastní identifikaci, ostatní se s vámi nebudou moc bavit. Je to blbé, není to ke všem férové, ale je to další krok k rozlišení, co přijímat chci a co ne.

Jestli máte o hodně vychytanější metodu, jak se zbavit spamu, prosím o linky, nebo přímo informaci. Asi bych nebyl první ani poslední, kdo by takovou informaci dostal. Spamassasin je sice super věc, ale nezvládá úplně všechno, co je schopen bloknout z pomocí několika primitivních metod. To nemluvím ani o tom, že u ověřování DNS pošlete jeden paket a počkáte si na druhý, když na zprávu pustíte assasina, tak to bude počítat pěkně dlouho a drtit CPU. Já náhodou v logu nacházím poměrně často zprávu, že byl odmítnut, protože nemá reverzi. Ještě mě to nikdo nereklamoval, a neobjevil jsem v logu zprávu s nepodezřelým subjectem, který by byl takto odmítnut. Takže vážně nevidím důvod, proč takové pravidlo nemít. Ale ne na všem se lidé musí shodnout, že ano :)

[Filip Jirsák]

Jestli máte o hodně vychytanější metodu, jak se zbavit spamu

K tomu mám jedině to, že tohle nepovažuju za metodu, jak se zbavit spamu. U mne by to např. eliminovalo ani ne 40 % spamu, takže na zbytek stejně musím nasadit něco jiného. Maximálně bych to mohl použít jako určitou váhu do celkového hodnocení, zda jde o spam – ale jinak mi ten test přijde zbytečný. Kdybych odmítal náhodně 40 % spojení, vyjde to nastejno.

[pavlix]

Kdybych odmítal náhodně 40 % spojení, vyjde to nastejno.

To si nemyslím :).

Btw, už jsi psal klukům od abclinuxu, že to maj špatně? :D

Přesněji řečeno... už tě s tím poslali do háje? ;)

[pavlix]

A pardon, že se pokauju, ale žádný maily se nezahazujou.

[pavlix]

*opakuju

[pavlix]

Tuto obranu používá například ABCLinuxu.cz.

Ale chápeš to špatně, žádné e-maily se nezahazují. Ony se nepřijmou, tak se nemůžou ani zahodit.

[xm]

Ještě bych rád uvedl odkaz na službu dns6.org - umožňuje vytvářet velmi jednoduše, rychle a zdarma dynamické DNS hostname (a to jak AAAA, tak A6 a i klasické A pro IPv4). Na některé jednoduché věci se to hodí

[pavlix]

Vypadá zajímavě, chystám se taky vyrobit nějakou jednoduchou službu.

[pepezdepa]

a kdy se dockame neco o IPv6 only sitich a pristupech na IPv4 sluzby? nejaky TRT apod? To jak nastavit zaklad IPv6 site zna hodne lidi, ale o tom jak vyresit tento problem se uz moc nepise :(

pepa z depa

[pavlix]

To jak nastavit základ IPv4/IPv6, DNS a další taky spousta lidí neví (dotazy, které dostávám po Jabberu jsou toho důkazem). Umět nastavit IPv6 síť společně s IPv4 mi přijde docela užitečné (aspoň pro lidi jako jsem já).

Pokud jde o nastavování IPv6 sítě, která zpřístupní část IPv4 služeb (třeba podobnou část jako umí NAPT)... to už je jen hraní si s "čistotou" sítě (tj, běží jen to, co se mi aktuálně líbí).

Ať nenechám otázku bez odpovědi, článkem o přístupu k IPv4 službám z IPv6-only sítě se začnu zabývat, až budu mít pocit, že je o něj dostatečně velký zájem.

[Ondrej 'SanTiago' Zajicek]

Premyslim, jak rozvrhnout IPv6 adresy v mensi siti. Prijde me jako znacne sradani pridelovat /64 rozsah pro point-to-point spoje mezi routery. Uvazuji, ze bych pro rozhrani na point-to-point spoji pouzil explicitne prirazene link-local adresy jako fe80::1 (a tyto adresy pouzil v pripadnych routach). Napada vas nejaky problem, ktery by tohle reseni mohlo mit?

Mate nekdo nejake zkusenosti, jak se programy vyporadavaji s link-local adresama (zejmena mam na mysli nutnost zadavat krome IP adresy i rozhrani)?

[pavlix]

Podle zdrojů se mi zdálo, že takovéto explicitně přiřazené adresy nejsou zvykem. Na druhou stranu v tom problém nevidím.

Pokud jde o aplikace, myslím, že nejlepší je po nich vůbec nechtít link-local adresy používat kromě bonjour/zeroconf a podobných, nebude se jim to bez zadání rozhraní líbit.

Osobně bych doporučil link-local používat kromě speciálních link-local aplikací jen na směrování a pro další aplikace vždy vyhradit globální adresu.

Těším se na zkušenosti jiných.

[petr_p]

Problém nastane, když nastane problém. Tedy, když uzel s příchozím rozhraním mající jen link local adresu vygeneruje ICMP6 chybovou zprávu a pošle ji zpět odesílateli, tak odesílatel uvidí, že k chybě došlo na adrese fe80:…, což hodně pomůže při hledání příčiny. Navíc se může stát, že takovou chybovou zprávu někdo cestou zahodí, protože link local adresy by se za routerem objevovat neměly.

[Ondrej 'SanTiago' Zajicek]

Opravdu se bude mit prislusna ICMP6 chybova zprava (nebo i jakykoliv odchozi traffic z daneho routeru pres dany interface) takovou zdrojovou adresu? V IPv4 by mela - tam se zdrojova adresa standardne nastavuje podle adresy odchoziho rozhrani. Nicmene mel jsem pocit, ze v IPv6 (v Linuxu) jsou nejaka sofistikovanejsi pravidla pro urcovani zdrojove adresy, ktere berou v potaz ruzny scope ruznych adres.

[pavlix]

Na to, že by se Linux choval k IPv6 adresám jinak než k IPv4 jsem zatím nenarazil.

Podle mě při komunikaci s link-local adresou používá link-local adresu (nemůže očekávat, že by druhá strana znala jeho globální) a při komunikaci s globální adresou se použije globální adresa toho zařízení.

Pokud na daném zařízení není globální adresa, není tam ani automatická routa.

No a samozřejmě přes ip route jde ledacos přizpůsobit.

[Ondrej 'SanTiago' Zajicek]

Na to, že by se Linux choval k IPv6 adresám jinak než k IPv4 jsem zatím nenarazil.

A on snad Linux v IPv4 dela to, co popisujes v druhem odstavci?

[pavlix]

Mám za to, že dělá. Ale bohužel teďka nemám čas to otestovat.

[pavlix]

Akorát IPv6 má link-local ve výchozí konfiguraci a jestli jsem dobře četl, tak podle RFC povinně.

[pavlix]

"Něco málo" o IPv6 i IPv4 a upřednostňování adres se píše v RFC 3484.

[petr_p]

Jo, je to tam:

It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination. (The "outgoing" interface.) On routers, the candidate set MAY include unicast addresses assigned to any interface that forwards packets, subject to the restrictions described below.

Takže situace, kdy jediná globální adresa je na loop backu nebo dummy rozhraní je oficiálně posvěcena.

Ovšem situace, kdy router nemá žádnou globální adresu (kdo by to dělal, když by přišel o možnost přihlásit se tam po síti), nemá žádné uspokojivé řešení.

Takže se omlouvám za zmatení. Zdá se, že koncept globální adresy náležící stroji a nikoliv rozhraní i někdo jiný považuje za rozumný.

[pavlix]

Taky už se mi párkrát jedna hodila, ale většinou jsem používal adresu prvního lokálního zařízení... ta adresa se pak routě přidělit jako preferovaná zdrojová adresa, ne?

[petr_p]

K čemu vám bude linková zdrojová adresa adresovaná globální adrese? V lokální síti to možná lze uhlídat, ale celosvětově? To už tam rovnou můžete dávat nespecifikovanou adresu. Nehledě na to, že spousta lidí vám takový pakety bude zahazovat. Jak pak bude fungovat Path MTU discovery? Jaký bude výstup z traceroutu? (Dosti komický.)

[lyon]

Pres local-link adresy se mi nepodarilo rozchodit OSPF6. Pouzival jsem tedy jen implicitni automaticke adresy, s rucne nastavenymi jsem neexperimentoval, ale pokud by nekdo vedel jak na to, rad bych si usetril praci s rozdelovanim prefixu na paterni interfaces. ;)

[pavlix]

Na IPv4 se to přes link-local adresy nedělalo, tak nevím, jak na IPv6. Podíval bych se na to, ale nemám testovací síť.

[Pihhan]

Obávám se, že dokud chcete udržet alespoň nějakou stabilitu adres, tak zrovna routery je vhodné číslovat ručně. Protože pokud chcete provádět registrace reverzních dns záznamů pro adresy routerů, tak to budete muset přepočítávat při výměně síťovky. Prostě adresy dedikovaných routerů a serverů je stejně jako na ipv4 vhodné nastavit natvrdo, aby tam nebylo cosi náhodného. Pravda, práce to je navíc, ale obvykle jednorázová, tak se to snad nějak přežije.

[David Rohleder]

Já to tak mám a funguje mi to bez problémů. Včetně OSPFv6 (ikdyž to běží jen na ciscách).

[Ondrej 'SanTiago' Zajicek]

Snad OSPFv3, ne?

[David Rohleder]

no jo, chybička se vloudila.

[pavlix]

Používání linkový adresy v lokální síti nejde uhlídat, pokud lokální sít neříkáš pouze jednomu ethernetovému segmentu.

A paket s adresamy s různým "rozsahem" (scope) je podle mě nesmyslný už sám o sobě, pokud se hry neúčastní NAT.

[petr_p]

Špatně vidím. Nějak jsem si domyslel, že používáte linkovou adresu prvního rozhraní. Samozřejmě, že použití globální adresy je naprosto v pořádku.

Pokud jde o to, jestli globální adresu přiřazovat loop/dummy zařízení a nebo skutečnému zařízení, tak je zde ten rozdíl, že skutečné rozhraní nemusí být vždy „up and running“ a tudíž se může stát, že zařízení nebude existovat (třeba z důvodu údržby), z něj žádnou adresu nedostanu (stateless) nebo adresa bude tentative (statická linkou neověřená).

Proto si myslím, že mít globální adresu na nečem trvalém je rozumná věc.

[pavlix]

S tím bych docela souhlasil.

[pavlix]

že by nefungovaly odpovědi?

[pavlix]

hmm, snad to brzo opraví

[Pihhan]

Co přesně chcete udělat s OSPF6? Jako registribuce jakýchkoliv linkových adres je zcela proti logice, když linková adresa nesmí opustit svoji linku (tedy routerem neprochází) a OSPF6 má za úkol šířit routovací informace (tedy kudy do jiné sítě, což linková adresa vědět nepotřebuje).

Já na síti nepoužívám vůbec radvd, ale nastavuju to přímo přes zebru, a kupodivu to tak nějak funguje. ospf6d používám taky, ale prostě na to potřebuju jenom globální rozsahy, šířit linkové nedává smysl. Ono teda se tam linkové taky projevují, protože jako default routa se používá linková adresa na router, nikoliv jeho globální adresa. To ovšem nic nemění na faktu, že router by asi mít globální taky měl mít, a odesílající počítač ji mít musí, aby mu mohla vůbec být doručena odpověď.

Asi jsem moc nepochopil, v čem máte problém. Jestli tu hustím samé samozřejmosti, tak se omlouvám :)

[pavlix]

to Pihhan:

Hezky shnuto...

Ty nastavuješ přes zebru i koncový stroje? Protože to jsou jediný, pro který je radvd dobrý.

Přes ospf má opravdu smysl šířit jen informace o globálních nebo lokálních prefixech (nikoliv linkových), ale netuším, jestli se při routování ze souseda na souseda uplatňují globální, lokální nebo žádné (přecejenom nás zajímá jen zařízení, kudy paket poslat, zdrojová adresa je naše a cílová adresa je neměnná).

[Pihhan]

Ano, v démonu zebra lze nastavit u interfacu (v editačním módu pro určený interface) něco typu no ipv6 nd-suppress a k tomu ipv6 nd prefix 2001::.../64, a funguje to stejně jako s radvd. Píšu z hlavy, přesný zápis si nastudujte v dokumentaci zebry. Nevím co tam jde dávat za parametry, ale pro přidělení adresy pomocí autokonfigurace s prefixem to postačuje. DNS to přidělit nijak neumí, ale to mělo snad i radvd nějak hodně experimentální a nedoporučované.

[pavlix]

No.. hodně experimentální a nedoporučované, spíš bych řekl nové.

[David Rohleder]

tazatel měl patrně na mysli, že nemusí adresovat globálními adresami jednotlivé sítě mezi směrovači. Což opravdu nemusí, OSPFv6 komunikuje po link-local adresách, ale v LSA si předává pouze identifikaci směrovače (čtyřbajtové číslo, často shodné s IPv4 adresou) a pak ty sítě s nelokálním významem.

IMHO je dobré nepoužívat globální adresy pro spojovačky mezi směrovači, zbytečně si tím budete plnit tabulky. Pokud chcete statické adresování, pak se dají použít staticky přidělené link-local adresy.

[pavlix]

Mě to statické adresování na link-local přijde trochu zbytečné.

[David Rohleder]

alespoň nemusíte měnit statickou routu při každé výměně routeru nebo síťové karty.

[Pihhan]

Potom by mě docela zajímalo, co bude hlásit traceroute6, když budu trasovat takový spoj. Každopádně dělat staticky link-local adresy mě fakt přijde jako blbost. Pokud se tu bavíme o routování ve spolupráci s ospf6, tak tam si případnou změnu adres do routování zanesou démoni automaticky a mělo by to fungovat bez jakékoliv manuální konfigurace, kromě snad povolení interfacu, že přes něj chci ospf používat. Což se minimálně v quaze nedělá pomocí adresy, ale jména interfacu.

[David Rohleder]

traceroute6 bude hlásit nějakou globální IPv6 adresu (třeba adresu loopbacku).

Jinak se bavíme o rozhraní mezi poskytovatelem běžícím OSPFv6 a zákazníkem, kterému směruji nějakou síť. Při každé výměně routeru na straně zákazníka by poskytovatel musel měnit statickou routu, což by bylo jistě velmi pohodlné...

[Pihhan]

Jistě, tohle je holý nesmysl a v tomto případě určitě bude poskytovatel přidělovat statickou adresu. Viděl bych to tak, že s nějakým prefixem dostanu jednu statickou adresu a s tímto prefixem lehce modifikovaným budu mít svůj subnet. To by mě docela zajímalo, jak případné subnety řeší sítě, které už ipv6 nabízejí nativně. Náš provider to teda rozhodně není :(

[David Rohleder]

IMHO dostanete jednu /64 dovnitř a spojovačka bude na link-local. Tak je to správně.

[Pihhan]

Jenže link-local je tak akorát na nasrání, pokud chcete na tom routeru něco případně provozovat, nebo se třeba připojovat vzdálenou správou někde z internetu. Prostě pokud chcete mít odchozí službu přímo na tom routeru, není problém si ji spárovat s jednou staticou adresou s prefixem 128. Protože zjištovat, co a jakou MAC si změnil nějaký jouda doma a poslouchat kvůli tomu telefonáty na servisní lince je nesmysl, stejně jako vázat rotuování na konkrétní mac. Kromě toho z pohledu poskytovatele to asi p2p nebude.

[David Rohleder]

On ten router u uživatele má ovšem i jednu adresu z vnitřní sítě, takže je globálně adresovatelný. Jak si to uživatel u sebe udělá je jeho věc.

[pavlix]

Jednu nebo více... ale taky bude mít jednu globální na zařízení ven a máš vyřešeno. akorát je dost pravděpodobný, že si na ní nezměníš reverzní záznam, takže budeš chtít stejně používat jinou. Ale to už je tvoje věc, jak si to zařídíš :).

[David Rohleder]

Jenomže tento způsob zbytečně plní OSPF tabulky. Ne, že by to nešlo.

[pavlix]

No... já myslím, že byla řeč o standardním způsobu... ne o nějakých malých poskytovatelích, co ani nedávaj /48.

[David Rohleder]

? /48? To je vtip? Takový rozsah mají velké sítě, nevidím absolutně žádný důvod, proč dávat koncovým zákazníkům něco takového.

[David Rohleder]

Tím koncovým zákazníkem myslím nějakého Frantu Uživatele s domácí sítí.

[pavlix]

No... Franta Uživatel dostane /64, samozřejmě :D.

Protože je to pro něj lepší.

A dostane předkonfigurovaný router, který mu tu /64 rozroutuje.

nemá smysl dávat /48 někomu, kdo neumí stavět síťě a připojí k routeru dva počítače :D.

Z tohohle pohledu berte můj příspěvek dole s rezervou :). Ten je spíš z pohledu člověka, co má maličko větší domácí síť, kde ten router má několik děr, ze kterých vedou kabely nezávislých rozsahů oddělených firewallem.

[pavlix]

To naštěstí není vtip. Nebo si myslíš, že náš jeden server je velká síť? :D.

P.S.: Já osobně nevidím důvod, proč vůbec dávat koncovým zákazníkům nějakej internet... vždyť si můžou zaplatit pobyt v internetové kavárně, že? :D

Pardon, trošku přeháním, ale /48 je rozsah, který vám dá kterýkoliv větší ISP. A dá vám ho bez okolků, protože jakmile se mu začne plnit jeho rozsah, dostane automaticky přidělený další.

Samozřejmě, pokud jde o místního wifi providera, který je zákazníkem "velkého" providera, tak vám /48 nedá.... protože je sám považován za "koncového zákazníka" a tudíž má sám /48, tak vám dá třeba /56, když je hodný... nebo /64, když je mu to jedno.

Btw... /48 rozsahů je pořád teoreticky víc než je počítačů v šedesáti tisících celých "IPv4 Internetech". Kromě takovéhoto obrovského nárůstu byly ještě provedeny administrativní kroky k zajištění široké dostupnosti internetu.

Doporučuju se podívat na to, jaký význam se přisuzuje jednotlivým částem adresy... dva bajty mezi /48 a /64 jsou určeny k místnímu rozdělení na straně zákazníka.

Nikdo si samozřejmě nedělá iluze... někdo holt dostane /64 (jedna automaticky konfigurovaná síť nebo spousta "nestandardně" agregovaných), někdo /128 (jedna IP a konec), což doufám moc lidí nepotká, že by dostaly pro celou síť jednu IPv6, konkurence snad zafunguje :).

[David Rohleder]

/128 snad ne, to by musel dovnitř sítě nasadit ten škaredý NAT, což se nám nelíbí.

Jinak celkem souhlas.

[pavlix]

No... síť se agreguje až na /128 :).

Třeba já mám /48 přes tunel, rozdělený na několik místních sítí (/64) a koncové počítače dostanou /128.

Takže pokud bude poskytovatel počítat jen s jedním zařízením na konci, tak nemá důvod dávat víc. V tomhle případě to půjde obejít zase jenom nějakým polovičatým řešením typu proxy nebo NAT (princip je stejný, použít počítač, který na internetu je, k dosažení služeb).

[pavlix]

Já jsem tuším viděl řešení stejné jako u tunelů. Propojovací IP adresa ven... a subnet směrovanej na ní. Nedávno jsem to viděl i na IPv4.

[pavlix]

Zapoměl jsem upozornit, že ta IP adresa není z toho rozsahu.