Jeżeli jesteście administratorami w innowacyjnym, prężnie rozwijającym się przedsiębiorstwie. Pracujecie w młodym i dynamicznym zespole, a wasza spółka właśnie weszła na Newconnect albo wejść ma wkrótce, to wiecie na pewno, że słowa takie jak inwestycje, pieniądze, potrzeby czy też rozwój będą równie niezrozumiałe dla zarządu, co zdanie w suahili – usiokuwa na rundo la watu wenye tamaa.

Tak, więc zakładam, że jeżeli wasza dynamicznie rozwijająca się spółka ma odziały rozsiane po okolicy, to są one oparte na jednym esx’ie i jak nikczemnie podejrzewam maszynie wirtualnej z linuksem robiącej za router. W takim to pre-enterprise środowisku administratorzy muszą sobie radzić… jak w dżungli. Każdy wiszący w bezładzie kabel potrafi zabić, każdy opuszczony komputer pod biurkiem strzeże swoich produkcyjnych aplikacji jak matka młodych, a ostatniego administratora, jakiego tu widziano programiści ugotowali w kotle i zżarli. Proza życia można by rzec – większość z nas przez to przeszła lub aktualnie przechodzi. Ale tak jak mówię, trzeba zacisnąć zęby i sobie radzić. Pamiętajmy, bowiem, że jeden fałszywy ruch, jedno potknięcie i niechybnie zrobią z nas bulion.
Tak wiec w ramach braterskich porad, szybki przepis na zrobienie prostego, bezpiecznego, zdalnego dostępu, na żądanie (bez ipseca) do zagubionych w buszu programistycznych wiosek i działających tam esxów.

Dokonamy tego prze pomocy tunelu SSH. Czyli będziemy się łączyć z wspomnianym linuksowym serwerem poprzez SSH i tworzyć przy pomocy tego protokołu tunele. Wszystko wykonujemy za pomocą Putty i małego tricku.

Tak wiec otwieramy Putty i edytujemy, lub tworzymy nowe połączenie. Przed jego zapisaniem przechodzimy do zakładki na samym dole, w menu po lewej stronie – SSH -> Tunnels i dodajemy tu porty potrzebne do działania vSphere Clienta – 443, 902, 903.

Celem wykonania tego, w polu Source port wpisujemy 443 a, w Destination podajemy IP w sieci lokalnej za firewallem wraz z portem – w przypadku mojej wioski 10.1.1.10:443. Klikamy Add i analogicznie postępujemy dla dwóch pozostałych. Dzięki tej operacji powinniśmy uzyskać coś podobnego do obrazka poniżej:

Następnie, kiedy klikniemy Save i Open, zalogujemy się na adresie naszego localhosta będziemy mieli zmapowane porty zdalnego ESX’a.

Wydawałoby się, że teraz niema nic prostszego niż uruchomienie vSphere Clienta i wpisanie 127.0.0.1, oraz połączenie z naszym ESX. Gdy jednak tego spróbujemy, zaskoczy nas taki oto komunikat:

Dzieje się tak, ponieważ vSphere Client automatycznie z IP próbuje rozwiązać nazwę. Musimy wiec go nieco oszukać. Uruchamiamy notatnik z prawami administratora i edytujemy plik C:\Windows\System32\drivers\etc\hosts i dodajemy tam linijkę:

127.0.0.1 esxi01.corp.cmentarnapolka.pl esxi01

Następnie w vSphere Client wpisujemy zamiast 127.0.0.1 nazwę esxi01.corp.cmentarnapolka.pl, łączymy się i voilà!

ps. Jak słusznie zauważył w komentarzach Marcin Rybak na serwerze SSH trzeba mieć uruchomiony  TCP Forwarding.

About the author

Bloger i niezależny konsultant z wieloletnim doświadczeniem w branży IT. Specjalizujący się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VCP oraz VMware vExpert.
6 Responses
  1. jest i na to obejście – mapowanie do 127.0.0.2 i dalszych adresów (dzieki temu – możemy przy jednym połączeniu SSH skonfigurować dostęp do większej ilości hostów).

    no i na serwerze SSH trzeba mieć wklikany TCP Forwarding 🙂

  2. Osobiscie nad tunelami ssh i ipsec preferuje OpenVPN. Wydzielony host oparty na odpadkach zasobowych, samopodpisane certyfikaty i ew. client-to-client. Wrzucam tam to do czego potrzebuje dostep. prosciej niz z ipsec, niezawodniej niz tunelami na ssh.

  3. ml

    No tak… wiesz sposobów jest wiele, ale mi tu bardziej chodziło o rozwiązanie ad-hoc. OpenVPN, nie dużo, ale jednak trzeba konfigurować. Tunel po SSH to w zasadzie nie konfiguracja a klikacja 😉

Leave a Reply