cisco z nat i publiczny serwer za nim

mam router cisco, który robi NAT dla sieci 10.0.0.0

jeden z komputerów tej sieci ma dwa interfejsy logiczne (prywatny
10.0.0.x i publiczny A.B.C.x) i stoi sobie za tym routerem.

oczywiście router ma również interfejs logiczny w podsieci A.B.C.0, i
zasadniczo serwer publiczny był w pełni "publiczny", dopóki nie dostał
adresu 10.0.0.x. od tej pory najchętniej korzysta z NAT-u. konkretnie
chodzi o to, że połączenia inicjowane z tego komputera są widoczne dla
świata jako wychodzące z adresu NAT-owego, a ja bym chciał, żeby
serwer pozostał przy swoim adresie publicznym.

w jaki sposób mogę sprawić, żeby te połączenia były inicjowane z
adresu publicznego?

jako laik chwilowo ustawiłem po prostu wyższą metrykę dla bramy 10.0.0
niż dla A.B.C.0 - efekt jest, ale nie jestem pewien, czy to dobry
sposób. wolałbym jednak z klucza wyciąć to na routerze, ale nie bardzo
wiem, jak to zrobić. czy zdefiniować jakiś wpis w ACL?

obecnie wygląda on tak:
ip nat inside source list 100 interface Serial0.1 overload
access-list 100 permit ip 10.0.0.0 0.0.0.255 any
access-list 100 deny   ip any any

użyj translacji statycznej na routerze dla tego jednego adresu i usuń
adres publiczny z listy adresów komputera.

ip nat inside source static ...

Najwygodniej by było, gdybyś miał oddzielny adres ip dla tego komputera
z puli publicznej. Jeśli nie masz, to możesz próbować odwzorować poprzez
PAT na adres interfejsu szeregowego. Router najczęściej się zbuntuje, że
nakładają się adresy, ale jeśli usuniesz PAT dynamiczny, dodasz static i
znowu dynamiczny, to powinno działać. Najbezpieczniej wtedy użyć
translacji na port poniżej 1024 (np. na 80).

I tak dodatkowo:

Tutaj wystarczyłaby lista standardowa. I tak określasz tylko adresy
źródłowe. A druga linijka jest zbędna.

Jarek

mam. więc nie powinno być problemów. dziękuję.

co to jest standardowa lista?

przeklepałem ją skądś. pewnie ktoś uważał, że będzie bezpieczniej. :)

Lista o numerkach od 1 do 99 (plus zakres dodatkowy na dalszych
numerach). Filtruje tylko po źródłowych adresach IP, czyli w tej
sytuacji: access-list 1 permit 10.0.0.0 0.0.0.255


Pewnie ktoś zakończył edukację na Cisco Network Academy. Ewentualnie
umieścił, żeby widać było, że jest deny na wszystko. Niepotrzebnie, bo i
tak na końcu listy jest domyślna (niewidoczna) reguła "deny any".

Jarek

no tak. zrobiłem i działa. notabene: używałem tego polecenia, ale ze
wskazaniem tcp/udp i konkretnego portu, w celu jego przekierowania.
no, ale jakoś nie wiedziałem, że można polecieć po całości. dziękuję.

inna rzecz, że mój problem nie został rozwiązany tak, jak się tego
spodziewałem. ale ponieważ sprawa jest grubsza, przynajmniej dla mnie,
to może po kolei.

na routerze mam, tak jak piszesz, adres na interfejsie szeregowym. i
na niego robię nat z sieci wewnętrzenej 10.0.0.0. mam też 2 adresy
publiczne z jednej podsieci: jeden przypisany w cisco do fast eth 0, a
drugi do interfejsu rzeczonego serwera. w ten sposób serwer dostępny
był od zewnątrz. serwer dodatkowo ma adres z sieci 10.0.0.0, po którym
dostępny jest od środka.

kompy z sieci wychodzą na świat identyfikowane adresem serialowym, a
serwer - po adresie publicznym.

i jeszcze jeden istotny dla sprawy szczegół: aby można było dostać
odpowiedź z serwera po wołaniu go z zewnątrz, jego brama musi
wskazywać na interfejs routera.

no i teraz zachciało mi się vpn-a. serwer nie ma tej funkcjonalności,
więc za routerem postawiłem PC z IPCop-em (takie linuksowe distro
firewallowe).

