kafi

Dokładnie taka, jak w dokumentach rejestrowych firmy - czyli dla jednoosobowej DG właśnie coś w rodzaju "ABC Jan Nowak". Co do innych form - to w Polsce spółkami kapitałowymi są spółka z ograniczoną odpowiedzialnością i spółka akcyjna. Inne są osobowe i w nazwie powinny mieć nazwisko conajmniej jednego ze wspólników.

Podziel się zatem swoją metodologią tunelowania ruchu z VPS we Francji do serwera w DC w Polsce. Z chęcią potestuje to u siebie

Problem jest taki, że 1) nie w każdym przypadku tunelowanie można zrobić bez bardzo dziwnych komplikacji - VMware ESXi jest tego najlepszym przykładem; 2) nawet jeśli - to w sieci OVH z WAW1 do RBX opóźnienie wynosi ok. 20ms. Po co więc wprowadzać dodatkowe +20ms (no i jeszcze klient końcowy zamiast ruch zakończyć w Warszawie to łączy się do RBX, więc pewnie z kolejne 20ms więcej). Moje testy na Neostradzie dawały pingi bliskie 100ms. Do zabawy może być, na produkcję już trochę gorzej. PS: Co ma ATMAN i rzekome z nim przeboje do routingu adresów IP w sieci OVH ?

Czemu więc w całości dokumentacji (to jest kilka miejsc) zaznaczone jest wyraźnie, że weryfikacja telefoniczna jest w języku angielskim?

Ale ty nie masz zmieniać adresu MAC dla adaptera vmnic0, ale adres MAC interfejsu managementowego vmk0 - a to drobna różnica Przez polecenia CLI nie udało mi się tego ustawić, ale edytując plik konfiguracyjny jak najbardziej.

esxi6 - ta instalowana przez ovh Bingo! Czemu więc sukces jest połowiczny? Jeśli przygotujesz sobie wcześniej intranet na vmk1 (działanie tego jesteś w stanie przetestować wcześniej), to nie ma bata - musi wszystko pójść OK i robiąc NAT albo VPN dostaniesz się do tej intranetowej sieci

@ksk: 1) Karta sieciowa hypervisora podpięta jest pod vSwitch0. vSwitch1 nie jest podpięty do żadnej karty sieciowej (praca jako local intranet) 2) Na Mikrotiku 3) Po NAT nie wiem, ale po VPN IPsec over L2TP jak najbardziej. @mariaczi - u mnie eth0/1 pojawia się pod opisem wirtualnej maszyny, więc logicznym się dla mnie wydawało, że to jej i tylko jej właśnie dotyczy. Kluczowym elementem całej układanki jest zmiana adresu MAC na vmk0. Reszta jest tylko po to, aby nie stracić managementu hypervisora.

Troszkę odkopując temat - udało mi się zrobić taką konfigurację z metarouterem. Tak w skrócie: vSwitch0 - VM Network: External Network - VMkernel: VMkernel External [na początku ustawiony statycznie zewnętrzny adres IP] vSwitch1 - VM Network: Internal Network - VMkernel: VMkernel Internal [192.168.0.1/24] Wirtualna maszyna routera: - eth0: local [192.168.0.254/24] - adres MAC - autogenerowany przez VMware - eth1: wan [adres.ip.wan/24] - adres MAC taki sam, jak karty sieciowej serwera default gateway: adres.ip.wan.254, maskarada na wyjściu przez eth0 Ważnym jest, aby ustawić natychmiastowe automatyczne startowanie tej maszyny w pierwszej kolejności oraz upewnić się, że obie karty sieciowe mają włączone "Connect at startup". Trzeba się też upewnić, czy w systemie-gościu - wirtualnym routerze interfejs ma poprawny adres MAC. I teraz cała esencja sprawy: otwieramy sesję KVM, włączamy lokalną konsolę i przechodzimy do niej. Testujemy przy pomocy ping czy mamy łączność z adresem 192.168.0.254. Jeśli tak, sprawdzamy, czy działa sesja SSH z hypervisora do wirtualnej maszyny. Jeśli tak, to w pliku konfiguracyjnym ESXi (do edytowania niestety pozostaje tylko vi) należy zmienić - adres MAC sieci vmk0 na jakiś fikcyjny, - bramę domyślną na 192.168.0.254, - występujący tam adres WAN IP serwera na jakiś losowy (np. początek zmienić ze 137. na 10.) - w pliku jest kilka jego wystąpień całość zapisać i zrestartować serwer fizyczny. Jeśli wszystko zostało zrobione poprawnie, na zewnętrznym adresie IP powinien być osiągany nasz metarouter.

