iptables/masquerading vs. IPSec

Правила iptables на роутере устанавливаются вот таким скриптом:

#!/bin/sh

ipt="/sbin/iptables"

pri="0:1023"
unpri="1024:65535"
ftppassive="60000:65535"

# Flush all
$ipt  -F
$ipt  -F -t nat
$ipt  -F -t mangle
$ipt  -X
$ipt  -X -t nat
$ipt  -X -t mangle

# Default policies
$ipt  -P INPUT       DROP
$ipt  -P FORWARD     DROP
$ipt  -P OUTPUT      ACCEPT

# Reject invalid packets
$ipt  -A INPUT    -j DROP     -p tcp -m state --state NEW ! --syn
$ipt  -A INPUT    -j DROP     -m state --state INVALID

$ipt  -A FORWARD  -j DROP     -p tcp -m state --state NEW ! --syn
$ipt  -A FORWARD  -j DROP     -m state --state INVALID

# Accept all packets on loopback
$ipt  -A INPUT    -j ACCEPT   -i lo

# Accept packets of established connections
$ipt  -A INPUT    -j ACCEPT   -m state --state ESTABLISHED,RELATED
$ipt  -A FORWARD  -j ACCEPT   -m state --state ESTABLISHED,RELATED

# Create new chains
$ipt  -N lan_in
$ipt  -N mks_in
$ipt  -N all_in
$ipt  -A INPUT    -j lan_in   -i eth0
$ipt  -A INPUT    -j mks_in   -i eth1

#########################################################
########################## LAN ##########################
#########################################################

# DHCP server
$ipt  -A lan_in   -j ACCEPT   -p udp -m state --state NEW --sport 68 --dport 67

# DNS server
$ipt  -A lan_in   -j ACCEPT   -p tcp -m state --state NEW --dport 53
$ipt  -A lan_in   -j ACCEPT   -p udp -m state --state NEW --dport 53

# FTP server
$ipt  -A lan_in   -j ACCEPT   -p tcp -m state --state NEW --sport $unpri --dport 21
$ipt  -A lan_in   -j ACCEPT   -p tcp -m state --state NEW --sport $unpri --dport $ftppassive

# HTTPs server
$ipt  -A lan_in   -j ACCEPT   -p tcp -m state --state NEW --sport $unpri --dport 443

# HTTP proxy
$ipt  -A lan_in   -j ACCEPT   -p tcp -m state --state NEW --sport $unpri --dport 3128

# Incoming ping
$ipt  -A lan_in   -j ACCEPT   -p icmp -m state --state NEW --icmp-type echo-request

# Samba server
$ipt  -A lan_in   -j ACCEPT   -p tcp -m state --state NEW --sport $unpri --dport 445 #smbd
$ipt  -A lan_in   -j ACCEPT   -p tcp -m state --state NEW --sport $unpri --dport 139 #nmbd
$ipt  -A lan_in   -j ACCEPT   -p udp --sport 137 --dport $unpri                      #nmbd
$ipt  -A lan_in   -j ACCEPT   -p udp --sport 137 --dport 137                         #nmbd
$ipt  -A lan_in   -j ACCEPT   -p udp --sport 138 --dport 138                         #nmbd

#########################################################
######################### MKS ###########################
#########################################################

#########################################################
####################### INTERNET ########################
#########################################################

#########################################################
########################## ALL ##########################
#########################################################

# SSH server
$ipt  -A all_in   -j ACCEPT   -p tcp -m state --state NEW --sport $unpri --dport 4589 # =)

#########################################################
####################### ALL CHAINS ######################
#########################################################

# Jump to all_in/all_out chains
$ipt  -A lan_in   -j all_in
$ipt  -A mks_in   -j all_in

$ip6t -A inet_in  -j all_in

# Reject all unknown packets
$ipt  -A all_in   -j DROP

$ip6t -A all_in   -j DROP


#########################################################
########################### NAT #########################
#########################################################

# Accept forwarding from LAN to WAN
$ipt  -A FORWARD -j ACCEPT -i eth0 -m state --state NEW

