Zveřejnění interní služby přes VPN site-to-site na ASA

Zveřejnění služby, která žije za VPN site-to-site, je jeden úkol s pěti body selhání a ty selhávají v pevném pořadí. Tunel se zvedne, překlad souhlasí, pobočka odpovídá a odpověď se vrací stejnou cestou. Když je cokoli z toho špatně, prohlížeč ukazuje totéž: spojení, které visí nebo se resetuje. Projděte seznam shora dolů a zastavte se u první kontroly, která selže.

Kontrola 1: tunel chrání adresu zdroje

Začněte tunelem, který už propouští provoz, a potom potvrďte, že adresa, kterou chcete zveřejnit, leží uvnitř chráněného rozsahu. Na ASA tento rozsah pochází z krypto ACL nebo z tras VTI a musí pokrývat skutečnou adresu zdroje, ne podsíť, kterou pobočka používá pro správu. Selektor, který zdroj mine, vám dá tunel, který je nahoře, a tok, který do něj nikdy nevstoupí.

Potvrďte to počítadly tunelu a tabulkou tras, než se dotknete překladu. Pokud zdroj není z hubu přes tunel dostupný, nic dalšího v tomto seznamu to nespraví.

Zastavte se tady, pokud se chráněný rozsah a adresa zdroje neshodují.

Kontrola 2: rozhodněte, jaký zdroj pobočka uvidí

Pobočka vidí buď původní adresu klienta, nebo přeloženou, a tato volba určuje zpáteční cestu. Zachování adresy klienta vypadá v logech zdroje čistěji, ale pobočka pak musí posílat odpovědi pro veřejné klienty zpět tunelem; běžná internetová výchozí trasa je pošle opačným směrem a spojení umře v jednom směru. Překlad zdroje na adresu, kterou pobočka už přes tunel směruje, tento požadavek odstraní.

Překlad také mění, co zdroj může logovat a s čím se mohou shodovat pravidla založená na zdroji. Pokud aplikace potřebuje znát člověka za požadavkem, patří to do autentizované reverzní proxy, ne do rozhodnutí NAT.

Kontrola 3: napište překlad proti skutečným rozhraním

ASA vyhodnocuje pravidla překladu v pořadí a hlásí, které se shodovalo, takže dvojice rozhraní uvnitř pravidla není kosmetická. Pravidlo napsané pro cestu zvenku dovnitř se neshoduje s tokem, jehož vstup a výstup se liší od těch, které jste předpokládali.

Cesta, kterou stavíte, má čtyři úseky a všechny čtyři musí souhlasit:

Berte rozsahy v té tabulce jako zástupné hodnoty. Důležité je, že tuple po překladu je adresa, kterou pobočka přes tunel přijímá, a že reverzní mapování existuje ve stavu NAT, aby se odpověď na cestě ven obnovila.

Kontrola 4: omezte přístupové pravidlo na zveřejněný port

Zveřejněte port, ne hostitel. Pravidlo, které povolí zdroj na každé službě, promění jednu zveřejněnou aplikaci v cestu ke všemu, co zdroj provozuje, včetně rozhraní pro správu, které jste záměrně drželi mimo internet. Povolte zveřejněný port z přeloženého zdroje ke zdroji a administrativní služby nechte na jejich cestě jen přes VPN.

Zkontrolujte zároveň pořadí pravidel. Široké povolení nad vaším konkrétním pravidlem dělá konkrétní pravidlo neviditelným.

Kontrola 5: vystopujte jeden požadavek a jeho odpověď

Nezačínejte prohlížečem, protože prohlížeč skrývá, který úsek selhal. Vystopujte tok na hubu a přečtěte výsledek, než něco změníte.

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

Stopa uvádí, který překlad se shodoval, které přístupové pravidlo tok povolilo nebo zamítlo a zda byl paket směrován do tunelu. Pokud ukazuje, že tok vychází z rozhraní, které jste nečekali, dvojice rozhraní v pravidle NAT je špatná. Pokud ukazuje zamítnutí, pořadí pravidel je špatné. Pokud dorazí do tunelu, ale zdroj nikdy neodpoví, problém je ve zpáteční cestě pobočky.

Potom pošlete jeden skutečný požadavek zvenku a potvrďte, že odpověď se vrací stejným tunelem. Zaznamenejte zveřejněnou položku, překlad, chráněnou dvojici adres a zpáteční trasu jako záznam o zveřejnění.