O prolínání práce v IT a osobního života

čtvrtek 23. srpna 2007

BIND Multiview



V situaci, kdy je doména hostována na DNS serveru, který je součástí lokální sítě nebo DMZ, vzniká problém s překladem DNS pro aplikační služby umístěné za firewallem.

Tento problém spočívá v tom, že DNS ukazuje na WAN rozhraní firewallu. Při přístupu z vnitřní sítě však firewall typicky zakáže přístup přes WAN rozhraní všem packetům se zdrojovým IP z vnitřní sítě. Výsledkem je, že aplikační služby umístěné za firewallem fungují pouze z internetu, nikoliv však z vnitřní sítě.

Možností jak vyřešit tento problém je několik, například:
  • omezení firewallových pravidel (díra do fw)
  • speciální funkce firewallu (modifikace DNS odpovědi)
  • použití veřejných IP adres pro DMZ
  • dva DNS servery (jeden pro internet, druhý pro vnitřní síť)
  • DNS multiview
A právě o posledně jmenovaném řešení pojednává tento článek. Hlavní myšlenka je prostá: Nakonfigurovat DNS server tak, aby vracel různé odpovědi na základě zdrojové IP tazatele.

V případě BIND9 by konfigurační soubor vypadal následovně:

// ====
// ACLs
// ====
acl "ournetworks" {
127.0.0.0/8;
10.0.0.0/8;
};

acl "ispns" {
8.8.8.0/24;
};

// ============================
// Konfigurace pro dotazy z LAN
// ============================
view "internal" {
match-clients {
ournetworks;
};
recursion yes;

// =============
// special zones
// =============
zone "." {
type hint;
file "/etc/bind/db.root";
};

zone "localhost" {
type master;
file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};

zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};


// =========
// our zones
// =========
zone "domena.cz" {
type master;
file "/etc/bind/db.cz.domena.internal";
allow-transfer { any; };
};

zone "0.0.10.in-addr.arpa" {
type master;
file "/etc/bind/db.10.0.0";
allow-transfer { any; };
};
};

// =================================
// Konfiguace pro dotazy z internetu
// =================================
view "external" {
match-clients {
any;
};
recursion no;

// =============
// special zones
// =============
zone "." {
type hint;
file "/etc/bind/db.root";
};

zone "localhost" {
type master;
file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};


// =========
// our zones
// =========
zone "domena.cz" {
type master;
file "/etc/bind/db.cz.domena.external";
allow-transfer { ispns; };
};
};
Share:

středa 1. srpna 2007

Vizualizace Cisco flows dle AS - aneb kudy to sakra teče? :)



Jedná se o vyřešení klasické situace, kdy je ASBR připojen do peeringového centra, skrz které má spojení do mnoha sousedních AS. Všechno krásně funguje, data proudí, ale admin neví nic o tom kolik z/do kterého AS vlastně teče.
Je mi jasné, že někteří toto vůbec neřeší a monitorují pouze celkový traffic z/do peeringového centra. Já však tento přístup považuji za neprofesionální, protože zastávám názor, že tyto informace mohou mít zásadní význam pro správu BGP a pro koncepci dalšího rozvoje sítě (pro štoury: typickým příkladem může být situace, kdy partner podmiňuje peering nějakým minimálním trafficem).

Pro vyřešení této situace jsem znovu použil řešení, které jsem již popsal v článku s názvem Vizualizace Cisco flows na Linuxu. V tomto případě jsem se však zaměřil na monitoring dat, která procházejí jednotlivými BGP peery.

Takže jak na to? Je třeba přidat seznam AS se kterými je router propojen do souboru CUFlow.cf, příklad:


ASNumber 29086 Gity
ASNumber 42000 Global_Inspiration
ASNumber 35361 GREPA
ASNumber 2819 GTS_NOVERA
ASNumber 15935 ha-vel_internet
ASNumber 29134 IGNUM
ASNumber 24806 INTERNET_CZ
ASNumber 25424 INTERNEXT2000
ASNumber 8928 Interoute
ASNumber 9080 Ipex
ASNumber 15598 IP_Exchange
ASNumber 24971 Master_Internet
ASNumber 34315 MAXPROGRES
ASNumber 20723 MGI
ASNumber 34080 MIRAMO
ASNumber 8913 Mopos
ASNumber 9148 net4net
ASNumber 8422 NetCologne
ASNumber 35236 NETWAY
ASNumber 8251 NFX
ASNumber 6881 NIX
ASNumber 39817 OVANET
ASNumber 35214 OXID
ASNumber 12306 Plusline
ASNumber 30764 PODA
ASNumber 12767 PRAGONET
ASNumber 25248 RADIOKOMUNIKACE
ASNumber 12570 SELFservis
ASNumber 5407 Skynet
ASNumber 29113 Sloane
ASNumber 31246 SMART_Comp
ASNumber 39392 SuperNetwork
ASNumber 5610 Telefonica_O2
ASNumber 28725 TelefonicaO2-Eurotel
ASNumber 25036 TERMS
ASNumber 13036 T-Mobile
ASNumber 38949 Trestel_SK
ASNumber 33883 TRIOPTIMUM
ASNumber 29583 Unient
ASNumber 6830 UPC
ASNumber 702 Verizon
ASNumber 16019 Vodafone
ASNumber 6706 VOLNY
ASNumber 39790 Web4U
ASNumber 21430 WIA

A následně restartovat flowscan.

A na samotném routeru je třeba upravit export flows, je možné si vybrat dvě varianty:

ip flow-export version 5 peer-as

nebo

ip flow-export version 5 origin-as

V prvním variantě se čísla ASek přidělují na základě toho, z/do jakého peeru data proudí (to je můj případ). Ve druhé variantě se čísla ASek přidělují na základě toho, z/do jakého ASka data směřují. Tzn., že pokud pátráte po tom kolik s kým peerujete, tak použijte první variantu. Pokud vás však zajímá odkud/kam Vaše data směřují a s kým by bylo případně vhodné nějaký nový peering navázat, použijte druhou variantu (ale to však budete muset nacpat více ASek do konfigurace CUFlow.cf).
Share: