LINUX.ORG.RU

VPS NAT

 , ,


0

1

Арендовал VPS. Специально уточнил о доступности TUN/TAP и NAT. Поставил StrongSwan. Клиент подключается, получает ip. Доступ в интернет отсутствует. Сделал на VPS tcpdump icmp и пинганул с клиента 8.8.8.8

(xxx.xxx.xxx.xxx) - адрес VPS

09:37:18.468006 IP 192.168.11.1 > dns.google: ICMP echo request, id 1, seq 647, length 40
09:37:18.468092 IP xxx.xxx.xxx.xxx > dns.google: ICMP echo request, id 1, seq 647, length 40

Т. е. пакет приходит, маскарадится и уходит на адрес назначения. Обратно - тишина.

Что хорошего можно сказать провайдеру?

Конфиг strongswan

config setup
        # strictcrlpolicy=yes
        # uniqueids = no

conn %default
        dpdaction=restart
        dpddelay=30
        dpdtimeout=90
        fragmentation=yes
        #forceencaps=yes
        keyexchange=ikev2
        keyingtries=1
        ike=aes256-sha1-modp1024
        esp=aes256-sha1
        
conn income
        right=%any
        rightid=%any
        rightauth=pubkey
        rightsourceip=192.168.11.0/24
        
        left=xxx.xxx.xxx.xxx
        leftid="CN=xxx.xxx.xxx.xxx"
        leftauth=pubkey
        leftcert=server.crt
        leftsubnet=0.0.0.0/0
        type=tunnel
        auto=add

IPTABLES

export WAN=venet0
export FW=iptables
$FW -F
$FW -F -t nat
$FW -F -t mangle
$FW -X
$FW -t mangle -X
$FW -t nat -X

$FW -A INPUT   -j ACCEPT
$FW -A FORWARD -j ACCEPT
$FW -A OUTPUT  -j ACCEPT

$FW -t nat -A POSTROUTING -s 192.168.11.0/24 -j SNAT --to-source xxx.xxx.xxx.xxx












Последнее исправление: AndrK189100 (всего исправлений: 2)
Ответ на: комментарий от Pinkbyte

с клиента

12:57:31.864654 IP (tos 0x0, ttl 128, id 24155, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.11.1 > dns.google: ICMP echo request, id 1, seq 886, length 40
12:57:31.864721 IP (tos 0x0, ttl 128, id 24155, offset 0, flags [none], proto ICMP (1), length 60)
    xxx.xxx.xxx.xxx > dns.google: ICMP echo request, id 1, seq 886, length 40

с VPS

13:00:31.234370 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    xxx.xxx.xxx.xxx > dns.google: ICMP echo request, id 3539, seq 11, length 64
AndrK189100
() автор топика

Ядерный IPsec обычно не работает в OpenVZ, т.к. требует изменения конфигурации на хосте. Используйте юзерспейсный kernel-libipsec, он работает через TUN.

ValdikSS ★★★★★
()
Последнее исправление: ValdikSS (всего исправлений: 1)
Ответ на: комментарий от AndrK189100

А если через iptables поменять TTL пакетов, которые идут от клиента на 64?

Pinkbyte ★★★★★
()
Ответ на: комментарий от ValdikSS

Как-то странно. Туннель поднимается. Сам сервер доступен. Клиент по полученному ip доступен. Пакеты уходят…

Ну и упираться не вижу смысла. Взял VPS за копейки для тестов. Softether с Sec. NAT. работает без проблем.

Просто, стало интересно…

AndrK189100
() автор топика
Ответ на: комментарий от ValdikSS

У ТС вроде трафик уже на выходном интерфейсе в интернет видится в tcpdump. То есть ipsec от клиента к серверу как-то, но работает, а вот дальше - никак.

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Ну, и, это рабочий конфиг. На моей виртуалке Hyper-V(кстати, дедик от того же провайдера) все работает. Проблема, явно, в VPS. Мне, по сути, пофиг. Интересуюсь для общего развития. Для начала, решил спросить здесь. Далее, буду терзать провайдера на предмет, что они такого сделали, что не работает…

AndrK189100
() автор топика
Ответ на: комментарий от Pinkbyte

Да, так и есть. Проблема в policy на стороне хоста. Необходимо делать sysctl net.ipv4.conf.venet0.disable_policy=1 на хосте.

L2TP/IPsec на OpenVZ работать будет, т.к. в пределах сервера IPsec работает корректно, а этого достаточно для инкапсуляции L2TP в IPsec.

Чистый IKEv2 в туннельном режиме будет работать только с юзерспейсным kernel-libipsec.

ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS

Спасибо за пояснение - сам я очень давно работал с OpenVZ, таких деталей не знал.

Pinkbyte ★★★★★
()
Ответ на: комментарий от ValdikSS

Спасибо. Задам вопрос прову, на предмет… L2TP тоже, кстати, пытался настроить. Нет модуля ppp.

AndrK189100
() автор топика
Ответ на: комментарий от ValdikSS

Вы были правы. Провайдер подтвердил, что ipsec для VPS отключен. Предложил KVM. Спасибо.

AndrK189100
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.