Nová stránka

Hoci sa preklad cieľovej adresy (presmerovanie) zväčša používa v smere z WAN do LAN, niekedy príde vhod aj opačný smer. Z technického hľadiska a ani z hľadiska konfigurácie síce nie je žiadny rozdiel, no z praktického pohľadu tým dosahujeme úplne iný cieľ. Našich LAN klientov dokážeme nasmerovať tam, kam potrebujeme, väčšinou s cieľom ochrániť ich alebo kompenzovať obmedzenia, ktoré vznikli presmerovávaním z WAN do LAN.

Situácia 1: Webové rozhranie z LAN

Webové rozhranie smerovača sme presunuli na port TCP/81 (WinBox ponuka IP → Services), aby sme uvoľnili webový port TCP/80 pre presmerovanie z internetu do LAN a zároveň mali dostupné aj webové rozhranie smerovača.

V smere z LAN je presmerovanie TCP/80 zbytočné - webové rozhranie by sme chceli mať dostupné na štandardnom porte TCP/80. Využijeme pravidlo destination NAT pre požiadavky prichádzajúce z LAN rozhrania na TCP/80 a akciu redirect, ktorá vykoná presmerovanie na smerovač samotný (čím sa forward mení na input), pričom zmeníme cieľový port na 81.

Hoci sa všetko zdá jednoduché, je tu opäť skrytá komplikácia - akonáhle toto pravidlo presmerovania pridáme, prestanú nám fungovať internetové webové stránky, namiesto nich sa zobrazuje webové rozhranie smerovača. Riešenie je rovnaké ako v predošlej kapitole - je potrebné špecifikovať aj typ cieľovej adresy (Dst. Address Type) - opäť zadáme local.

Situácia 2: Vynútenie lokálneho DNS servera

Klientom v LAN chceme zabrániť používať iné DNS servery a vynútiť používanie nášho DNS servera. Dôvody môžu byť dva:

1. klientov chrániť pred falošnými DNS servermi (nastavenými malvérom);
2. klientom sprístupniť lokálne DNS mená, ktoré sú definované len na našom lokálnom DNS serveri.

Mohli by sme uplatniť zákaz na firewalli, no ak by niekto mal nastavený iný DNS server, prestal by mu „fungovať internet“. Preto využijeme destination NAT pre požiadavky prichádzajúce z LAN rozhrania na TCP a UDP porty DNS (teda 53).

Pozor na typ cieľovej adresy! Kým pri presmerovávaní adresy smerovača sme volili local, teraz potrebujeme presný opak - teda zvolíme negáciu !local. Smerovač si bude všímať tie požiadavky, ktorých cieľová adresa je iná ako jeho vlastná adresa.

Môžeme ich dať presmerovať:

• a) Na náš DNS server vo WAN alebo v DMZ - využijeme akciu dst-nat.
• b) Na smerovač samotný, teda jeho interný DNS server. Využijeme akciu redirect, ktorá mení forward na input.

V oboch prípadoch budú klienti transparentne manipulovaní, ani sa o tom nedozvedia.

Prečo má byť DNS server vo WAN alebo v DMZ, nemôže byť aj v LAN?

Mohol by, ale potom by nastal problém Hairpin NAT, ktorý je opísaný nižšie. Vo všeobecnosti je lepšie, aby servery boli v samostatnej sieti (DMZ).

Situácia 3: Hairpin NAT

Toto je jedna z najčastejších situácií, ktorá spôsobuje začiatočníkom vrásky. V predošlej kapitole sme úspešne nastavili prístup na náš webový server z internetu (presmerovaním portu). Všetko funguje, keď sa pripájame z WAN - či cez mobilné dáta, od suseda alebo zo školy. Akonáhle však zadáme naše verejné doménové meno (alebo verejnú IP) na počítači v tej istej LAN sieti, stránka sa nenačíta.

Analýza situácie

Prečo to nefunguje? Problém nie je v presmerovaní, ale v ceste odpovede (asymetrické smerovanie):

1. Počítač z LAN pošle požiadavku na verejnú IP adresu, paket odošle smerovaču. Ten má túto verejnú adresu priradenú na svojom WAN rozhraní.
2. Smerovač prijme paket. Pravidlo v destination NAT hovorí, že pri požiadavke smerujúcej na jeho IP adresu (a uvedený port) sa má zmeniť cieľová IP adresa na server v LAN. Tak sa aj stane a upravený paket odošle LAN serveru.
3. Server prijme paket a v ňom vidí, že požiadavka prišla zo susedného počítača v jeho LAN (zdrojová adresa sa nemenila). Požiadavku vybaví a pripraví odpoveď na odoslanie.
4. Keďže server aj počítač sú v rovnakej sieti, server odpovie počítaču priamo (nie cez smerovač). Odošle mu paket, ktorého zdrojová adresa je LAN adresa servera.
5. Počítač prijme tento paket. Očakával odpoveď z verejnej IP adresy (s ktorou nadväzoval komunikáciu), no namiesto toho dostal paket z akejsi (pre neho neznámej) lokálnej IP adresy. Takýto paket zahodí ako neplatný.

Pokiaľ by server nebol v LAN s ostatnými počítačmi, ale v samostatnej sieti serverov (DMZ), opísaný problém by nevznikol.

Riešenie 1: Úprava NAT (Hairpin NAT)

Toto riešenie rieši samotnú podstatu problému. Musíme dosiahnuť, aby server odpovedal smerovaču a nie priamo počítaču. Musí si „myslieť“, že paket pochádza zo smerovača. To dosiahneme tak, že okrem zmeny cieľovej adresy (čo robí dst-nat) zmeníme aj zdrojovú adresu - teda pre toto spojenie vykonáme aj source NAT.

V praxi stačí do reťazca srcnat pridať všeobecné pravidlo: Ak požiadavka prichádza z LAN a aj smeruje do LAN (konkrétne na server), vykonaj maškarádu alebo src-nat zo svojej LAN adresy. Serveru potom príde paket z IP adresy smerovača a jemu aj odošle odpoveď - smerovač ju prijme, v tabuľke spojení nájde pôvodného odosielateľa a vráti mu odpoveď. Tomuto riešeniu sa hovorí Hairpin NAT, pretože tok dát pripomína vlásenku (ohnutý drôtik na upevnenie ženského účesu) - ide z LAN do smerovača a hneď sa otáča späť do LAN.

vlásnička Čínskej dynastie Tang (roky 618 až 907, vtedy ešte nebol NAT)

Riešenie 2: Lokálne DNS (Split DNS)

Predošlé riešenie je síce funkčné, ale pomerne neefektívne - pri jednoduchej LAN komunikácii zbytočne zaťažujeme smerovač a aj káble vedúce k nemu. Pokiaľ často prenášame veľa údajov medzi LAN klientmi a serverom, bolo by nežiaduce.

Preto je vhodné problém riešiť elegantnejšie - presvedčiť počítač, aby požiadavku neposielal smerovaču, ale priamo serveru. To dosiahneme jednoduchým trikom - na lokálnom DNS serveri vytvoríme pre doménové meno servera DNS záznam s jeho LAN adresou. V odbornej terminológii sa táto technika nazýva Split DNS (rozdelený DNS), pretože pre to isté meno vraciame inú IP adresu podľa toho, či sa pýta klient z internetu alebo z lokálnej siete.

Pre takýto lokálny DNS záznam je vhodné nastaviť krátku dobu platnosti, aby nezostával platný aj po presune počítača z našej LAN napríklad na mobilné internetové pripojenie.