Nie do końca. Jeżeli zmienisz tylko rekordy DNS i nie wyłączysz obsługi poczty dla domeny, to będziesz miał problem z "local delivery" - poczta z innych utrzymywanych na tym serwerze domen do tej jednej nie wyjdzie poza serwer i będzie odbijana z adnotacjami najprawdopodobniej "mailbox not found".

apt-get php5-imap A następnie /etc/init.d/apache2 restart

No tak. I on zezwala na wysyłkę maili tylko i wyłącznie z zoho. Jak chcesz wysyłać maile ze swojego serwera www funkcją mail() a nie autoryzacją SMTP, to musisz dodać to do rekordu SPF np tak: v=spf1 ip4:212.91.26.155 mx include:zoho.com ~all

Źle czytałeś. Musisz zmodyfikować rekord dotyczący SPF a nie DKIM.

Rekord SPF upoważnia do wysyłki tylko zoho, a nastąpiła próba wysyłki z adresu IP 212.91.26.155, który to wg SPF nie jest upoważniony. A ten adres to adres serwera WWW - przypuszczalnie wysyłka wiadomości funkcąj mail()

VMware nie pozwoli ci na zmianę MAC na adres interfejsu sieciowego hosta .

Twoja wirtualna maszyna PFSENSE ma nieautoryzowany adres MAC, więc jest wycinany przez infrastrukturę OVH. A VMware tracisz, no bo zmieniasz mu adres na prywatny i nie możesz się do niego dobić .

Wykonujesz, jeśli łaskawie wirtualna maszyna ci go pozwoli wykonać tu-i-teraz a nie za 200 ms, kiedy przestanie już być potrzebny. Systemy krytyczne to nie takie, w których jest niewystarczająca moc obliczeniowa. To systemy, dla których kluczowy jest czas i gwarancja wykonania/przetworzenia operacji w stałym, konkretnie zdefiniowanym czasie. A tego - czyli gwarancji reżimów czasowych - żaden język oparty na wirtualnej maszynie ci nie zapewni, bo nie jest z samej natury działania w stanie A odpowiadając na pytanie autora - to z książek drukowanych to raczej ciężko coś polecić. Na potrzeby szkolne wystarczy pierwszy lepszy kurs programowania, w którym to omówione zostaną podstawy - podstawowa składnia, instrukcje warunkowe, pętle, procedury, funkcje.

Czy trzeba do tego jakiś dodatkowy komentarz?

Umieść plik .htaccess

Ustaw na drugiej sieciówce adres 10.0.0.2 z maską 255.0.0.0 bez bramy domyślnej, zrestartuj Windowsa i wtedy spróbuj wejść do ustawień bindowania.

Spróbuj https://johndelizo.wordpress.com/2013/03/09/dhcp-binding-only-to-one-interface-card/

I nadal (zakładając, że drugi interfejs nie jest podłączony do niczego) DHCP przestaje na pierwszym przydzielać adresy?

Ustaw dla testów na tej drugiej sieciówce adres IP z jakiejś zupełnie innej podsieci i sprawdź, czy też wtedy będzie głupieć...

Napisz, do czego każda z kart sieciowych jest podłączona i jakie adresy IP są ustawione na poszczególnych interfejsach.

Skoro nie raczysz przedstawić swojej arcytajnej topologii, to jak widać nikomu nie chce się wróżyć, chociażby co to jest wspomniane w push route 192.168.1.0/24 ...

Szklana kula niestety nie jest w stanie wywróżyć topologii twojej sieci i adresacji poszczególnych węzłów...