Hálózat konfigurálása transzparens proxyhoz

  • Leírás
  • Tanmenet
  • Kérdések
  • Értékelések

Egyszer volt, hol nem volt, a kilencvenes években, amikor még modemmel tolta otthon a többség a 150 forintos Matáv kedvezménnyel, amikor a kisebb cégeknél 64k – 128k bérelt vonalak voltak, a nagyobb cégeknél pedig E1-E3, esetleg ATM (nem, nem a pénzkiadó automata) a rendszergazdák felfedezték maguknak a proxykat. A proxy egy kedves jószág volt, a rajta áthajtott (leginkább) webforgalmat tárolta és amennyiben bizonyos időn belül másvalakinek ugyanaz a tartalom kellett, akkor helyben kiszolgálta, ahelyett, hogy a lassú és drága WAN kapcsolaton lekérte volna újra ugyanazt. A végfelhasználóknak ez jó is volt, mert a felhasználói élmény javult, de rossz is volt, mert olyan dolgokkal kellett ezután szembesülniük, mint tartalomszűrés, proxy beállítási nehézségek, roamingolás közben esetleg bosszankodás. Természetesen az informatikának volt erre válasza, mint például a PAC (Proxy Auto Configuration), de ez igazából nem tökéletes, mert függ sok tényezőtől. A másik megoldás a rendszergazdáktól jött, akik leggyakrabban egy linuxos internet kijáratot üzemeltettek és egyszerűen beállítottak egy transzparens proxy-t, amire a forgalmat átirányították.

Előretekerünk 2020-ba, amikoris a WAN sávszélességek igazából nem szűk keresztmetszetek, kapacitás van bőven, ellenben a biztonság sokkal nagyobb probléma, mint húsz éve. Rosszindulatú javascript kódok, phishing oldalak, bitcoin-bányász programok játéknak álcázva, ransomware programok, makrós mellékletek levelekben – napestig lehetne sorolni miféle veszélyek leselkednek az egyszeri felhasználóra, aki csak békésen szeretne böngészni. A tartalomszűrésnek ma sokkal inkább van létjogosultsága mint eddig bármikor és ma már a tartalom lokális tárolása a gyorsabb kiszolgálás érdekében háttérbe szorult. De a proxy-k továbbra is megbízhatóan teszik a dolgukat.

Mit tegyen azonban a rendszergazda, ha egy közönséges iptables REDIRECT szabály nem elérhető számára? Mit tegyen, ha nincsenek általa üzemeltetett linux rendszerek, mert szegénynek hálózati eszközei vannak csak? Hogyan tudja a forgalmat elterelni a transzparens proxy irányába, hogy az, aki azt üzemelteti, kezelni és kontrollálni tudja a forgalmat?

A képzésen egy laborban fogunk dolgozni ahol egy tipikus céges hálózatot fogunk konfigurálni. Nincs benne linux tűzfal, nincs benne iptables, nincs benne semmi, amit egy átlagos rendszergazda használni tudna. Csak hálózati eszközök vannak és ezekkel fogjuk megoldani ugyanezt a feladatot. Nagyon izgalmas képzés lesz olyan szempontból, hogy visszaköszönnek benne olyan technológiák illetve protokollok, amelyeket már egyszer megismertünk és most újra segítségül fogjuk hívni őket. Tipikus példája annak, amikor az elméletet egyszer valamikor megtanultuk, most pedig a gyakorlatban alkalmazzuk. Az oktatáson nem azt fogod megtanulni, hogyan kell proxy-t installálni – ezt majd megcsinálja egy rendszergazda. Azt fogod megtanulni, hogy a hálózat üzemeltetőjeként (legyen a szerep akár önként vállalt, akár rádszuszakolt) miképpen tudod hálózati eszközökkel a transzparens proxy-hoz eljuttatni a forgalmat. Természetesen mindent az oktató képernyőjén követhetsz végig, a konfigurálást, ellenőrzést és hibakeresést is. Nyakig túrunk ismét a wireshark-ba, hogy minden részletét megértsük a dolgoknak és szükség esetén másnap a saját hálózatodban magabiztosan tudd bevezetni a tanultakat.

Course Information

Categories:

Képzés Instructor

Kósa Ádám Kósa Ádám Author

Hálózati mérnök, a DevOps Akadémia oktatója. Team leader a Sky-nál.

Subscribe
Visszajelzés
guest
0 Kérdés
Most Voted
Newest Oldest
Inline Feedbacks
View all comments

6
tanuló
1
fejezet
2
tananyag
Kósa Ádám Kósa Ádám
Tanmenetek: , ,

6
tanuló
1
fejezet
2
tananyag
Kósa Ádám Kósa Ádám
Tanmenetek: , ,