IPCop ma dwa interfejsy: publiczny (red) i prywatny (green). bramą dla
red jest cisco (przez nat). port, na którym słucha vpn na interfejsie
red forwardnąłem na serial cisco. a kompom w sieci wskazałem interfejs
green jako bramę.

no i teraz łączę się z domciu z interfejsem ciscowym, który przerzuca
mnie na red - loguję się w vpn-ie i mogę nawiązać kontakt z
komputerami w sieci 10.0.0.0 (czyli tej samej co green), czyli
praktycznie z wszystkimi, z wyjątkiem... serwera. bo on ma bramę
ustawioną prosto na cisco, żeby mógł gadać z wywołaniami z netu. tzn.
pewnie on dostaje pakiety, ale odsyła je do cisco, czyli w kosmos.

jak mu ustawię bramę na IPCop green - to oczywiście wszystko pięknie
działa, ale nie można połączyć się z usługą dostępną bezpośrenio z
internetu, bo sytuacja jest taka sama, tylko odwrotna: cisco
statycznie przerzuca wywołania na jego interfejs 10.0.0.x, a on
odpowiada, ale na bramę IPCopa - czyli ponownie w kosmos.

czy jest jakiś sposób, żeby to pogodzić?

tak sobie myślę, że przecież vpn używa dodatkowej sieci pośredniej,
10.30.0.0 - i pewnie dodanie jakiejś trasy (bramy?) serwerowi dla
tejże sieci mogłoby rozwiązać sprawę, tylko nie bardzo wiem, jak to
zdiagnozować? Czy jeśli IPCop dostaje interfejs TUN 10.30.0.5, to dla
maszyny pingowanej z drugiego końca vpn-u, pakiety przychodzą właśnie
z tego adresu?

wszelkie rozwiązania mile widziane.

zrobiłem jeszcze taką sztuczkę magiczną. podwójny forward. serwerowi
wskazałem bramę green. a z drugiej strony (tzn. idąc od strony
internetu) zrobiłem taki manewr: porty z adresu publicznego są
forwardnięte na interfejs red IPCop-a. a z interfejsu red -
forwardnięte po raz drugi na interfejs 10.0.0.x serwera.

w ten sposób wszystko działa. dostępne są usługi serwera na intefejsie
publicznym, i jednocześnie jest on dostępny dla vpn, bo IPCop green
jest bramą. mogę też jednym ruchem zdecydować, czy ruch wychodzący
jest identyfikowany w sieci jako pochodzący z interfejsu szeregowego
cisco (podwójny nat) czy przez adres publiczny - zależnie od
konfiguracji interfejsu red (adres publiczny vs. prywatny).

tylko, że też jest problem. bo mi zależy na tym, aby oba rodzaje ruchu
(z serwera i z sieci 10.0.0.0) nie wychodziły tym samym nat-em. powód
jest prozaiczny: miałem kiedyś taką wpadkę, że jeden user,
zainfekowany trojanem pocztowym, skaził mi adres serialowy (nat) - bo
został on wpisany na spamlistę, jako źródło spamu. dlatego serwer (m.
in. poczty), i tylko on, musi być identyfikowany swoim adresem
publicznym, a ten musi być różny od adresu nat-owego na wypadek, gdyby
taka sytuacja mogła się powtórzyć, bo wypadki chodzą po ludziach, a
mnie nie stać na przestoje.

dlatego potrzebuję pomocy, bo skończyły mi się pomysły.

:)

[wielkie wycinanie]

Serwer powinien mieć gateway na adres eth0 routera. Dzięki temu będą Ci
funkcjonować połączenia do/z Internetu. Oddzielnie należy skonfigurować
na tym routerze przekazywanie ruchu VPN. Z jakiej puli dostajesz adres
po połączeniu przez tunel? Trzeba sprawdzić, czy serwer wie, że pakiety
kierowane do tej puli powinien przekazać do IPCop. Zastanawia mnie,
dlaczego możesz się połączyć do innych komputerów w swojej firmie, a nie
możesz akurat do tego. Coś mi się zdaje, że na serwerze masz coś
pokręcone z routingiem.

Jarek

no właśnie nie wiedział.

pokręcony nie był. po prostu automatyczny, a więc niepełny.

dzieki. :)