# NAT to MKS
$ipt  -A POSTROUTING -t nat -o eth1 -j MASQUERADE

# Transparent HTTP proxy
$ipt  -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-ports 3128

# Drop all unknown forward packets
$ipt  -A FORWARD  -j DROP

#########################################################
#########################################################
#########################################################

/etc/init.d/iptables save

Что нужно суда добавить, чтобы нормально работал IPSec? Я уже мозг
сломал нафиг. В интернете куча обрывочной информации, сводящейся к
тому, что прокидывание IPSec через NAT - это Большой Геморрой. Я
пробовал смотреть tcpdump'ом что происходит в сети при попытке
коннекта - клиент обменивается с сервером UDP-пакетами на порт 500. И
туда и обратно эти пакеты проходят нормально, никакого другого
трафика не наблюдается.

Помогите пожалуйста, я уже в панике =).

Тут iptables абсолютно не причём... Дело в двойном(!) NATировании. То есть IPsec со скрипом, но работает с NAT'ом (IPsec-travesal), но двойное натирование сводит всё на нет.

Но, чтобы не нарушать мой девиз "нет ничего невозможного", могу предложить по душам (с пивом или паяльником - на твой выбор) поговорить с владельцем сервера (4) об установке на том сервере openvpn... Решение кроссплатформенное, NAT-независимое. То что надо.

Ещё решение: выбить из провайдера реальный IP. с прямым роутингом к нему (безо всяких NATов).

>> Дело в двойном(!) NATировании. То есть IPsec со скрипом, но работает с NAT'ом (IPsec-travesal), но двойное натирование сводит всё на нет.

А почему? Что такое в принципе работы NAT не даёт пройти IPSec'у через 2 и более NAT'ов? Я вот это не понимаю... Причём самое интересное, что насколько я понял логи и то что мне выдаёт tcpdump - данные и не начинают идти. Соедиение рвётся на этапе авторизации/обмена ключами/etc. Но ведь пакеты то проходят свободно =\...

Это не принцип работы NAT, а принцип работы IPsec с вычислением контрольных сумм на пакеты. Пакеты проходят свободно, спору нет. Но на этапе проверки подлинности канал не устаавливается. IPsec-travesal вроде бы решает решает эту проблему, но если в пути меняется хотя бы один битик в пакете - соединение не может быть установлено (не сходится контрольная сумма). Второе натирование меняет, как минимум, source address.

IPSec гарантирует не только шифрование канала, но и неизменную доставку (по аналогии с цифровой подписью).

vtun (tap) и виртуальный езернет линк между офисной сеткой и (4)server не спасут ли вас?

>> vtun (tap) и виртуальный езернет линк между офисной сеткой и (4)server не спасут ли вас?

Я как-бы не могу вмешиваться в дела провайдера (3) и администрации сервера (4) =). Или я не понял что вы предлагаете.

>> Второе натирование меняет, как минимум, source address.

А первое разве не меняет?

Ну попросите у провайдера ещё один ip-адрес (который он будет NATить), обычно второй то адрес они дают, хоть и не очень охотно :( На Линуксе пропишите proxy arp для этого второго адреса и маршрут на этот адрес во внутренную сеть, а компу с вендой дайте этот адрес.

ну не совсем так...
просто в пакетах isakmp указывается payload, т.е. какой именно трафик должен шифроваться, а при нат естественно ip адреса пиров и то что в payload не овпадает, поэтому сервер и отвечает отлупом.

>> Ну попросите у провайдера ещё один ip-адрес (который он будет NATить), обычно второй то адрес они дают, хоть и не очень охотно :( На Линуксе пропишите proxy arp для этого второго адреса и маршрут на этот адрес во внутренную сеть, а компу с вендой дайте этот адрес.

Это тоже проблематично... Там подключение в сети хитро - по витой паре, но с авторизацией через WPA (у меня через wpa_supplicant -Dwired работает). Т.е. два IP там не получить. Зато они по слухам могут выдать белый IP (через PPtP подключение), если написать заявление и дополнительно заплатить - по этому направлению видимо я и пойду =).