Corbina vs Arch Помогите настроить VPN

Что касается роутов (а не рутов) – придётся узнать, это базовые знания, без которых всё превращается либо в тупое выполнение готовой инструкции, которая не может предусмотреть все возможные местные проблемы, либо в бесконечное шаманство в надежде на везение.

Все идеи уже изложены.
Одной строчкой не обойдётся, поскольку и L2TP, и PPTP предполагают уже настроенную обычную сеть, поверх которой они подключаются к заданному серверу, который у провайдеров к тому же обычно задаётся через DNS, а не по прямому IP.

Сценарий подключения примерно такой:
Сначала система получает через DHCP свой IP-адрес, адрес шлюза и адреса локального DNS.
В общем случае это стандартная процедура, для которой достаточно network в DAEMONS и строчки interface=eth0 в /etc/rc.conf .
Когда это прописано, network запущен, нужные роуты должны прописаться сами, и DNS тоже.
Для проверки можно посмотреть ip addr , ip route и cat /etc/resolv.conf после этого.

Только когда это сделано и проверено, можно переходить к установке PPTP или L2TP-туннеля с провайдерским сервером. Кстати, перед этим не мешало бы его пропинговать.
Когда-то настраивал соединение по информации с форума билайна, с тех пор оно нормально работает. Столкнулся с проблемами дважды: первый раз долго не мог понять, почему соединение часто рвется сразу после поднятия с огромным количеством TX packets в выводе ifconfig и второй - когда переходил на так называемый L2TP-тариф (этот вопрос уже обсуждался в треде, он решился добавлением “tx bps = 100000000” в /etc/xl2tpd/xl2tpd.conf).

Неправильный маршрут, приводящий к “закольцовыванию” соединения я удаляю скриптом, находящимся в /etc/ppp/ip-up.d/

bad_ip=`ifconfig ppp0 | grep 'destination' | awk '{ print $6}'`
ip route del $bad_ip dev ppp0

В принципе основная таблица роутинга должна содержать маршрут через интерфейс ppp0 с меньшей метрикой, чем через eth0.
route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     100    0        0 ppp0
0.0.0.0         10.57.0.1       0.0.0.0         UG    202    0        0 eth0
<остальные записи удалил как несущественные>


Если нужно, могу выложить конфиги xl2tpd, содержимое /etc/rc.conf и скрипты, исполняющиеся после поднятия/разрыва соединения. Ничего особенного там нет, вся информация взята с форумов.
Подскажите как вообще настроить подключение по l2tp?
NoVASpirit, соединение поднимает демон xl2tpd, он есть в репозиториях arch'a и устанавливается штатно
pacman -Sy xl2tpd
Соответствующим образом правятся конфигурационные файлы:
/etc/ppp/options.xl2tpd
lcp-echo-interval 10
lcp-echo-failure 2
name [email protected]
remotename l2tp
ipparam corbina
connect /bin/true
mru 1460
mtu 1460
nodeflate
nobsdcomp
persist
maxfail 0
nopcomp
noaccomp
noauth

/etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# client        server  secret                  IP addresses
"[email protected]"       *       "P@sSw0Rd"

/etc/xl2tpd/xl2tpd.conf
[global]
access control = yes
auth file = /etc/ppp/chap-secrets
[lac corbina]
lns = tp.internet.beeline.ru
redial = yes
redial timeout = 10
require chap = yes
require authentication = no
name = [email protected]
ppp debug = no
pppoptfile = /etc/ppp/options.xl2tpd
require pap = no
autodial = yes
tx bps = 100000000

Подобной настройки достаточно для поднятия соединения при нормально работающей локальной сети, т.е. предполагается, что сетевые настройки на интерфейсе ethX сделаны руками или DHCP, в /etc/resolv.conf есть информация о DNS Билайна

nameserver 85.21.192.3
nameserver 213.234.192.8
и адрес tp.internet.beeline.ru доступен для подключения.

В директории /etc/ppp/ip-up.d находятся скрипты, выполняющиеся при поднятии l2tp. Сюда можно положить файлик routing.sh примерно такого содержания:

