witam przede wszystkim 
PTP to mam rozumieć chodzi Ci o protokół PPP? Mikrotik udostępnia dokumentację i tam znajdziesz jak skonfigurować protokół PPP.
W Linuksie możesz zastosować policy based routing. Na stronach CentOS albo RedHat powinno to być ładnie wyjaśnione.
IPTables nie ma tu nic do routingu, iptables ma za zadanie filtrować ruch sieciowy (zapora).
Jak już coś próbowałeś zrobić, to wklej konfigurację z Mikrotika i pokaż co masz zrobione na CentOS.
Edycja:
Zapomniałem dodać, że oprócz topologii fizycznej przydałaby się jeszcze topologia logiczna, bo sam opis sieci jest trochę chaotyczny.
chodzi mi o łącze punkt-punkt a nie PPP/PPTP.
Czyli ruch wypycham routem, a nie muszę rekonfigurować iptables ? nat/postrouting ?
Zrobiłem update rysunku:
Oczekiwania:
-
kiedy HOST_A chce korzystać z internetu - łaczy się przez Internet_PUBL,
-
kiedy HOST_A chce połączyć się łączem punkt-punkt do hosta po 2 stronie np. 172.16.20.15 musi wyjść łączem punkt-punkt przez Mikrotika,
-
na Centosie nie bardzo mogę zrobić restart usługi network
Czy taki schemat jest bardziej przejrzysty ?
Co do konfiguracji jeszcze jej nie mam, znalazłem dopiero odpowiedni moim zdaniem sprzęt: RB2011UAS-RM
http://www.interprojekt.pl/wiki/Wiki.jsp?page=RTB-RB2011UAS-RM
Co o nim sądzisz ?
Może zapytam tak, to ma być łącze punktowe? Jeśli tak, to jaki chcesz stsosować protokół skoro nie PPP (PPTP to zupełnie co innego). Jeszcze inaczej, to ma być sieć rozgłoszeniowa czy nierozgłoszeniowa?
Po co Ci NAT skoro łączysz dwie sieci prywatne? No chyba że nie chcesz dodawać tras do sieci na routerze? Poza tym NAT można załatwić teraz też przez iproute2.
Widzę, że zmieniłeś trochę topologię. Problem jest teraz taki, że w sieci masz dwa routery, czyli dla hosta to są dwie bramy i teraz host (albo routery muszą się jakoś dogadać) musi na jakiejś podstawie zdecydować, którą bramą chce wysłać pakiety. Nie chcesz co prawda restartować sieci (choć nie musisz restartować całej usługi, możesz to zrobić dla pojedynczego interfejsu), to zepnij łącza obu ISP do mikrotika i niech decyduje, którym łączem co ma iść. Bo teraz wygląda to tak.
HOST_A ma bramę ustawioną na adres CentOS.
HOST_A wysyła pakiety do internetu, wysyła je na CentOS.
CentOS przekazuje pakiety łączem INTERNET_PUBL
HOST_A wysyła pakiety do serwer w sieci 172.16.0.0, wysyła je do CentOS (bo nie wie, że ma wysłać do Mikrotika).
CentOS przekazuje pakiety do Mikrotika (jeśli ma trasę do tej sieci).
Mikrotik przekazuje pakiety do serwera przez łącze drugiego ISP.
Problem może pojawić się na etapie 5 (CentOS przekazuje pakiety do Mikrotika). Problem polega na tym, że routery są w tej samej sieci (normalne), ale CentOS odbiera i ma przekazać pakiety z tego samego interfejsu, a routing polega na tym, że pakiet odbierany jest na jednym interfejsie, a wysyłany na drugim. Jeśli na HOST_A działa też Linux, możesz spróbować policy based routing i określić co ma iść daną trasą. Jeśli Windows, to nie wiem czy da się zrobić coś podobnego. Ewentualnie jeśli ten switch jest zarządzalny, możesz zastosować VLANy.
Ewentualnie wróć do starej topologi fizycznej.
miałem taką koncepcję:
- ruch do hosta 172.16.20.15 kieruje (z Centos) na host 10.5.0.100 (Mikrotik), tam ustawiam routing do 172.16.20.15 poprzez sieć 10.250.250.0/30,
a. dodaje route add 172.16.20.0/27 via 10.5.0.100 - w takim razie to wystarczy tak ?
b. iptables FORWARD - potrzebny ? route sam to skieruje ?
- ruch na pozostałe sieci kieruje wg normalnych obecnych tras.
Co do Twojego opisu schematu kierowania ruchem - dokładnie tak :). Przełącznik nie jest zarządzalny, co do środowiska - zarówno Windows (ssh, scp) jak i Linux - środowisko mieszane.
Co do VLAN - boje się tam grzebać, restart czy to interfejsu czy usługi wątpliwy, dodatkowo chciałbym filtrowac ruch - po adresach MAC.
Tylko jak pisałem, tu pojawia się problem. CentOS może odrzucić pakiet, którego wyjściem jest interfejs wejściowy. Jak masz możliwość odpal wirtualne maszyny z CentOS i RouterOS (demo można pobrać ze strony Mikrotika), nie musisz używać przełącznika, ale jak chcesz możesz do tego wykorzystać, np. OpenvSwich. Jeśli zadziała, możesz zastosować takie rozwiązanie, ale w przyszłości może spowodować problemy. Taka sieć nie jest skalowalna.
Dlaczego się boisz? To jest jakaś maszyna krytyczna do działania sieci czy po prostu nie znasz CentOS? Jeśli system jest dobrze postawiony i masz w nim porządek, to nie powienien się wysypać. Z teg co opisujesz sieć jest raczej mała i przerwa w dostępie powinna być krótka.
Najlepiej jakbyś tę sieć zbudował tak (musiałbyś dołożyć do maszyny z CentOS jeszcze jedną kartę sieciową). Przy dwóch routerach możesz sobie porobić trasy statyczne, a jakbyś planował rozbudować sieć, to odpal sobie RIPa w wersji drugiej (tylko wyłącz sumaryzację tras). Jeśli nie chcesz dokładać karty do CentOS, to HOST_A podepnij do RBeka i na nim ustawiasz trasę do INTERNET_PUBL.
Jutro zainstaluje na fizycznej maszynie Centosa + Mikrotika. Podepnę to do jakiegoś switch (bez mgmt) i sprawdzę, tylko jak podepnę drugi net ? ;/
A jaką kartę proponujesz ? bo to serwer rackowy. na usb ? nie będzie kernel panic ? 
Masz na myśli coś takiego ?
Tak jest to maszyny krytyczna, NAT dla całej firmy, vpn, dns, monitoring, www.
Co do podpięcia HOST_A do Mikrotika - ten host potrzebuje również połączenia do Centosa (w sieci 10.5.0.0/22 są inne usługi, z których będzie korzystał). Będzie się przepinał ? Dziś w planach jest 10-15 osób, po nowym roku ok 50 osób.
Zatem user musi mieć dostęp zarówno do obecnej sieci jak i sieci za p-t-p.
RouterBoard to jednak urządzenie dedykowane, wiec może NAT i VPN lepiej było na nim realizować? Mikrotik wspiera chyba wszystkie rodzaje VPN. Na CentOS mógłbyś mieć DNS. Oczywiście o ile takie rozwiązanie wchodzi w grę.
Co do HOST_A to będzie miał normalnie dostęp do obu sieci jak podepniesz go do RBka, bo będzie routował ruch do odpowiednich sieci. RB to nie jest jakiś TP Link, żeby nie dało się tego nie zrobić.
Co do karty sieciowej, po obrazku wyobrażałem sobie, że CentOS stoi na zwykłym PC.
Sieć zawsze powinno się najpierw zaplanować, a później ją budować. Dziś podłączasz 10 - 20 osób, w planach masz już 50 hostów, za rok możesz mieć ich 200, a za 2 lata 2000, a za 5 lat może być już 20000 hostów w sieci. Nawet jeśli ta topologia z dwoma routerami na jednym przełączniku wypali, sieć nie będzie skalowalna i przy rozbudowanie zrobi Ci się bałagan, który będzie jeszcze trudniej ogarnąć. Pamiętaj, że jeśli w sieci pojawi się więcej routerów, w końcu zaczniesz używać protokołów routingu dynamicznego i wystarczy, że włączysz chociażby RIPv2, to sieć już na dzień dobry Ci padnie (zadziała mechanizm split horizon).
Na chwilę obecną jest serwer na Centosie, w przyszłości chcę go zmigrować, część usług na router hardwarowy (np. Mikrotik), część pozostanie na Centosie/inny. Czy dobrze wyczytałem, że Mikrotik ma limitowanie sesji OpenVPN do 200 ? ;/
Czyli biorąc pod uwagę podłączenie Mikrotika jaki wariant podpowiadasz ?
Taki jak ja zaproponowałem czyli, dokładam RB z adresem IP obecnej sieci i wypycham ruch do “nowej” podsieci przez dodanie na Centosie routa ? Czy aby na pewno nie będę musiał na Centosie (router) robić na iptables żadnych reguł ?
Jeśli w iptables masz jakieś reguły lub domyślnie, które są po instalacji systemu, to dajesz tylko reguły do łańcucha forward.
Do VLANów potrzebny Ci przełącznik zarządzalny. Jak będę miał troszkę więcej czasu (czwartek lub piątek), będę mógł coś więcej podpowiedzieć.
Mam NAT post/preroutingi + input/output/forward.
Reguła w stylu:
ok, czekam - dzięki.
Mam takowy zaraz za Centosem, ale to jakiś mało intuicyjny model Netgear.
EDIT:
zapomniałem dodać co najważniejsze, że nie mogę prezentować się adresem 10.5.0.0/22 po 2 stronie tylko inny, 10.4.0.0/24 - mogę to zrobić po stronie Mikrotika ?! \
druga strona będzie miała 10.3.0.0/24
druga strona korzysta z tej samej podsieci - zapomniałem o tym.
Wystarczy.
iptables -I FORWARD -s 10.5.0.0/24 -j ACCEPT
Tak, ustawiasz source nat na Mikrotiku.
Podaj topologię logiczną, będzie najlepiej się do tego odnieść.
Ogólnie, jeśli podłączyłbyś hosty do Mikrotika, masz trasę do sieci 172.16.0.0 i dodajesz trasę domyślną w kierunku internet_publ. Pakiety idące do serwera będą kierowane do sieci 172.16.0.0, a cała reszta przez trasę do dymyślną do internetu.