közháló szolgáltatás felügyelet végponti technikai...

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

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

Létesítés menete

Saját Secondary ADNS

2 szerver

Külön hálózaton

SOA rekordban szereplő postafióknak

élnie kell

SOA timerek RFC szerinti megadása

stb...

Szabályok

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

Privát

Tanár PC

Diák PC

File

szerver

Web és

levelező

szerver

Publikus

Lokális (1)

Saját

tűzfal

Lokális (2)

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 Sulinet-

es 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.

Publikus

Lokális 1.

Közháló

GerincISP

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

• 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ét Internet kapcsolat 3.

Privát (diák) szegmens

Közháló

Gerinc

Publ.1

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

Publikus

Privát (diák)

Közháló

Gerinc

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!

NAT

Publikus

Lokális 1.

NAT

Publikus

Lokális 1.

GRE Tunnel

Közháló

Gerinc

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.