#!/bin/bash
#
PATH=/bin:/sbin:/usr/bin:/usr/sbin
# Определяем IP-адрес нашего основного шлюза
GATEWAY=`ip route | grep 'default via' | awk '{ print $3}'`
# L2TP-сервер
route add -host tp.internet.beeline.ru gw $GATEWAY
# Серверы DNS и локальная сеть провайдера Билайн
route add -host 213.234.192.8 gw $GATEWAY
route add -host 85.21.192.3 gw $GATEWAY
route add -net 10.0.0.0 netmask 255.0.0.0 gw $GATEWAY
# Добавляем маршрут через устройство ppp0 с более высоким приоритетом (меньшей метрикой), чем маршруты, раздаваемые по DHCP провайдера
route add default dev ppp0 metric 100
В данном файле мы определяем маршруты до основных сервисов провайдера (DNS, сервер авторизации tp.internet.beeline.ru), ну и заодно говорим, что будем стучаться в сеть 10.0.0.0/8 не через VPN, а через провайдерский основной шлюз (у меня 10.57.0.1). И наоборот, на все ресурсы, до которых явно не определены маршруты с метрикой ниже 100, будем стучаться через устройство ppp0.

Для автоматического подключения после перезагрузки компьютера нужно добавить xl2tpd в файл /etc/rc.conf
DAEMONS=(... network xl2tpd ...)
user_256, коли ты расписал подробно “как”, маленькое дополнение: /sbin/route принадлежит core/net-tools, но net-tools может быть и не установлена, если не сложно, всё то-же самое, но применительно к iproute2
bobart
/sbin/route принадлежит core/net-tools, но net-tools может быть и не установлена, если не сложно, всё то-же самое, но применительно к iproute2
bobart, у команды route из net-tools есть одно маленькое, но существенное преимущество – она позволяет задать адрес по имени хоста. Никакой замены этому её свойству во всей группе “base” я не знаю. Можно получить айпи по имени хоста отдельно, от команды host, к примеру. Но и host, и её аналоги dig и nslookup входят в пакет dnsutils, который ТОЖЕ может быть НЕ установлен, так как ни в какую группу не входит.

Тот же скрипт от user_256, только с “выпиленным” net-tools, и с зависимостью от dnsutils. Оцените разницу :)
#!/bin/bash
#
PATH=/bin:/sbin:/usr/bin:/usr/sbin
# Определяем IP-адрес нашего основного шлюза
GATEWAY=`ip route | grep 'default via' | awk '{ print $3}'`
# L2TP-сервер
SERVER=tp.internet.beeline.ru
# Читаем вывод команды host
set -k `host -t a $SERVER`
# Если первые три слова "$SERVER has address", значит четвёртое будет IP сервера
[[ "$1 $2 $3" == "$SERVER has address" ]] && ip route add $4 via $GATEWAY
# Серверы DNS и локальная сеть провайдера Билайн
ip route add 213.234.192.8 via $GATEWAY
ip route add 85.21.192.3 via $GATEWAY
ip route add 10.0.0.0/8 via $GATEWAY
# Добавляем маршрут через устройство ppp0 с более высоким приоритетом (меньшей метрикой), чем маршруты, раздаваемые по DHCP провайдера
ip route add default dev ppp0 metric 100
Оценил, разница очевидна =)
Мораль всей этой басни для virus_found: устанавливайте снова выпиленный net-tools, настраивайте L2TP по инструкции user_256 (предыдущая страница) и не мучайте мозг, в первую очередь самому себе.
прочитал топик и немного ужаснулся…что это за демон такой который сам не может прописать дефолтный маршрут после запуска…? и наверно надо dnsutil и net-tool добавлять “в коробку” уже…. Задам вопрос еще раз, это факт что после активации тунеля нужно еще руками заворачивать все заросы на него? поясните.
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
L2TP работает ПОВЕРХ имеющейся сети.
После подключения он создаёт СВОЙ дефолтный роут, который перекрывает уже имеющийся дефолтный роут, выданный DHCP.

Если после этого окажется, что сам L2TP-сервер был доступен по ЛОКАЛЬНОМУ дефолтному роуту, который перестал действовать после создания туннеля, то туннельный сервер перестанет быть доступен, и туннель снова “отвалится”.

Поэтому требуется обязательно создать роут, который будет указывать, что L2TP-сервер нужно роутить через физическую сеть, а не через туннель, на который показывает дефолтный роут.

Кроме того, в локальной сети провайдера могут быть другие ресурсы, недоступные через туннель, и для них тоже нужно создать роуты.

В принципе, при соответствующей (правильной) настройке локальной сети провайдера и его DHCP таких проблем возникать не должно, но так как мы клиенты, а не админы провайдера, мы не можем всё исправить как нам удобно, и приходится настраивать маршрутизацию на своей стороне :)
понятно, спс.
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
 
Зарегистрироваться или войдите чтобы оставить сообщение.