Közháló Szolgáltatás Felügyelet Végponti technikai információk
Végponti szolgáltatások 1 Adminisztrációs postafiók Web mail Levelezési lista Mail Relay és vírusszűrés Web hosting DNS szolgáltatások NTP szolgáltatás
E-mail Zárt adminisztrátori postafiók Lokálisan adminisztrált web mail Web, POP3, IMAP, SMTP elérés bárhonnan (kívülről SMTP jelszó kell)
Saját mail szerver Független a többi mail szolgáltatástól, de az MX rekordra gondolni kell Ne legyen open relay! (ellenőrizzük) A Mail Relay szolgáltatás vírusszűrést is biztosít
DNS Web adminisztráció
A, CNAME, PTR rekordok kezelése MX rekord csak ügyfélszolgálaton keresztül
Saját resolver DNS
Saját Primary ADNS
Létesítés menete DNS szerver építés Zóna fájl elkészítése Tűzfalon port megnyitása Primary DNS átvétele NS rekord átírása a sulinet.hu zónában Reverse DNS átvétele lehetséges RFC 2317 szerint
Saját Secondary ADNS
Szabályok 2 szerver Külön hálózaton SOA rekordban szereplő postafióknak élnie kell SOA timerek RFC szerinti megadása stb...
Végponti szolgáltatások 2 Menedzselt tűzfal Menedzselt DHCP szolgáltatás VPN hozzáférés Menedzselt VLAN Switch port konfiguráció QoS szolgáltatás
Végpont felépítése
Alapértelmezett tűzfal szabályok Zöld nyíl: kapcsolat megengedett Piros nyíl: kapcsolat tiltott Betűvel jelzett szabályok módosíthatóak
Tűzfal módosítás korlátai Tiltott portok a border routerek szintjén is korlátozva vannak (nem lehet kivételt tenni) Közháló 2: A külső intefészen lévő, a publikus szegmens felé mutató access listát lehet módosítani (port nyitások) Közháló 3: A belső szegmensek forgalmát is lehet korlátozni Port nyitás Privát szegmens felé (port forward) Indokolt esetben a tűzfal teljes megnyitása kérhető Egy publikus címre lehet kérni. Faxon kérünk megerősítést és nyilatkozatot a felelősség vállalásról. Tiltott portok így sem nyithatók meg.
Tűzfal módosítás módja Portálon keresztül: Internet felől az 5 publikus IP címere TCP vagy UDP portok, kisebb port tartományok megnyitása Internet felé tetszőleges TCP/UDP port vagy port tartomány tiltása Azonnal érvényre jut Ügyfélszolgálaton keresztül: Internet felől egyéb protokollok megnyitása (GRE, ESP), nagyobb TCP/UDP port tartományok megnyitása, port nyitás Privát szegmens felé (port forward) ÜSZI által felvett szabályokat csak ÜSZI tudja visszavonni.
Alkalmazások támogatása Real Audio támogatás FTP és passzív FTP támogatás TCP_ECN (Explicit Congestion Notification) támogatás van, de máshol lehet hogy nincs! Netshow, SQL *Net, Netmeeting, StreamWorks, VDOLive... SIP támogatás elvileg van Gyakorlatban nem minden szolgáltatóval működik T-Com Klip pl. nem működik. Használata csak publikus szegmensen lehetséges, és csak ha SIP kontrol port és média portok statikusan nyitva vannak Skype: nem kell tűzfal támogatás, protokoll végzi a kétoldali UDP port nyitást PPTP pass-thru nem támogatott (publikus szegmensről használható csak, GRE portot statikusan ki kell nyitni) IPSec pass-through nem támogatott (NAT-T mellett működik)
Switch port módosítás Switch portok alapból Ethernet auto-negotiation alapján működnek Automatikus sebesség (10/100, két utolsó porton 10/100/1000) és Automatikus duplexitás (half/full) érzékelés Hibás egyeztetés eltérő beállítást, és emiatt késői ütközést, nagy mértékű csomagvesztést, és sebesség csökkenést eredményezhet Csak ügyfélszolgálaton keresztül kérhető a módosítása Fix sebességek: 10-Half, 100/Half, 100/Full A fixálás egyben kikapcsolja az auto-negotiation funkciót Auto-negotiation nélkül 10/Half az alapértelmezetta túloldali eszköznél A csatlakozó eszközt is fixen be kell állítani
Switch trönk port használata Csak ügyfélszolgálattól kérhető bekapcsolása Egy interfészen több VLAN átadása 802.1Q protokoll segítségével Intézményi (saját üzemeltetésű) tűzfal vagy switch felé használható Kevesebb fizikai port, egyszerűbb kábelezés elegendő VLAN kiosztás fix, nem módosítható Publikus: 10, Privát: 11, Védett: 12, Lokális1: 20, Lokális2: 21, Lokális3: 22, Lokális4: 23
Lokális VLAN Ha végpont saját szája íze szerint szeretné szegmensekre osztani a switch-et Lokális szegmensben Közháló tűzfalnak (router) nincsen IP címe Külön tűzfal szükséges az Internet eléréséhez Több ilyen szegmens is lehet (Lokális1, Lokális2, Lokális3, Lokális4) Trönk port beállítása is kérhető
Két lokális szegmens példa Közháló Védett Publikus Saját tűzfal Tanár PC Lokális (2) Privát Lokális (1) Diák PC File szerver Web és levelező szerver
Közháló VPN IPSec által titkosított és hitelesített kapcsolat minden végpont védett szegmense és egy központi szolgáltatói szegmens között (Sulinet Programiroda). Nincs címfordítás: nagyobb hitelesség Jelenleg egy alkalmazás fut felette: Sulinet elégedettség felmérés Amit nem nyújt: végpontok közötti átjárhatóság, egyéb kapcsolat végpontok elérése otthonról IPSec segítségével
Tapasztalt nehézségek SMTP forgalom korlátja Több Internet kapcsolat Dual-home szerver nem elérhető Két végpont kommunikációja Név feloldási probléma Wake-On-LAN Saját hálózati eszköz csatlakoztatása
Email védelem Végponti tűzfalon szigorúbb szűrés 2005 február óta Elsősorban vírusok ellen Privát (diák) szegmens: csak Publikus és ISP szerverek felé küldhet üzenetet Ez alól nem enged kivételt az automatikus konfiguráció ISP szerver tetszőleges feladó címmel elfogadja az üzenetet Külső szolgáltató postafiókját használva is SMTP szervernek a Sulinetes szervereket kell beállítani Publikus szegmens: amelyik IP cím felé tűzfalon nyitva az SMTP, az küldhet bárhova, egyébként csak ISP szerverek felé Ha csak küldeni szeretne egy szerver: deny from=bárhonnan to=szerver_ip tcp=25 permit from=bárhonnan to=szerver_ip tcp=25 Tűzfalon az első szabály felülbírálja másodikat A visszirányú portnyitás viszont csak a permit sorokat nézi, és kinyitja kifelé SMTP-t
Mail Guard A tűzfal szabályok által átengedett SMTP forgalmon végez alkalmazás szintű ellenőrzést RFC szerinti működést vár el IOS 12.3(3.9)T2 ez még nem tudott ESMTP-t Pár funkciója gátolhatja az egyébként normális SMTP működést ESMTP kapcsolatokat is "visszabutítja" SMTP-re. Delivery Status Notification nem megy át Nem enged kézzel SMTP kapcsolatot tesztelni (telnet ip-cím 25,...). Pár helyen (eddig Exchange, Mercury esetében fordult elő) megakadályozza a normális kommunikációt. Bizonyos szerverek felé egyáltalán nem mennek ki levelek Véletlenszerű kieséseket nem szokott okozni SMTP AUTH nem megy át rajta. SMTP over SSL/TLS nem megy át rajta. Ha problémát jelent a működése, kérni lehet kikapcsolását Kikapcsolás teljes routerre vonatkozik, nem lehet csak egyik irányban
Két Internet kapcsolat Feladat Egy épületben két Internet kapcsolat Mindkettő Közháló (pl. kollégium+iskola), vagy iskolának van egy másik (saját) Internet elérése Szeretné mindkettőt használni (terheléselosztás) Amit nem szabad Közvetlen csomagtovábbítás Sulinet és nem-sulinet hálózat között (amúgy is csak a végponti címekről jövő csomagokat engedjük ki) Egyéb módon adattovábbítás (pl. publikus proxy, címfordítás, SOCKS, GRE tunnel) segítségével nem-sulinetes felhasználók számára Sulinet vonalat elérhetővé tenni (Lake Success-i egyezmény megsértése!)
Két Internet kapcsolat 2. Linux, 3 Ethernet interfész, kettős NAT 1. Statikus route (pl. leggyakrabbi magyar oldalak egyik, minden egyéb másik irányban) 2. Policy route (pl. böngészés egyik, P2P forgalom másik) 3. Load Balancing Linux Advanced Routing & Traffic Control http://lartc.org Véletlenszerűen éri el szervereket a két kapcsolaton, de egy szervert mindig egyik irányban Közháló Gerinc Publikus Lokális 1. ISP
Két Internet kapcsolat 3. Egy érdekes megoldás: ARP Round-Robin Két router címe megegyezik (192.168.64.254) Amelyik routertől előbb kap a diák PC ARP választ, abba az irányba fog kimenni Routerek panaszkodnak IP cím ütközésre, de működnek Véletlen hibákat okozhat: a PC szemszögéből aktív routerhez tartozó Publikus szegmenst közvetlenül, a másik Publikus szegmenst a Közhálón keresztül éri el Nem javasolt megoldás Közháló Gerinc Publ.1 Privát (diák) szegmens Publ.2
Dual-home szerver probléma Szerverben két Ethernet interfész Sérül a DMZ biztonsági elv A szerver publikus címe nem lesz belülről elérhető Privát-Publikus között nincsen címfordítás Válasz csomag Privát címre szól, szerver a belső interfészén küldi Tűzfal blokkolhatja forgalmat, ha csak az egyik irányt látja PC nem ismeri fel a válasz csomagot, ha az a szerver privát címéről érkezik Közháló Gerinc Publikus Privát (diák)
Két végpont összekapcsolása Feladat Két végpont közös intézmény alatt de külön telephelyen. Meg kellene valósítani kapcsolatukat Közháló vonalon keresztül. Megoldás 1. (jelenleg nem támogatott) GRE tunnel Közháló routerek között Csak Védett (tanár) szegmenst lehetne összekapcsolni (diák szegmensek egyező címeket használnak) Jelenleg automatikus konfiguráló rendszerek nem támogatják, tömeges igény esetén van csak értelme a megoldást tesztelni és konfiguráló szoftverekbe belefejleszteni. Megoldás 2. Közháló sebessége LAN-to-LAN file átvitelre csak korlátozottan alkalmas Egyéb, nagyobb sebességű P2P média (wireless bridge,...)
Két végpont összekapcsolása 2. Megoldás 3. Saját felügyeletű GRE (esetleg IPSec) tunnel (pl. PC, duál ethernet, Linux, iptables+nat, GRE tunnel) Privát (diák) szegmens helyett Lokális szegmens használata, így nem ütköznek a címek Mindkét irányban az Upstream sebesség lesz a korlát! Közháló Gerinc GRE Tunnel Publikus NAT Publikus NAT Lokális 1. Lokális 1.
DHCP és DNS DHCP szerver beállítása módosítható eltérő DNS szerver és domain név állítható be IP tartomány kivehető DHCP alól (exclude) Egyéb esetekben kérni kell a megfelelő szegmensre a DHCP kikapcsolását, és saját DHCP szervert kell üzemeltetni Fentieken túlmutató opciók beállítása (pl. tftp szerver) Fix címek osztása DHCP segítségével (pl. nyomtatónak) Hosszabb lease kezelése (router elfelejti lease-eket reboot esetén) Egy tipikus DNS hiba elsődleges szerver: iskolai Active Directory másodlagos szerver: ISP DNS szervere véletlenszerűen jelentkező hibát okoz: munkaállomások néha nem találják Domain-t, valamint néha nem tudnak helyi címeket feloldani Win2k+ munkaállomások a DNS-ből szedik ki az NT domain és AD információkat
Microsoft hálózat több szegmensen Név szerinti eszköz azonosítás nem megy a szegmensek között Lehetséges megoldások Fix IP cím használata a végponton, és minden gép hosts file-ján keresztül megadni a név-cím összerendelést WINS alkalmazása (egy WINS szerver, munkaállomások ide regisztrálnak, innen megy a név feloldás) ActiveDirectory és helyi DNS szerver használata
Wake-On-LAN A megérkezett Ethernet keretben 6 darab FFh byte után legalább 16-szor kell ismétlődnie a cél állomás Ethernet címének ( mágikus csomag ) Egy szegmensen belül működik Broadcast és UDP porton egyaránt Szegmensek között korlátozottan működik Broadcast csomagok nem routolódnak! Unicast UDP-be csomagolva szokták használni, de UDP kiküldése előtt ARP címfeloldást csinál a router, és mivel az sikertelen lesz, UDP csomagot már nem küldi ki Mindenképpen fix ARP bejegyzés kell routerbe! Közhálóban távoli vagy szegmensek közötti WOL csak fix ARP bejegyzés mellett támogatott: Publikus és Privát szegmes között oda-vissza Védett szegmensről a Publikus szegmensre Visszafelé nem megy! Internetről Publikus szegmensre További UDP port nyitása szükséges a tűzfalon Internetről Privát szegmensre További UDP port nyitása (port forward) szükséges a tűzfalon
Saját hálózati eszköz csatlakoztatása Hibás LAN eszköz (HUB, switch) a Közhálós switch portjának letiltódásához vezet ( err-disable ) Switch port melletti LED zöld helyett sárga állapotú Nem vált vissza magától (LAN védelme) Oka lehet Hosszú hálózati kábel ( Late collision ) Kontakt hiba ( Excess collision ) Duplexitás különbség A switch portját újra kell engedélyezni Ügyfélszolgálat -> Hálózatfelügyelet Switch újraindítás
QoS szolgáltatás
Torrent probléma Torrent forgalom felhasználja véges erőforrásokat Bejövő sávszélesség ezen osztozik többi alkalmazással, kisebb lassulást okoz Kimenő sávszélesség általában ez a gyengébb, a torlódás itt drasztikus lassulást okoz Routerek NAT és kapcsolat táblája ha megtelik, router nem képes felépíteni új kapcsolatot Több szintű védekezés Legjobb, ha a torrent klienst lehet korlátozni (DHT kikapcsolása, fel- és letöltés korlátozása, kapcsolat szám korlátozása, ) Központosított védekezés QoS segítségével torrent forgalom korlátozása DHT tiltása (UDP fogalom, ahol forrás és cél port is >1023), és Tracker szerverek tiltása változásokat követni kell
Hibakeresés a végponton Ping Végponti router-t Szomszédos munkaállomást Traceroute Névvel IP címmel Végponti eszközök LED-jei normál működés alatt és hiba esetén Távközlési berendezés (pl. ADSL modem) Router Switch Hálózati beállítás ellenőrzése Ipconfig /all
Switch és router diagnosztika Portál felületen érhető el Cisco IOS show parancsok kimenete látszik Router esetében Interfészek állapota, részletes számlálók DHCP szerver statisztikák Aktuális ARP tábla Tűzfal szabályok és találati számok Aktuális tűzfal kapcsolatok Aktulis címfordítások (NAT) Switch esetében Interfészek állapota, részletes számlálók Bridge tábla tartalma Parancsok értelmezése: ÜSZI vagy CCO http://www.cisco.com
köszönöm a figyelmet NETvisor Zrt.