Witam wszystkich!

Zauważyłem, że coś ostatnio dzieje się na slacklist, wiec postanowiłem
poprosić kolegów o pomoc.
Mam router, który ma dynamicznie publiczne IP (neostrada) router ten
jest również bramą dla
klientów VPN. Dotychczas bramka VPN była wykorzystywana do forwardowania
połączeń na klienta VPN.
Uzyskiwałem to przez ustanowienie VPNa (openvpn+tap) i wydanie polecenia
na kliencie:

ssh -gNfR 2222:10.7.0.1:22 10.7.0.1 , gdzie
10.7.0.0/30 VPN, .1 - serwer i .2 klient

Dzięki temu wszytko ładnie grało i gra nadal. Postanowiłem przenieść ową
funkcjonalność na iptables
routera. Reguły jakie wprowadziłem:

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.7.0.2 -j MASQUERADE

oraz

iptables -t nat -A PREROUTING -p tcp --dport 2222 -j DNAT
--to-destination 10.7.0.2:22

Działają one prawdopodobnie tak jak powinny, ale nie tak jak ja bym
chciał. (;
Pewnie wiecie już o co chodzi. Klient ma również dostęp do internetu -
stałe publiczne IP, z brakiem
możliwości nawiązywania połączeń ze Świata, ot taka polityka adminów z
akademików. Dzięki tunelowaniu
przez ssh uzyskiwałem połączenie na kliencie z źródłowym adresem bramki
VPN, dzięki czemu pakiety z klienta
wracały odpowiednim interfejsem (tap). Po zastosowaniu w/w regułek do
klienta dochodzi pakiet TCP SYNC,
ale z publicznym adresem maszyny, która łączy się przez forwardowany
port na bramce. Pakiet nie może wrócić
tą samą drogą ze względu na wpis domyślnej bramy w tablicy routingu na
kliencie. Klient odpowiada łączącej
się maszynie ze swoim adresem i tu się wszystko sypie dlatego, że adresy
docelowe na sockecie maszyny łączącej
się różnią. Jak mogę uzyskać podobny rezultat do tunelowania przez ssh
wykorzystując iptables bramki VPN?

e.
Received on Sat Dec 8 09:00:50 2007