Anonymous

Howto: Роутер для Корбины на базе FreeBSD или OpenBSD

Рекомендованные сообщения

народ дайте плиз работающие конфига на сегоднишней день!!!!!!!!!!!!!! Плиззззззззззззззззззз!!!!!!!!!!!!!!!!!!!!!!!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Удалось все настроить на FreeBSD 6.1

 

Мой mpd.conf

default:

load corbina

corbina:

new corbina corbina

set iface idle 0

set bundle disable multilink

set bundle authname "login"

set bundle password "password"

set iface up-script /usr/local/etc/mpd/crb.io.up.sh

set iface down-script /usr/local/etc/mpd/crb.io.down.sh

set link keep-alive 60 180

set link accept chap

set link no pap

set bundle disable compression

set ccp yes mpp-e40

set ccp no mpp-e128

set bundle disable crypt-reqd

set ccp no mpp-stateless

set ipcp no vjcomp

set link mtu 1460

open

 

Мой mpd.sh из /usr/local/etc/rc.d

 

#!/bin/sh

#

# $FreeBSD: ports/net/mpd/files/mpd.sh,v 1.5 2006/02/20 20:47:27 dougb Exp $

#

# PROVIDE: mpd

# REQUIRE: NETWORKING syslogd

#

# Add the following line to /etc/rc.conf to enable mpd:

#

# mpd_enable="YES"

#

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

ifaceCrb="fxp0"

ipfwlineCrb="10"

CrbVPNGW=`resolveip -s vpn.corbina.ru`

CrbDefGW="10.179.0.17"

ipfwcommand="/sbin/ipfw"

lnFile="/usr/local/etc/mpd/mpd.links"

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

 

hasip=`ifconfig $ifaceCrb | grep inet | cut -d " " -f 2`

while [ "$hasip" = "0.0.0.0" ] ; do

echo "Waiting for Corbina IP allocated via DHCP. Current IP = $hasip"

sleep 2

hasip=`ifconfig $ifaceCrb | grep inet | cut -d " " -f 2`

done

InfIP=`ifconfig $ifaceCrb | egrep -o \[0\-9\]+\.\[0\-9\]+\.\[0\-9\]+\.\[0\-9\]+ | head -n 1`

 

#echo $InfIP $CrbIP

echo "corbina:" > $lnFile

echo " set link type pptp" >> $lnFile

echo " set link bandwidth 1000000" >> $lnFile

echo " set pptp self $CrbIP" >> $lnFile

echo " set pptp peer $CrbDefGW" >> $lnFile

echo " set pptp enable originate incoming outcall" >> $lnFile

 

chmod 600 $lnFile

mpd_flags="${mpd_flags:--kb}"

mpd_enable="${mpd_enable-NO}"

 

. /etc/rc.subr

 

name=mpd

rcvar=`set_rcvar`

 

prefix=/usr/local

procname=${prefix}/sbin/mpd

pidfile=/var/run/mpd.pid

required_files="${prefix}/etc/mpd/mpd.conf ${prefix}/etc/mpd/mpd.links"

command="${prefix}/sbin/mpd -k"

 

load_rc_config ${name}

run_rc_command "$1"

 

Мой crb.io.up.sh

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

ipfwcommand="/sbin/ipfw"

natdcommand="/sbin/natd"

routecommand="/sbin/route -nq"

lnFile="/usr/local/etc/mpd/mpd.links"

IfaceUpFile="/var/tmp/IfaceUp"

mynet="10.x.x.0/24"

DefGW="10.179.0.17"

Iface="fxp0"

ipfwline="10"

IfaceVPN=$1

NatdPidFile="/var/run/natd.$IfaceVPN.pid"

MyIP=`ifconfig $Iface | egrep -o \[0\-9\]+\.\[0\-9\]+\.\[0\-9\]+\.\[0\-9\]+ | head -n 1`

#VPNIP=`ifconfig $IfaceVPN | egrep -o \[0\-9\]+\.\[0\-9\]+\.\[0\-9\]+\.\[0\-9\]+`

VPNIP=$3

VPNGW=$4

OrigGW=`route -n get default | egrep -o \[0\-9\]+\.\[0\-9\]+\.\[0\-9\]+\.\[0\-9\]+`

NatdPort="8669"

NextVPNGW=`resolveip -s vpn.corbina.ru`

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

$routecommand delete $VPNGW

$routecommand add $VPNGW $DefGW

if [ $OrigGW ]; then

$routecommand change default $VPNGW

else

$routecommand add default $VPNGW

fi

 

$natdcommand -p $NatdPort -n $IfaceVPN -P $NatdPidFile

$ipfwcommand add $ipfwline divert $NatdPort ip from $mynet to any out via $IfaceVPN

$ipfwcommand add $ipfwline divert $NatdPort ip from any to $VPNIP in via $IfaceVPN

$ipfwcommand add $ipfwline fwd $VPNGW ip from $VPNIP to any

 

echo "Iface=\"$Iface\"" > $IfaceUpFile

echo "MyIP=\"$MyIP\"" >> $IfaceUpFile

echo "VPNIP=\"$VPNIP\"" >> $IfaceUpFile

echo "IfaceVPN=\"$IfaceVPN\"" >> $IfaceUpFile

echo "VPNGW=\"$VPNGW\"" >> $IfaceUpFile

echo "DefGW=\"$DefGW\"" >> $IfaceUpFile

echo "NatdPidFile=\"$NatdPidFile\"" >> $IfaceUpFile

echo "mynet=\"$mynet\"" >> $IfaceUpFile

echo "routecommand=\"$routecommand\"" >> $IfaceUpFile

echo "natdcommand=\"$natdcommand\"" >> $IfaceUpFile

echo "ipfwcommand=\"$ipfwcommand\"" >> $IfaceUpFile

echo "ipfwline=\"$ipfwline\"" >> $IfaceUpFile

echo "lnFile=\"$lnFile\"" >> $IfaceUpFile

echo "OrigGW=\"$OrigGW\"" >> $IfaceUpFile

#echo "=$" >> $IfaceUpFile

 

chmod 0400 $IfaceUpFile

 

echo "corbina:" > $lnFile

echo " set link type pptp" >> $lnFile

#echo " set link bandwidth 1000000" >> $lnFile

echo " set pptp self $MyIP" >> $lnFile

echo " set pptp peer $NextVPNGW" >> $lnFile

echo " set pptp enable originate incoming outcall" >> $lnFile

 

Мой crb.io.down.sh

#!/bin/sh

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

IfaceUpFile="/var/tmp/IfaceUp"

. $IfaceUpFile

NatdPid="cat $NatdPidFile"

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

$routecommand delete $VPNIP

$routecommand change default $OrigGW

$ipfwcommand delete 10

kill -TERM $NatdPid

$routecommand delete $VPNGW

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хочу халявный роутер ;) . Это будет работать? (ВПН-интернет + локалка). Прошу сильно не пинать чайника ;) .

http://www.thg.ru/network/ipcop/index.html

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

alkol, лучше уж тогда попробовать pfsense.com

Он вроде умеет всё что надо. И конфигурится несложно, возможностей масса! Но честно скажу, я его к корбине прикручивать не пробовал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Отзовитесь У КОГО РАБОТАЕТ MPD в FreeBSD6???

когда нет потери пакетов - работает ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

-=ace=-, у меня перестал работать с тех пор как прикрыли 195.14.40.8 впн-сервер... на всех 10 ныне действующих серверах mpd с моими конфигами вешает напроч машину... раньше на 40.8 работал как часы...

Стукни в асю! дай конфиги сравнить... 259850

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня работает (mpd4-4.0b5) + pf (перенаправление портов).config.zip

 

Админы не дают присоединить просто файл

 

#!/bin/sh
#
# Configure Corbina internal net routing
#

# PROVIDE: corbinaroutes
# REQUIRE: routing mountcritlocal
# BEFORE: mpd
# KEYWORD: nojail

. /etc/rc.subr

name=corbinaroutes
start_cmd="crb_start"
stop_cmd="crb_stop"

fetch_crb_routes() {
fetch -q -o - 'http://foto.corbina.ru/route.php' | \
		tr '[:upper:]' '[:lower:]' | \
		fgrep add | \
		fgrep -v ' 0.0.0.0 ' | \
		sed 's/^.* add //' | \
		awk '{ print $1,$3 }'
}

mkcmds() {
awk '{ print "route -q add",$1,"'"$1"'",$2 }'
}

crb_start()
{
gw=`netstat -rnf inet | awk '/^default/ { print $2 }'`
if [ x$gw != x ]
then
	(echo 195.14.50.1 255.255.255.255; echo 195.14.50.21 255.255.255.255; fetch_crb_routes) | mkcmds $gw | sh
fi
exit 0
}

crb_stop()
{
exit 0
}

load_rc_config $name
run_rc_command "$1"

Изменено пользователем nms42

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня к сожалениею ни pptp ни mpd не работает.

 

кто настроит и покажет за 500 руб. на выходных

стоит frenzy (freebsd) mpd скидывает при подкючении

 

daniel_sl@rambler.ru

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

я правильно понимаю что только у меня проблема с соеденение VPN через pptpclient на уровне авторизации?

Nov 16 20:39:46 gate ppp[1035]: tun0: LCP: deflink: LayerUp
Nov 16 20:39:46 gate ppp[1035]: tun0: Phase: bundle: Authenticate
Nov 16 20:39:46 gate ppp[1035]: tun0: Phase: deflink: his = CHAP 0x05, mine = no
ne
Nov 16 20:40:06 gate ppp[1035]: tun0: Phase: Chap Input: CHALLENGE (16 bytes from bras6)
Nov 16 20:40:06 gate ppp[1035]: tun0: Phase: Chap Output: RESPONSE (MyLogin)
Nov 16 20:40:08 gate ppp[1035]: tun0: IPCP: deflink: Error: Unexpected IPCP in phase Authenticate (ignored)
Nov 16 20:40:20 gate last message repeated 6 times
Nov 16 20:40:38 gate ppp[1035]: tun0: LCP: deflink: RecvEchoRequest(4) state = Opened
Nov 16 20:40:38 gate ppp[1035]: tun0: LCP: deflink: SendEchoReply(4) state = Opened
Nov 16 20:40:57 gate ppp[1035]: tun0: IPCP: deflink: Error: Unexpected IPCP in phase Authenticate (ignored)
Nov 16 20:40:59 gate ppp[1035]: tun0: LCP: deflink: RecvEchoRequest(6) state = Opened
Nov 16 20:40:59 gate ppp[1035]: tun0: LCP: deflink: SendEchoReply(6) state = Opened
Nov 16 20:41:00 gate ppp[1035]: tun0: IPCP: deflink: Error: Unexpected IPCP in phase Authenticate (ignored)
Nov 16 20:41:12 gate last message repeated 4 times

обратите внимание на строчку

Nov 16 20:41:00 gate ppp[1035]: tun0: IPCP: deflink: Error: Unexpected IPCP in phase Authenticate (ignored)

Проверил 4 сервера .. результат везде одинаковый

 

PS: на MPD поднялось

Изменено пользователем -=ace=-

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Народ помогите.

OpenBSD 4.0, pptp 1.7.0.

Проблема в следующем:

Линк подымаеться держиться но

я не могу пропинговать ip который мне выделили в качестве внешнего.

и соответственно инета тоже нету.

на пинг получаю

 

# ping ya.ru

PING ya.ru (213.180.204.8): 56 data bytes

ping: sendto: No buffer space available

ping: wrote ya.ru 64 chars, ret=-1

 

Локалка вся работает.

В логах пробегает

tun0: Warning: 0.0.0.0/0: Change route failed: errno: No such process

как линк поднялся в лог пишеться

tun0: Phase: deflink: Not transmitting... waiting for CCP

с определенным интервалом.

Адреса резольвяться DNS работает.

default route перепробовал все.

Да и еще из винды через BSD мой внешний ip пингуеться а из самой BSD нет.

Из винды VPN устанавливаеться через OpenBSD.

настройки вот эти:

Howto: Роутер для Корбины на базе FreeBSD или OpenBSD

 

Подсобите кто может - предоставлю все логи и конфиги.

Спасибо

Изменено пользователем Wrk

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Удалено

Изменено пользователем Edmundo

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

VPN на базе MPD

 

mpd.conf

default:

load mpd

mpd:

new -i ng0 link1 link1

set bundle authname "blabla"

set bundle password "blabla2"

set bundle disable multilink

set iface disable on-demand

set iface enable tcpmssfix

set iface idle 0

set ipcp ranges 0.0.0.0/32 195.14.38.21 - не имеет значения, не должен пересекаться с адресом пира

set iface mtu 1500

set link mtu 1500

set link mru 1500

log -lcp

log -phys

log -fsm

log -ipcp

log -iface

log -bund

log -link

log -chat

log -auth

open

 

mpd.links

 

link1:

set link type pptp

set pptp peer vpn.corbina.net

set pptp enable originate outcall

set pptp disable windowing

 

Дефолт поднимаем (не прописываем ручками ни в коем случае) зеброй ибо знаем о проблемах корбины и используем альтернативку на случай падения. И никаких up.sh и down.sh

 

zebra.conf

ip route 0.0.0.0/0 195.14.38.21

ip route 0.0.0.0/0 x.x.x.x 200 (альтернативный шлюз)

ip route 10.57.0.0/16 10.57.0.17

ip route 195.14.38.0/24 10.57.0.17

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Дефолт поднимаем (не прописываем ручками ни в коем случае) зеброй ибо знаем о проблемах корбины и используем альтернативку на случай падения. И никаких up.sh и down.sh

Проблема в "магических" числах/адресах, которые бумкнут при очередном корбинном "улучшении".

 

Up/down скрипты хороши тем что не надо перегружать компьютер (не форточки чать ;-]), починяется то что рухнуло только.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проблема в "магических" числах/адресах, которые бумкнут при очередном корбинном "улучшении".

 

Up/down скрипты хороши тем что не надо перегружать компьютер (не форточки чать ;-]), починяется то что рухнуло только.

 

Это каких например? Не вижу ничего, что могло бы заставить перезагрузить комп в таком случае

Изменено пользователем dvglazunov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

-=ace=-, у меня перестал работать с тех пор как прикрыли 195.14.40.8 впн-сервер... на всех 10 ныне действующих серверах mpd с моими конфигами вешает напроч машину... раньше на 40.8 работал как часы...

Стукни в асю! дай конфиги сравнить... 259850

 

После смены адресов MPD действительно стала вешать машину. В чем беда уже говорили, адреса ВПН шлюзов совпадают с выданными адресами новых gateway по умолчанию, BSD или MDP с этого сносит крышу. Лечится включение forward в ядре и добавление одного правила в файрволл.

 

в конфиг нового ядра надо добавить включение файрволла (у меня ipfw2) и форварда.

----------

options IPFIREWALL

options IPFIREWALL_FORWARD

options IPFIREWALL_FORWARD_EXTENDED

----------

 

а в сам файрволл добавить правило поближе к началу

---

fwd 10.xxx.0.17 gre from me to any out

---

первый ip - ваш gateway

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

После смены адресов MPD действительно стала вешать машину. В чем беда уже говорили, адреса ВПН шлюзов совпадают с выданными адресами новых gateway по умолчанию, BSD или MDP с этого сносит крышу. Лечится включение forward в ядре и добавление одного правила в файрволл.

 

в конфиг нового ядра надо добавить включение файрволла (у меня ipfw2) и форварда.

----------

options IPFIREWALL

options IPFIREWALL_FORWARD

options IPFIREWALL_FORWARD_EXTENDED

----------

 

а в сам файрволл добавить правило поближе к началу

---

fwd 10.xxx.0.17 gre from me to any out

---

первый ip - ваш gateway

 

set ipcp ranges 0.0.0.0/32 195.14.38.21 - адрес пира не имеет значения, не должен пересекаться с адресами vpn.corbina.net

 

достаточно самому прописать адрес пира

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вышел m0n0wall Beta version 1.3b2 released,

просьба попробовать, по крайней мере в tc-exe при поднятом впн сетка видится, как насчет корбины, желающие есть?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Народ есть у кого рабочий ppp.conf? Пробовал настраивать по топику автора - не проходит авторизацию, или выдает ошибку 691. логи и пас верны.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

пробую pptpclient

ppp.conf:

corbina:

set authname reill

set authkey *****

set timeout 0

set ifaddr 0 0

disable pap

add default HISADDR

allow users

 

Подключаюсь pptp vpn.corbina.net corbina

log1:

Feb 5 11:35:56 freerouter ppp[1218]: Phase: Chap Input: CHALLENGE (16 bytes from bras19)

Feb 5 11:35:56 freerouter ppp[1218]: Phase: Chap Output: RESPONSE (reill)

Feb 5 11:35:56 freerouter ppp[1218]: Phase: Chap Input: FAILURE (Authentication failed)

Feb 5 11:35:56 freerouter ppp[1218]: Phase: deflink: Disconnected!

Feb 5 11:35:56 freerouter ppp[1218]: Phase: deflink: Connect time: 2 secs: 205 octets in, 164 octets out

Feb 5 11:35:56 freerouter ppp[1218]: Phase: deflink: 6 packets in, 5 packets out

Feb 5 11:35:56 freerouter ppp[1218]: Phase: total 184 bytes/sec, peak 0 bytes/sec on Mon Feb 5 11:35:54 2007

Feb 5 11:35:56 freerouter ppp[1218]: Phase: deflink: lcp -> closed

Feb 5 11:35:56 freerouter ppp[1218]: Phase: bundle: Dead

Feb 5 11:35:56 freerouter ppp[1218]: Phase: PPP Terminated (normal).

log2:

 

Feb 5 11:39:22 freerouter ppp[1273]: Phase: Chap Input: CHALLENGE (8 bytes from bras4 )

Feb 5 11:39:22 freerouter ppp[1273]: Phase: Chap Output: RESPONSE (reill)

Feb 5 11:39:22 freerouter ppp[1273]: Phase: Chap Input: FAILURE (E=691 R=0)

Feb 5 11:39:22 freerouter ppp[1273]: Phase: deflink: Disconnected!

Feb 5 11:39:22 freerouter ppp[1273]: Phase: deflink: Connect time: 2 secs: 182 octets in, 221 octets out

Feb 5 11:39:22 freerouter ppp[1273]: Phase: deflink: 6 packets in, 5 packets out

Feb 5 11:39:22 freerouter ppp[1273]: Phase: total 201 bytes/sec, peak 0 bytes/sec on Mon Feb 5 11:39:20 2007

Feb 5 11:39:22 freerouter ppp[1273]: Phase: deflink: lcp -> closed

Feb 5 11:39:22 freerouter ppp[1273]: Phase: bundle: Dead

Feb 5 11:39:22 freerouter ppp[1273]: Phase: PPP Terminated (normal).

 

поправил конфиги mpd4: nthm выходит вот такая хня... ошика авторизации:

Multi-link PPP for FreeBSD, by Archie L. Cobbs.

Based on iij-ppp, by Toshiharu OHNO.

mpd: pid 1000, version 4.0b5 (root@freebsd.org 09:57 3-Jan-2007)

CONSOLE: listening on 127.0.0.1 5005

[vpncorbina] ppp node is "mpd1000-vpncorbina"

tcpmss node is "mpd1000-mss"

[vpncorbina] using interface ng0

[vpncorbina] LCP: Open event

[vpncorbina] LCP: state change Initial --> Starting

[vpncorbina] LCP: LayerStart

pptp0: connecting to 195.14.38.12 1723

pptp0: connected to 195.14.38.12 1723

pptp0: attached to connection with 195.14.38.12 1723

pptp0-0: outgoing call connected at 64000 bps

[vpncorbina] PPTP call successful

[vpncorbina] link: UP event

[vpncorbina] link: origination is local

[vpncorbina] LCP: Up event

[vpncorbina] LCP: state change Starting --> Req-Sent

[vpncorbina] LCP: SendConfigReq #1

ACFCOMP

PROTOCOMP

MRU 1500

MAGICNUM 36adf350

[vpncorbina] LCP: rec'd Configure Request #1 link 0 (Req-Sent)

AUTHPROTO CHAP MD5

MAGICNUM 586f100d

[vpncorbina] LCP: SendConfigAck #1

AUTHPROTO CHAP MD5

MAGICNUM 586f100d

[vpncorbina] LCP: state change Req-Sent --> Ack-Sent

[vpncorbina] LCP: rec'd Configure Ack #1 link 0 (Ack-Sent)

ACFCOMP

PROTOCOMP

MRU 1500

MAGICNUM 36adf350

[vpncorbina] LCP: state change Ack-Sent --> Opened

[vpncorbina] LCP: auth: peer wants CHAP, I want nothing

[vpncorbina] LCP: LayerUp

[vpncorbina] CHAP: rec'd CHALLENGE #1

Name: "bras12"

Using authname "reill"

[vpncorbina] CHAP: sending RESPONSE len:22

[vpncorbina] CHAP: rec'd FAILURE #1

MESG: Authentication failed

[vpncorbina] LCP: authorization failed

pptp0-0: clearing call

[vpncorbina] LCP: rec'd Terminate Request #2 link 0 (Opened)

[vpncorbina] LCP: state change Opened --> Stopping

[vpncorbina] LCP: SendTerminateAck #2

[vpncorbina] error writing len 8 frame to bypass: Network is down

[vpncorbina] LCP: LayerDown

[vpncorbina] link: DOWN event

[vpncorbina] LCP: Down event

[vpncorbina] LCP: state change Stopping --> Starting

[vpncorbina] pausing 7 seconds before open

pptp0-0: peer call disconnected res=lost carrier err=none

pptp0-0: killing channel

pptp0: closing connection with 195.14.38.12 1723

pptp0: got StopCtrlConnRequest: reason=zero?

pptp0: killing connection with 195.14.38.12 1723

[vpncorbina] pausing 2 seconds before open

pptp0: connecting to 195.14.38.12 1723

pptp0: connected to 195.14.38.12 1723

pptp0: attached to connection with 195.14.38.12 1723

pptp0-0: outgoing call connected at 64000 bps

[vpncorbina] PPTP call successful

[vpncorbina] link: UP event

[vpncorbina] link: origination is local

[vpncorbina] LCP: Up event

[vpncorbina] LCP: state change Starting --> Req-Sent

[vpncorbina] LCP: SendConfigReq #3

 

 

startup:

set console port 5005

set console ip 127.0.0.1

set console user XXXXXX XXXXXX

set console open

 

default:

load vpncorbina

 

vpncorbina:

new -i ng0 vpncorbina vpncorbina

set auth authname ZZZZZZ

set bundle disable compression

set bundle disable crypt-reqd

set bundle disable multilink

set iface disable on-demand

set iface idle 0

set iface down-script /usr/local/etc/mpd4/vpncorbina-dn.sh

set iface up-script /usr/local/etc/mpd4/vpncorbina-up.sh

set ipcp enable req-pri-dns

set ipcp enable req-sec-dns

set ipcp no vjcomp

set ipcp ranges 0.0.0.0/0 0.0.0.0/0

set link accept chap

set link keep-alive 60 180

set link no pap

open

 

 

vpncorbina:

set link type pptp

set pptp peer vpn.corbina.net

set link bandwidth 1000000

set pptp enable originate outcall

set pptp enable always-ack

 

vpncorbina-dn:

#!/bin/sh

 

PFCTL=/sbin/pfctl

ROUTE=/sbin/route

 

pmem=/var/run/vpn.memory

 

. $pmem

 

$PFCTL -a mpd/$1 -F all

 

$ROUTE delete $VpnGW

 

$ROUTE delete default

$ROUTE add default $OrgGW

 

exit 0

 

vpncorbina-up.sh:

 

#!/bin/sh

 

PFCTL=/sbin/pfctl

ROUTE=/sbin/route

 

pffile=/etc/pf.mpd.conf

pmem=/var/run/vpn.memory

 

OrgGW=`/usr/bin/netstat -rnf inet | /usr/bin/awk '/^default/ { print $2 }'`

 

umask 033

 

echo OrgGW=$OrgGW > $pmem

echo VpnGW=$4 >> $pmem

 

$ROUTE delete $4

$ROUTE add $4 $OrgGW

 

$ROUTE delete default

$ROUTE add default $4

 

$PFCTL -a mpd/$1 -Dmpd_if=$1 -f $pffile

 

exit 0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

pptpclient это который http://sourceforge.net/projects/pptpclient/ ?

 

я его наоборот запускаю:

 

cat << EOP | xargs pppd

pty "pptp __VPN_SERVER_ADDR__ --nolaunchpppd --loglevel 0 --timeout 2"

connect 'sh -c true'

name $LOGINNAME

ipparam corbina

lock

persist

noauth

nobsdcomp

nodeflate

noipdefault

usepeerdns

defaultroute

EOP

 

ну и конечно нужно пароли в /etc/ppp/chap-secrets настроить.

Ну и рутинг настроить,

Изменено пользователем dilmah

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Разобрался с mpd, всем спасибо. Теперь другой вопрос встал - нужно настроить перенаправление трафика, чтобы развести инет на пару компов. Кто чем пользуется, можно ли как-то это сделать без пересборки ядра, слышал для для поднятия nat - нужно пересобирать ядро..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Разобрался с mpd, всем спасибо. Теперь другой вопрос встал - нужно настроить перенаправление трафика, чтобы развести инет на пару компов. Кто чем пользуется, можно ли как-то это сделать без пересборки ядра, слышал для для поднятия nat - нужно пересобирать ядро..

Для перенаправления тоже придется )), точнее опиши задачу

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

dvglazunov, есть вторая сетевуха которая подключена к домашнему хабу, нужно настроить freebsd как роутер, вот собственно и все=)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Дорое время суток!

Не могу разобратся со связкой mpd+natd. Проблема в следующем есть впн соединенеие ng0. Пересобрал ядро с опциями:

IPFIREWALL

IPFIREWALL_VERBOSE

IPFIREWALL_VERBOSE_LIMIT=10

IPDIVERT

IPFIREWALL_DEFAULT_TO_ACCEPT

DUMMYNET

прописал в /etc/rc.conf

gateway_enable="YES"

firewall_enable="YES"

firewall_quiet="YES"

firewall_tupe="YES"

natd_enable="YES"

 

создал natd.conf:

use_sockets yes

same_ports yes

unregistered_only yes

inteface ng0

 

создал скрипт /usr/local/etc/rc.d/ipfw_natd.sh

natd -f /etc/natd.conf -n ng0

ipfw add 500 divert natd all from any to any via ng0

 

Перезагружаю систему никаких ошибок не выскакивает, но с клиентских машинок инет не виден. Подскажите в чем может быть проблема. Заранее спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Люди добрые (и не очень тоже:lol:), доброго времени суток!

Есть:

PIII-1GHz, 512Mb, 40Gb, LAN10/100 - 2шт.

FreeBSD 6.2, ядро по дефолту

Сетка 10.126.х.х

Надо, ну просто ОЧЕНЬ хочеться: ;)

Получать инет по одной и раздавать по второй сетевухе. Предпочтительнее делать это при помощи mpd (хотя если кто грамотно объяснит в чем разница, буду благодарен).

 

Читал эту тему и другие тоже, перепробовал тучу конфигов (и mpd и pptp), не выходит аленький цветочек... ну никак... даже интерфейс ng0 не поднимается... Очень прошу, объясните все как можно более подробнее, как же завести все это дело: нужно ли компилить ядро, если да, то с какими опциями, что должно быть в rc.conf, какую версию и чего лучше юзать, ну и сами файлы соббссно... Нужно ли проделывать какие-либо еще операции по настройке и т.д. и т.п.

 

Заранее благодарен, если вдруг что, то:

myspam@yandex.ru

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обновлённый How to по настройке Corbina VPN под OpenBSD

Я пишу эту инструкцию так как мне пришлось потратить около 30 часов суммарного времени чтобы заставить VPN работать и данная ветка дискуссии дала неполную и разрозненную информацию именно касательно OpenBSD. Кроме того без объяснения конфигов трудно понять что не работает, если всё-таки не заработает. Поэтому я постараюсь написать и возможные проблемы и какую-то их диагностику.

Оглавление:

Часть 1

Конфигурация, железо и т. п.

Настроим сеть

Сага о DNS

Настроим VPN

Автоматизация VPN

Часть 2

Подготовка внутренней домашней сети

Настройка NAT

Настройка резевного канала

Настройка policy based routing (понтово схитрим)

Конфигурация, железо и т. п.

После загрузки и входа в систему пишем dmesg|less находим и читаем как в системе называются ваши карточки. Например вот список из трёх карт у меня:

fxp0 at pci0 dev 10 function 0 "Intel 82557" rev 0x05: irq 10, address 00:a0:c9:e8:46:4d
inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 0
vr0 at pci0 dev 11 function 0 "VIA VT6105 RhineIII" rev 0x86: irq 12 address 00:0d:88:4e:c6:aa
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface
ukphy0: OUI 0x004063, model 0x0034, rev. 4
xl0 at pci0 dev 12 function 0 "3Com 3c905C 100Base-TX" rev 0x78: irq 11, address 00:01:02:28:23:ac
exphy0 at xl0 phy 24: Broadcom 3C905C internal PHY, rev. 7

Итак имена карточек fxp0, vr0, xl0. Команда, которую мы набрали выводит сообщения об оборудовании при загрузке системы. Вторая часть команды передаёт весь текст обработчику, позволяющему удобно листать текст.

Мы будем считать, что наша карточка xl0 и именно в неё надо воткнуть кабель от Корбины. Для диагностики можно набрать ifconfig -a - это выведет список всех сетевых карт в системе с их характеристиками. Например вот так:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
	inet 127.0.0.1 netmask 0xff000000
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	address: 00:a0:c9:e8:46:4d
	media: Ethernet autoselect (100baseTX full-duplex)
	status: active
	inet6 fe80::2a0:c9ff:fee8:464d%fxp0 prefixlen 64 scopeid 0x1
	inet 217.117.116.197 netmask 0xffffff80 broadcast 217.117.116.255
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	address: 00:0d:88:4e:c6:aa
	media: Ethernet autoselect (100baseTX full-duplex)
	status: active
	inet 192.168.212.1 netmask 0xfffffff8 broadcast 192.168.212.7
	inet6 fe80::20d:88ff:fe4e:c6aa%vr0 prefixlen 64 scopeid 0x2
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	address: 00:01:02:28:23:ac
	media: Ethernet autoselect (100baseTX full-duplex)
	status: active
	inet6 fe80::201:2ff:fe28:23ac%xl0 prefixlen 64 scopeid 0x3
	inet 10.83.18.55 netmask 0xffff0000 broadcast 10.83.255.255
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33224
pfsync0: flags=0<> mtu 2020
enc0: flags=0<> mtu 1536
tun0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1464
	inet 89.178.32.173 --> 85.21.0.5 netmask 0xffffffff

Все три карты присутствуют и в поле stutus указано, что они видят сигнал. На остальные карты пока внимания не обращаем. На этой стадии электрически всё связано. Еще можно посмотреть на светодиоды на сетевой карте. Они показывают видит ли сетевая карта сигнал. Перейдём к настройке сети.

Настройка сети

Нам нужно получить внутренний IP от Корбины через службу выдачи динамических IP (DHCP). Для этого есть программка dhclient и её отдельно устанавливать не нужно. Запустим её указав какая сетевая карта будет просить себе IP - dhclient xl0. Всё прошло удачно если оно похоже на вот это:

DHCPREQUEST on xl0 to 255.255.255.255 port 67
DHCPREQUEST on xl0 to 255.255.255.255 port 67
DHCPREQUEST on xl0 to 255.255.255.255 port 67
DHCPDISCOVER on xl0 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 10.83.0.17
DHCPREQUEST on xl0 to 255.255.255.255 port 67
DHCPACK from 10.83.0.17
bound to 10.83.18.55 -- renewal in 302400 seconds.

Что мы тут видим? Мы видим, что нам ответил 10.83.0.17 и предложил нам IP 10.83.18.55. Этот IP является внутренним и получение его это первый шаг чтобы бальше общаться с VPN сервером и просить его об установлении соединения. С нашим внутренним IP мы уже сможем зайти на форум Корбины и сейчас мы это настроим. Но сначала проверим, что IP установлен и кроме этого мы получили маску подсети. Для этого снова глянем на наши сетевые карты с помощью команды ifconfig, но на этот раз выведем информацию только по одной сетевой карте ifconfig xl0:

xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	address: 00:01:02:28:23:ac
	media: Ethernet autoselect (100baseTX full-duplex)
	status: active
	inet6 fe80::201:2ff:fe28:23ac%xl0 prefixlen 64 scopeid 0x3
	inet 10.83.18.55 netmask 0xffff0000 broadcast 10.83.255.255

Видим наш IP и маску подсети 0xffff0000. Информации как посмотреть выданный шлюз (gateway) я так и не нашёл, но у почти всех в Корбине он обычно 10.ххх.0.17. А я уже видел, как 10.83.0.17 мне отвечал. Я справедливо решил, что шлюз это именно он. Кроме того при установлении соединения к шлюзу прописывается путь (route) по умолчанию и сейчас мы сами научимся их смотреть и прописывать.

Итак наберёс команду route -n show или netstat -rn. route это команда управляющая тем в какую сетевую и к какому шлюзу посылать пакеты. Ключ -n заставляет эту программу не перекодировать IP в имена и просто сильно экономит время. Мы увидим что-то типа:

Routing tables

Internet:
Destination		Gateway			Flags	Refs	  Use	Mtu  Interface
default			10.83.0.17	UGS		 0	 6917	  -   xl0
10.83/16		   link#3			 UC		  0		0	  -   xl0
10.83.0.17		 00:17:59:af:a9:51  UHLc		0		0	  -   xl0
10.83.17.71		00:0f:3d:48:7c:65  UHLc		0		0	  -   xl0
10.83.17.237	   00:15:e9:76:c4:21  UHLc		0		0	  -   xl0
10.83.18.55		127.0.0.1		  UGHS		0		0  33224   lo0
127/8			  127.0.0.1		  UGRS		0		0  33224   lo0
127.0.0.1		  127.0.0.1		  UH		  0	   20  33224   lo0
192.168.212.0/29   link#2			 UC		  0		0	  -   vr0
192.168.212.2	  4c:00:10:38:7c:11  UHLc		0	21754	  -   vr0
217.117.116.128/25 link#1			 UC		  0		0	  -   fxp0
217.117.116.129	00:19:5b:12:b4:03  UHLc		0		0	  -   fxp0
217.117.116.156	00:80:48:26:12:d5  UHLc		0		0	  -   fxp0
217.117.116.197	127.0.0.1		  UGHS		0		0  33224   lo0
224/4			  127.0.0.1		  URS		 0		0  33224   lo0

Internet6:
Destination						Gateway						Flags	Refs	  Use	Mtu  Interface
::/104							 ::1							UGRS		0		0	  -   lo0
::/96							  ::1							UGRS		0		0	  -   lo0
::1								::1							UH		  0		0  33224   lo0
::127.0.0.0/104					::1							UGRS		0		0	  -   lo0
::224.0.0.0/100					::1							UGRS		0		0	  -   lo0
::255.0.0.0/104					::1							UGRS		0		0	  -   lo0
::ffff:0.0.0.0/96				  ::1							UGRS		0		0	  -   lo0
2002::/24						  ::1							UGRS		0		0	  -   lo0
2002:7f00::/24					 ::1							UGRS		0		0	  -   lo0
2002:e000::/20					 ::1							UGRS		0		0	  -   lo0
2002:ff00::/24					 ::1							UGRS		0		0	  -   lo0
fe80::/10						  ::1							UGRS		0		0	  -   lo0
fe80::%fxp0/64					 link#1						 UC		  0		0	  -   fxp0
fe80::2a0:c9ff:fee8:464d%fxp0	  00:a0:c9:e8:46:4d			  UHL		 0		0	  -   lo0
fe80::%vr0/64					  link#2						 UC		  0		0	  -   vr0
fe80::20d:88ff:fe4e:c6aa%vr0	   00:0d:88:4e:c6:aa			  UHL		 0		0	  -   lo0
fe80::%xl0/64					  link#3						 UC		  0		0	  -   xl0
fe80::201:2ff:fe28:23ac%xl0		00:01:02:28:23:ac			  UHL		 0		0	  -   lo0
fe80::%lo0/64					  fe80::1%lo0					U		   0		0	  -   lo0
fe80::1%lo0						link#7						 UHL		 0		0	  -   lo0
fec0::/10						  ::1							UGRS		0		0	  -   lo0
ff01::/32						  ::1							UC		  0		0	  -   lo0
ff02::%fxp0/32					 link#1						 UC		  0		0	  -   fxp0
ff02::%vr0/32					  link#2						 UC		  0		0	  -   vr0
ff02::%xl0/32					  link#3						 UC		  0		0	  -   xl0
ff02::%lo0/32					  ::1							UC		  0		0	  -   lo0

Вторая часть таблицы это вообще IPv6. Это нам не нужно. Смотрим на первые три строчки таблицы. Итак первая строчка состоит из нескольких элементов. Первый это куда мы хотим соединяться. Default значит любой IP. Это полность эквивалентно записи 0.0.0.0/0. Второй элемент это через кого мы хотим соединяться и именно тут после получения IP может прописаться наш шлюз. И если он там прописался, то всё замечательно ибо теперь мы можем посылать наши запросы и получать ответы если мы обращаемся к внутрисетевым ресурсам. Про то как исправить ситуацию при отсутствии этой строчки чуть далее. Дальше идут флаги того как широко действует маршрут-путь и как он был создан. В конце идёт сетевая карта через которую мы будем получать сеть. Естественно там должна быть xl0. Вторая строчка говорит нам, что если мы хоти общаться с кем-то из нашей подсети, то нам не нужен шлюз, а нужно просто посылать пакет напрямую в сетевую карту 3. Ну и наконец третья строчка говорит, что если мы хотим соединиться со шлюзом, то его MAC адрес по которому надо посылать пакет 00:17:59:af:a9:51.

Давайте сделаем некоторые проверочные шаги. Например попингуем (узнаем ходят ли туда сюда определённые пакеты от нас и до шлюза). Для этого набираем ping <адрес шлюза>. Например ping 10.83.0.17. Получим что-то типа:

PING 10.83.0.17 (10.83.0.17): 56 data bytes
64 bytes from 10.83.0.17: icmp_seq=0 ttl=255 time=0.695 ms
64 bytes from 10.83.0.17: icmp_seq=1 ttl=255 time=0.749 ms
64 bytes from 10.83.0.17: icmp_seq=2 ttl=255 time=0.718 ms

Для выхода нажмём Control+C. Здесь написано, что нам ответили и указано время сколько требуется для ответа после запроса. Теперь попингуем форум ping homenet.corbina.net:

PING homenet.corbina.net (85.21.90.25): 56 data bytes
64 bytes from 85.21.90.25: icmp_seq=0 ttl=59 time=1.099 ms
64 bytes from 85.21.90.25: icmp_seq=1 ttl=59 time=0.798 ms
64 bytes from 85.21.90.25: icmp_seq=2 ttl=59 time=0.991 ms

Определился IP форума и пришёл от него ответ. Можно даже посмотреть как именно он пришёл. А именно через какие места шёл. Для этого есть команда traceroute homenet.corbina.net:

traceroute to homenet.corbina.net (85.21.90.25), 64 hops max, 40 byte packets
1  10.83.0.17 (10.83.0.17)  0.901 ms  0.683 ms  0.648 ms
2  msu-bb-vlan72.msk.corbina.net (195.14.60.109)  0.633 ms  0.438 ms  0.455 ms
3  ko-bb-teng4-3.msk.corbina.net (195.14.54.225)  0.820 ms  0.805 ms  0.816 ms
4  hq-bb-teng4-1.msk.corbina.net (195.14.54.253)  0.907 ms  0.828 ms  0.810 ms
5  hg-rs1-vlan71.msk.corbina.net (195.14.61.214)  1.66 ms  1.12 ms  1.15 ms
6  85.21.90.25 (85.21.90.25)  1.47 ms  0.943 ms  0.852 ms

Первая строчка это наш шлюз как и должно быть. Далее идут какие-то внутренние узлы Корбины. Что делать если нет соединения со шлюзом. То есть он не пингуется. Надо проверить, что карта получила IP. Надо проверить, что шлюз это правильный шлюз. Надо проверить не отключилась ли карта или кабель. Если шлюз пингуется, а форум не пингуется, то надо проверить таблицу маршрутизации route -n show. Там должен стоять корректный шлюз для пути default. Если его там нет, то добавить его можно командой route add default <адрес шлюза>. Например route add default 10.83.0.17. Если строчка там есть, но шлюз указан неверно, то можно поменять шлюз командой route change default <gateway>. Например так route change default 10.83.0.17. И наконец можно удалить маршрут, но нам это вроде пока не нужно. Делается это командой route delete default. Вместо default может стоять любая другая сеть из списка, выдаваемого командой route -n show. Например route change 10.83/16 127.0.0.1. Теперь надо набрать route -n show и проверить, что таблица правильная и похожа на приведённую выше. Ну и снова добиться пингования форума.

Теперь предположим, что форум пингуется и мы хотим сделать более грамотную маршрутизацию до внутресетевых ресурсов. Для этого мы должны сказать что не все пакеты нужно посылать на шлюз, а только те, которые там обработают. Для этого надо указать все диапазоны IP внутресетевых ресурсов. Будем добавлять маршруты командой route add <диапазон IP> <gateway>. Например вот так: route add 10/8 10.83.0.17. Это означает подключение маршрута ко всем внутресетевым IP Корбины. Теперь подключим интернет ресурсы. Список я взял отсюда. Вот он:

85.21.29.242

195.14.50.26

195.14.50.16

85.21.79.0/24

85.21.90.0/24

85.21.52.254

85.21.88.130

83.102.146.96

85.21.138.210

85.21.138.214/27

Если после адреса идёт дробь и число до 32, то это целый диапазон, а не просто IP. Чем меньше число - тем шире диапазон. После добавления маршрутов можно проверить получилось ли. Делаем это командой route -n show. Там появятся ровно те новые строки, что мы и добавляли. Но это еще не всё. Есть еще адреса VPN серверов, к которым стоит прописать маршрут отдельно для пущей надёжности. Это мы рассмотрим в пункте настройки VPN. А сейчас немного о DNS.

Сага о DNS

Если есть проблема, что вы не можете зайти на сайт (например homenet.corbina.net), то возможно это не из-за отсутствия связи и винить глючный VPN совсем не нужно, а дело в сбившихся настройках DNS. Вкратце для тех кто не знает: DNS это система, которая перекодирует имя в IP адрес. Так как вёб в основном работает по именам, то без этой системы никуда. Для того чтобы по имени узнать адрес нужно просто связаться со специальным сервером провайдера, который сделает всё необходимое. Но что если один этот сервер недоступен? Может создаться впечатление, что "нет инета", однако это не так и лечить проблему нужно именно в области DNS. Как проверить кто виноват - отсутствие связи или DNS? Для этого надо попробовать обратиться по имени и по IP. Если глючит DNS, то по IP работать будет, а по имени будет давать ошибку. Например делаем так: ping ya.ru:

PING ya.ru (213.180.204.8): 56 data bytes
64 bytes from 213.180.204.8: icmp_seq=0 ttl=57 time=3.274 ms
64 bytes from 213.180.204.8: icmp_seq=1 ttl=57 time=3.561 ms
64 bytes from 213.180.204.8: icmp_seq=2 ttl=57 time=3.135 ms

Видно, что имя преобразовалось в IP = 213.180.204.8. то есть DNS работает гарантированно и инет тоже работает. если пинг не прошёл, то попробуйте ping 213.180.204.8 или любой другой IP, который точно включён и находиться в интернете, а не в соседней комнате. Пинговать шлюз не поможет понять работает у вас интернет или нет. Если пинг не проходит, то не работает сеть, а если проходит, то не работает DNS. Не работать он может по причине:

1) Самая вероятная - вы не прописали к нему маршрут

2) У вас сбились настройки DNS

3) Почти невероятная, но возможная - DNS сервер провайдера глючит.

Для начала научимся смотреть настройки DNS. Для этого запустим cat /etc/resolv.conf:

search corbina.ru
nameserver 195.14.50.1
nameserver 195.14.50.21

Первая строчка это то окончание, которое рекомендуется добавлять ко всем именам, к которым вы обращаетесь. Нам это не интересно. Далее идут 2 сервера DNS провайдера. Как они туда попали? Это произошло благодаря DHCP получению настроек. И если там нет нужных IP DNS серверов, то надо либо их вписать, либо получить настройки еще раз: dhclient xl0(смотри предыдущий пункт). Если у нас есть настройки, то теперь надо посмотреть если ли связь с серверами: ping 195.14.50.1. Естественно надо подставить IP для ваших серверов DNS. Если пинг проходит, то странно, что преобразование имён всё еще не работает. Скорее всего пинг не пройдёт и это будет значить отсутствие маршрута. Но это мы легко исправим: route add 195.14.50.1 10.83.0.17, ну и второй пропишите, заменив адрес шлюза на свой. Теперь должно работать.

Всегда проверяйте не проблемы ли с DNS вызывают у вас иллюзию неработоспособности сети при настройке компьютера. Благо проверить легко, да и исправить тоже.

Настройка VPN

Сейчас сделаю пояснение, что если вы можете себе позволить default путь установить на ваш шлюз, то можно особо не заботиться о маршрутах, но в моём случае трёх сетевых это важно и я не единственный, кому потребуется более долгий но и более понятный в своих этапах путь. Есть важная проблема с VPN серверами, которую обязательно надо понимать если вы не тупо подставляете чужие конфиги, а хотите понять. Эта проблема то, что серверов много и обращаясь к ним по имени как учит провайдер мы всё время общаемся с новым. Простой пример: уничтожим путь по умолчанию route delete default и добавляем путь к VPN серверу route add vpn.corbina.net 10.83.0.17. Теперь вроде при последующем обращении к vpn.corbina.net мы должны туда попасть, так как мы же прописали путь как с этим хостом связаться. Однако команда ping vpn.corbina.net имеет 5% шанс на успех ведь при запуске этой команды адрес сервера окажется скорее всего другой чем тот, что добавился в маршрут. По идее надо добавить все адреса которые может иметь VPN сервер в маршруты, но так делать не стоит ибо тогда не заработает VPN. Дело в том, что при установлении соединения по VPN пытается создаться маршрут к этому серверу не через наш шлюз, а через виртуальный тоннель. При этом оно натыкается на уже созданный нами маршрут и выдаёт ошибку:

File exists

Как решить проблему? Очень просто: надо добавить не каждый IP, а тот диапазон, который они занимают. Тогда если у нас есть более общее правило на весь диапазон. то частное правило которое будет навязывать VPN сможет проявиться. Как посмотреть все IP для vpn.corbina.net? Можно с помошью команды nslookup vpn.corbina.net:

;; Truncated, retrying in TCP mode.
Server:		 217.117.112.1
Address:		217.117.112.1#53

Non-authoritative answer:
Name:   vpn.corbina.net
Address: 195.14.38.17
Name:   vpn.corbina.net
Address: 195.14.38.18
Name:   vpn.corbina.net
Address: 195.14.38.19
Name:   vpn.corbina.net
Address: 195.14.38.20
Name:   vpn.corbina.net
Address: 195.14.38.21
Name:   vpn.corbina.net
Address: 85.21.0.5
Name:   vpn.corbina.net
Address: 85.21.0.6
Name:   vpn.corbina.net
Address: 85.21.0.7
Name:   vpn.corbina.net
Address: 85.21.0.8
Name:   vpn.corbina.net
Address: 85.21.0.9
Name:   vpn.corbina.net
Address: 85.21.0.32
Name:   vpn.corbina.net
Address: 85.21.0.33
Name:   vpn.corbina.net
Address: 85.21.0.35
Name:   vpn.corbina.net
Address: 85.21.0.36
Name:   vpn.corbina.net
Address: 85.21.0.37
Name:   vpn.corbina.net
Address: 85.21.0.38
Name:   vpn.corbina.net
Address: 85.21.0.39
Name:   vpn.corbina.net
Address: 195.14.38.1
Name:   vpn.corbina.net
Address: 195.14.38.2
Name:   vpn.corbina.net
Address: 195.14.38.3
Name:   vpn.corbina.net
Address: 195.14.38.4
Name:   vpn.corbina.net
Address: 195.14.38.10
Name:   vpn.corbina.net
Address: 195.14.38.11
Name:   vpn.corbina.net
Address: 195.14.38.12
Name:   vpn.corbina.net
Address: 195.14.38.13
Name:   vpn.corbina.net
Address: 195.14.38.14
Name:   vpn.corbina.net
Address: 195.14.38.15
Name:   vpn.corbina.net
Address: 195.14.38.16

, а если хочется список в чистом виде, то можно это команду пропарсить nslookup vpn.corbina.net|grep Address|tail +2|cut -f 2 -d ' '. Этот список удобно сохранять в файл.

Так что же нам нужно добавить в роутинг? Взгляните на список IP - это два диапазона с дырками: 195.14.38.1-195.14.38.21 и 85.21.0.6-85.21.0.39. Добавим эти диапазоны, слегка их расширив (иначе нельзя). Первый расширим до 195.14.38.0-195.14.38.31, а второй до 85.21.0.0-85.21.0.63. Для добавления нужно выполнить две команды route add 195.14.38.1/27 <gateway> и route add 85.21.0.1/26 <gateway>, где <gateway> надо заменить на ваш шлюз. Теперь должно работать ping vpn.corbina.net:

PING vpn.corbina.net (195.14.38.11): 56 data bytes
64 bytes from 195.14.38.11: icmp_seq=0 ttl=252 time=0.801 ms
64 bytes from 195.14.38.11: icmp_seq=1 ttl=252 time=0.784 ms

Следующий шаг после правильной настройки маршрутизации до VPN серверов будет подключение протокола GRE, который Микрософт придумало для туннелей. Для управление включениями и выключениями есть команда sysctl. Добавим протокол GRE вот так: sysctl net.inet.gre.allow=1

net.inet.gre.allow: 0 -> 1

Это будет значить, что вы его включили из состояния 0 в состояние 1.

Теперь мы поставим pptp программу для управления пересылкой данных в туннеле. Для этого нельзя скачать какую-нибудь версию из сети, так как все новые версии похоже идут только под Линукс. Они даже не компилируются, а после исправления кода так, что изменений быть не должно они куомпилируются, то жестоко не работают. Кроме того нельзя скачать mpd, который тут так рекламируют. Он не будет компилироваться под OpenBSD. А встроенный isakmpd, который должен его заменять не поможет так как его туннели устанавливаются через протокол IPsec, а это лишь один из трёх протоколов и естественно Микрософт использует не его. Ставить pptp мы будем из портов. Там поставится старая версия, но работать всё будет тип-топ. Ставить программы из портов можно так: Зайти в директорию, где порты лежат. Наприме они лежат в /usr/ports/ Далее заходим в /usr/ports/net/pptp/: cd /usr/ports/net/pptp/ Там делаем make, а затем make install. То есть сначала всё компилируем, а потом записываем в нудные директории чтобы уже запускать. Pptp попадёт скорее всего в /usr/local/sbin/. Запомним это.

Теперь настроим PPP, который будет устанавливать соединение используя pptp. Для этого нужно всего лишь создать конфигурационный файл, который должен лежать в /etc/ppp/ppp.conf. Отредактируем его: vi /etc/ppp/ppp.conf. Возможно файла там раньше не было и создастся новый. В любом случае конечный вариант сведём к

default:
 set log Phase Chat LCP IPCP CCP tun command
 disable ipv6cp
corbina:
 set device /dev/tun0
 set device "!/usr/local/sbin/pptp vpn.corbina.net --nolaunchpppd --loglevel 0 --nobuffer --logstring pptp"
 set timeout 0
 set authname <Ваш логин>
 set authkey <Ваш пароль>
 set ifaddr 0 0

Важно сделать отступы например в 2 пробела для всех строчек не являющихся метками, а именно default и corbina. Что же содержиться в этом файле: Во-первых метки мы будем использовать когда будем запускать ppp. Во-вторых мы здесть указываем свои пароль и логин для авторизации сервером, ну и наконец важная строчка, где запускается pptp клиент и ему указывается куда стучаться для VPN соединения (vpn.corbina.net), а также ему указывается не запускать pppd. Всё остальное я сам не понимаю, а простых туториалов я не нашёл. Если в конце добавить строчку

  add! default HISADDR

то это будет альтернативно команде route add default <IP того VPN сервера, куда мы дозваниваемся>. Мы пока эту строчку писать не будем чтобы разбить всё на более мелкие шаги. Перейдём к дозвону. Запустим ppp командой ppp -ddial corbina. С помощью параметров мы указываем ему как поддерживать соединение при разрывах связи и с какой метки считывать конфигурационные параметры. Реакцией на такую команду может стать что-то типа:

Working in ddial mode
Using interface: tun0
Jun 18 22:47:38 stelm pptp[30007]: log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:580]: Client connection established.
Jun 18 22:47:39 stelm pptp[30007]: log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:708]: Outgoing call established (call ID 0, peer's call ID 62919).
Jun 18 22:47:39 stelm ppp[18638]: tun0: Warning: ff02::%tun0/32: Change route failed: errno: Undefined error: 0
Jun 18 22:47:39 stelm routed[29277]: IP_ADD_MEMBERSHIP ALLHOSTS: Can't assign requested address
Jun 18 22:47:39 stelm routed[29277]: IP_ADD_MEMBERSHIP ALLHOSTS: Can't assign requested address
Jun 18 22:47:39 stelm routed[29277]: setsockopt(IP_ADD_MEMBERSHIP RIP): Can't assign requested address
Jun 18 22:47:39 stelm routed[29277]: setsockopt(IP_ADD_MEMBERSHIP RIP): Can't assign requested address
Jun 18 22:47:39 stelm routed[29277]: punt RTM_CHANGE without mask
Jun 18 22:47:39 stelm routed[29277]: punt RTM_CHANGE without mask

Мы здесь видим, что у нас теперь есть новая виртуальная стевая карта tun0 - туннель. Далее мы видим, что мы устанавливаем соединение и вроде успешно. Потом идёт ошибка роутинга IPv6 и она безвредна. Настройка ppp вида disable ipv6cp должна от этого спасать, но видно, что не спасает. Дальше хуже с пониманием. Идут 6 ошибок роутинга, связанные с какими-то попытками прописать какие-то маршруты. Можно пытаться влезть в подробный лог и разобраться в чём дело, но работать будет и так. На всякий случай учу, что если интересно что не нравиться демону роутинга, то запускаем его командой routed -t -T /tmp/somefile и он начнёт писать в этот somefile подробности своих возмущений. Итак наверное мы сейчас получили IP, получили новый маршрут к VPN серверу и сейчас мы это проверим. Начнём с ifconfig tun0:

tun0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1464
	inet 89.178.29.67 --> 195.14.38.4 netmask 0xffffffff

Значит тут написано, что мы имеем включённую в данный момент (UP) сетевую вида соединение точка-точка (POINTTOPOINT) и оно умеет делать MULTICAST. Далее мы видим свой новый IP, а также IP VPN сервера с которым у нас туннель. Теперь стоит проверить таблицу роутинга route -n show (я привожу лишь верхнюю часть):

Internet:

Destination Gateway Flags Refs Use Mtu Interface

default 10.83.0.17 UGS 0 2199328 - fxp0

10/8 10.83.0.17 UGS 0 9 - xl0

10.83/16 link#3 UC 0 0 - xl0

10.83.0.17 00:17:59:af:a9:51 UHLc 0 3 - xl0

10.83.17.237 00:15:e9:76:c4:21 UHLc 0 0 - xl0

10.83.18.55 127.0.0.1 UGHS 0 0 33224 lo0

83.102.146.96 10.83.0.17 UGHS 0 0 - xl0

85.21.0.0/26 10.83.0.17 UGS 0 4370 - xl0

85.21.29.242 10.83.0.17 UGHS 0 0 - xl0

85.21.52.254 10.83.0.17 UGHS 0 0 - xl0

85.21.79/24 10.83.0.17 UGS 0 263 - xl0

85.21.88.130 10.83.0.17 UGHS 0 0 - xl0

85.21.90/24 10.83.0.17 UGS 0 1497 - xl0

85.21.138.192/27 10.83.0.17 UGS 0 0 - xl0

85.21.138.210 10.83.0.17 UGHS 0 0 - xl0

89.178.29.67 127.0.0.1 UH 0 0 33224 lo0

127/8 127.0.0.1 UGRS 0 0 33224 lo0

127.0.0.1 127.0.0.1 UH 0 50 33224 lo0

192.168.212.0/29 link#2 UC 0 0 - vr0

192.168.212.2 4c:00:10:38:7c:11 UHLc 0 5014699 - vr0

195.14.38.0/27 10.83.0.17 UGS 0 194 - xl0

195.14.38.4 89.178.29.67 UH 0 4 1464 tun0

195.14.50.16 10.83.0.17 UGHS 0 0 - xl0

195.14.50.26 10.83.0.17 UGHS 0 217 - xl0

217.117.116.128/25 link#1 UC 0 0 - &nbs

Изменено пользователем =Zap=

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Продолжение предыдущего поста о настройке VPN в Корбине и раздачи интернета в домашнюю сеть

Подготовка внутренней домашней сети

Начнём с того, что нам нужно воткнуть вторую сетевую карту. У меня их 3 и для внутренней сети мы будем использовать интерфейс vr0. Про то как найти имя своей карты читай первый пункт. Далее нам нужно выбрать диапазон IP для нашей домашней сети. Выбирать мы имеем право из следующих диапазонов:

10.0.0.0	-	10.255.255.255
172.16.0.0	-	172.31.255.255
192.168.0.0	-	192.168.255.255

Эти диапазоны выделены для внутреннего применения и поэтому мы можем занимать их если мы сидим на выходе в интернет и больше ничего нет. Однако в Корбине используются IP из подсети 10/8, так что нам их занимать не стоит иначе мы можем перекрыться с какими-то другими компьютерами из Корбины, а роутер будет ругаться. В принципе наиболее непопулярными являются IP из диапазона 172.16/12 и стоит выбрать что-то именно там, но я уже настроил всё с IP из сети 192.168/16. Конечно нам нужна не вся сеть и нужно определиться с количеством будущих подключений из квартиры. 6 обычно достаточно, но не жалко взять и больше. Кроме того не стоит занимать начало диапазона чтобы не перекрыться с кем-нибудь, и в результате мы займём 192.168.212.0-192.168.212.7 или в другом написании 192.168.212.0/29.

Давайте начнём с прописывания настроек для нашей внутренней сетевой карты vr0. Редактируем файл /etc/hostname.vr0 vi /etc/hostname.vr0 и пишем там следующее:

inet 192.168.212.1 255.255.255.248 NONE

Тем самым при загрузке будет устанавливаться IP роутера 192.168.212.1 и маска подсети 255.255.255.248. Почему именно такой IP роутера? Потому что связываться ни с IP, заканчивающимся на 0, ни с IP являющимся последним в списке не хочется. Эти адреса могут оказаться выделенными. Теперь при перезагрузке настройки vr0 должны установиться правильные. А ручками мы можем это сделать командой ifconfig vr0 inet 192.168.212.1 netmask 255.255.255.248. Здесь мы указываем какой интерфейс будем менять и какой IP с какой маской установим. Теперь можно проверить как всё установилось: ifconfig vr0:

vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	address: 00:0d:88:4e:c6:aa
	media: Ethernet autoselect (100baseTX full-duplex)
	status: active
	inet6 fe80::20d:88ff:fe4e:c6aa%vr0 prefixlen 64 scopeid 0x2
	inet 192.168.212.1 netmask 0xfffffff8 broadcast 192.168.212.7

Видим наш IP и маску (0xfffffff8). Можно проверить соединение: подключить кабелем свитч, включить дополнительные компьютеры и прописать им другие IP из нашей внутренней сети, а потом попинговать роутер, но мы этим займёмся позже, а сейчас запустим DHCP на нашем роутере чтобы он мог выдавать настройки внутренним машинам автоматически. Для этого нужно прописать файл конфигурации dhcpd программы. Отредактируем /etc/dhcpd.conf командой vi /etc/dhcpd.conf:

shared-network LOCAL-NET {
	option  domain-name "mydomain.net";
	option  domain-name-servers 195.14.50.1 195.14.50.21;

	subnet 192.168.212.0 netmask 255.255.255.248 {
			option routers 192.168.212.1;
			option subnet-mask 255.255.255.248;
			range 192.168.212.3 192.168.212.6;
			default-lease-time 604800;
			max-lease-time 1209600;
	}

По-порядку: здесь описывается некая сеть, где все имена компьютеров будут иметь окончание mydomain.net, например vasya.mydomain.net, где DNS серверами будут 195.14.50.1 и 195.14.50.21, где внутренняя сеть это 192.168.212.0 - 192.168.212.7 и где шлюзом будет наш роутер, а маска подсети 255.255.255.248. Почему шлюз это роутер? Потому, что чтобы пакет дошёл к нужному IP мы должны послать его какой-то сетевой карте. Именно по MAC адресам сетевых карт распространяются пакеты. Мы будем посылать все пакеты от внутренних компов нашему роутеру, а он позаботится о них. На самом деле он пошлёт их роутеру Корбины, а тот их будет посылать всё дальше, но это не наша забота. Еще в файле настроек есть диапазон в котором мы будем выдавать внутренние IP и время на которое мы будем их запоминать в секундах. То есть включая компьютер не слишком редко можно быть уверенным, что наш IP не забудут и выдадут тот же самый. Теперь нужно запустить DHCP демона командой dhcpd vr0, где мы указываем интерфейс в который надо предоставлять свои услуги по выдаче IP. Не надо писать другие интерфейсы, а особенно xl0, который смотрит в сеть Корбины. Если повалите сетку Корбины и вас за это занесут в чёрный список провайдеров, то обижаться не стоит.

Чтобы демон запускался добавим запускающую его строчку в /etc/rc.local до запуска нашего скрипта прописывания маршрутов до внутренних ресурсов Корбины. А именно впишем там

dhcpd vr0

или отредактируем /etc/rc.conf с помощью vi /etc/rc.conf и найдём там строчку:

dhcpd_flags=NO			   # for normal use: ""

Вписываем там вместо NO "vr0".

Теперь пора проверить как всё заработало. Воткните в роутер кабель, другим концом воткните его в свитч, а свитч подсоедините кабелем к вашему компьютеру. Если хотите поэтапной проверки, то выключите свитч из сети. В настройках винды напишите себе IP 192.168.212.4 и маску 255.255.255.248. Остальное не заполняйте. Включите свитч и посмотрите появился ли сигнал на обоих картах. В OpenBSD это можно сделать командой ifconfig vr0:

vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	address: 00:0d:88:4e:c6:aa
	media: Ethernet autoselect (100baseTX full-duplex)
	status: active
	inet6 fe80::20d:88ff:fe4e:c6aa%vr0 prefixlen 64 scopeid 0x2
	inet 192.168.212.1 netmask 0xfffffff8 broadcast 192.168.212.7

и обращением внимания на поле status: active. Или посмотрите на светодиод на сетевой карте. Далее пропингуйте шлюз с виндового компьютера (для этого надо зайти в пункт меню "Выполнить" и набрать там cmd). ping 192.168.212.1:

Pinging 192.168.212.1 with 32 bytes of data:

Reply from 192.168.212.1: bytes=32 time<10ms TTL=255
Reply from 192.168.212.1: bytes=32 time<10ms TTL=255
Reply from 192.168.212.1: bytes=32 time<10ms TTL=255

Это копия виндового окна. Если пинг проходит, то запустите в винде команду ipconfig /all и полюбуйтесь на прописанный вами IP и маску. Теперь поставьте настройки сетевой карты на автоматические и нажмите OK. После этого снова проверьте ipconfig /all. Вы должны увидеть другой IP и добавившиеся адреса шлюза и DNS серверов:

Ethernet adapter Home network:

	Connection-specific DNS Suffix  . :
	Description . . . . . . . . . . . : Realtek RTL8139(A) PCI Fast Ethernet
Adapter #2
	Physical Address. . . . . . . . . : 4C-00-10-38-7C-11
	DHCP Enabled. . . . . . . . . . . : Yes
	IP Address. . . . . . . . . . . . : 192.168.212.2
	Subnet Mask . . . . . . . . . . . : 255.255.255.248
	Default Gateway . . . . . . . . . : 192.168.212.1
	DNS Servers . . . . . . . . . . . : 195.14.50.1
										195.14.50.21

Если всё ОК, то пора приступить к настройке NAT.

Настройка NAT на pf

Включим pf если он не включён. Для этого залезем в /etc/rc.conf с помощью vi /etc/rc.conf. Найдём там строчки:

pf=YES				  # Packet filter / NAT
pf_rules=/etc/pf.conf		   # Packet filter rules file

и проверим, что они именно такие. А именно pf включён и его конфигурационный файл это /etc/pf.conf. pf это мощная вещь, позволяющая сделать почти любое управление параметрами пакетов которые попадают на роутер. Именно pf мы и попросим брать все пакеты с интерфейса внутренней сети, переделывать их для внешней сети и отсылать туда. Для этого мы должны проверить, что включена переадресация пакетов sysctl net.inet.ip.forwarding:

net.inet.ip.forwarding=1

Если там стоит нолик, то делаем sysctl net.inet.ip.forwarding=1.

Теперь добавим строчку:

net.inet.ip.forwarding=1		# 1=Permit forwarding (routing) of packets

в файл /etc/sysctl.conf чтобы эта настройка устанавливалась автоматически при загрузке.

Перейдём к настройке pf. Для этого начнём редактирование /etc/pf.conf и закомментируем всё и допишем:

table <corbina> persist file "/etc/corbina.nets"
nat on xl0 from vr0/29 to <corbina> -> (xl0)
nat on tun0 from vr0/29 to any -> (tun0)

Первая строчка это элегантное решение для перечисления всех сетей, являющихся внутренними ресурсами (помните мы создавали файл со списком этих сетей). Таким образом мы вводим таблицу с именем <corbina> (скобки обязательны) и заставляем её храниться в памяти директивой persist даже при отсутствии ссылок на неё. Наконец мы указываем из какого файла считать таблицу вместо перечисления всех сетей заново. Далее идут 2 правила для NAT. Подробнее можно почитать мануал, а здесь я переведу на русский первое правило: Делать nat на интерфейс xl0 для пакетов направляющихся с IP из подсети интерфейса vr0 в те сети, которые являются внутренними ресурсами Корбины и подставлять в эти пакеты IP интерфейса сетефой карты воткнутой в сеть Корбины. Для второй строчки правила отличаются лишь тем, что теперь мы хотим интернета и поэтому будет посылать в туннель пакеты направляющиеся куда угодно.

Теперь мы сконфигурировали pf и можем запустить его командой: pfctl -e -f /etc/pf.conf. Здесь мы включаем pf и сразу указываем ему файл с настройками.

Если pf ничего не сказал при запуске, то синтаксис он понял. Проверить каждое из NAT правил можно пропинговав шлюз (в моём случае 10.83.0.17) с виндового компьютера внутренней подсети ping 10.83.0.17 и просто попытавшись зайти на сайт какой-нибудь (не Корбиновский).

Если не получилось, то стоит запустить pfctl -s all

TRANSLATION RULES:
nat on xl0 inet from 192.168.212.0/29 to <corbina> -> (xl0) round-robin
...

FILTER RULES:
No queue in use

STATES:
self tcp 192.168.212.2:2164 -> 10.83.18.55:58372 -> 10.184.19.30:17560	   SYN_SENT:CLOSED
self tcp 192.168.212.2:1990 -> 10.83.18.55:51787 -> 85.21.79.38:411	   ESTABLISHED:ESTABLISHED
...
...
...
TIMEOUTS:
tcp.first				   120s
tcp.opening				  30s
tcp.established		   86400s
...

LIMITS:
states	 hard limit  10000
src-nodes  hard limit  10000
frags	  hard limit   5000

TABLES:
corbina

OS FINGERPRINTS:
345 fingerprints loaded

Здесь можно увидеть массу информации, но нас интересует в первую очередь правила (translation rules), где должны быть те строчки, что мы писали в конфигурации, а также нас интересуют загруженные таблицы из группы tables. Можно посмотреть таблицу corbina командой pfctl -t corbina -T show и проверить правильно ли считалось.

Если всё заработало, то рано расслабляться - по информации отсюда в системах OpenBSD 3.8 и более старых pf при загрузке увидев интерфейс tun0 в правилах сразу откажется работать, так как туннель еще не создан. Решение из той же ссылки - создадим ненастроенные интерфейсы при загрузке. Для этого я придумал сделать так: заходим в /etc/rc файл и находим там такой фрагмент кода:

if [ "X${pf}" != X"NO" ]; then
	if [ -f ${pf_rules} ]; then
			pfctl -f ${pf_rules}
	fi
fi

Тут проверяется нужен ли pf и если нужен, то он загружает файл конфигурации, который настраивается в rc.conf (у нас это /etc/rc.conf). Если мы ничего не поменяем, то на третей строчке этого кода при загрузке мы получим синтаксическую ошибку конфигурации pf. Поэтому до этого кода, но после netstart команды напишем:

# add one tun interface for pf rules correct startup
ifconfig tun0 create

Я написал с комментарием, чтобы потом не забыть. Эта строчка создаст tun0 интерфейс и pf сможет загрузить правила, которые ссылаются на этот интерфейс.

Пробуем перезагрузиться reboot.

После перезагрузки если домашняя сеть осталась всё-таки без интернета, то проверяем по цепочке: есть ли интернет на роутере, затем выдали ли внутреннему компьютеру правильный IP, затем какие правила загружены в pf(для этого можно использовать не ту команду, что я привёл выше, а более частную pfctl -s nat) и наконец проверяем роутинг.

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

Настройка резервного канала

В моём случае второй канал даёт провайдер, который без всяких VPN выдаёт сразу внешний фиксированный IP. Этот случай мы и рассмотри подробно, так что переделать всё на случай второго VPN или еще как, - будет очень просто.

Добавим в роутер третью сетевую карту и у меня это fxp0. Настройки мы прописывать умеем, но предположим, что мы их получаем по DHCP. Так что в нашем файле /etc/hostname.fxp0 будет находиться строчка:

dhcp

Тут уже начинаются некоторые проблемы, так как каждый из dhcp ответов каждого провайдера захочет установить свои DNS сервера. В результате победит тот, что запустится вторым. Ну ничего - это мы еще переживём - вот с роутингом будет проблема. Если раньше был один выход в большой мир, то теперь есть 2 равноценных и если всё настраивать как написано в этом руководстве, то проблем не будет. А проблемы могут появляться если вы не прописали маршруты к VPN серверам - тогда возможно подключаться в VPN Корбины вы будете через второго провайдера и это не соответствует нашим целям. Кроме того таблица роутинга должна соответствовать правилам NAT.

На всём этом мы остановимся подробнее, а пока будем считать что настройки второго провайдера мы получили по DHCP либо перезагрузкой, либо командой dhclient fxp0 и у нас установился в конце концов выход в интернет через Корбину так как последним при загрузке запускается наш скрипт дозвона и он устанавливает выход (шлюз) через туннельный интерфейс.

Давайте определимся с полученными настройками. Для этого напишем ifconfig -a:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
	inet 127.0.0.1 netmask 0xff000000
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	address: 00:a0:c9:e8:46:4d
	media: Ethernet autoselect (100baseTX full-duplex)
	status: active
	inet6 fe80::2a0:c9ff:fee8:464d%fxp0 prefixlen 64 scopeid 0x1
	inet 217.117.116.197 netmask 0xffffff80 broadcast 217.117.116.255
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	address: 00:0d:88:4e:c6:aa
	media: Ethernet autoselect (100baseTX full-duplex)
	status: active
	inet 192.168.212.1 netmask 0xfffffff8 broadcast 192.168.212.7
	inet6 fe80::20d:88ff:fe4e:c6aa%vr0 prefixlen 64 scopeid 0x2
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	address: 00:01:02:28:23:ac
	media: Ethernet autoselect (100baseTX full-duplex)
	status: active
	inet6 fe80::201:2ff:fe28:23ac%xl0 prefixlen 64 scopeid 0x3
	inet 10.83.18.55 netmask 0xffff0000 broadcast 10.83.255.255
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33224
pfsync0: flags=0<> mtu 2020
enc0: flags=0<> mtu 1536
tun0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1464
	inet 89.178.92.91 --> 195.14.38.10 netmask 0xffffffff

Видим наш IP (217.117.116.197) на fxp0 и маску.

Теперь проверим таблицу роутинга route -n show:

Internet:
Destination		Gateway			Flags	Refs	  Use	Mtu  Interface
default			195.14.38.10	UGS		 0	98244	  -   fxp0
10/8			   10.83.0.17		 UGS		 0	 4149	  -   xl0
10.83/16		   link#3			 UC		  0		0	  -   xl0
10.83.0.17		 00:17:59:af:a9:51  UHLc		0		0	  -   xl0
10.83.17.237	   00:15:e9:76:c4:21  UHLc		0		0	  -   xl0
10.83.18.1		 00:e0:4d:08:f1:57  UHLc		0	 1464	  -   xl0
10.83.18.55		127.0.0.1		  UGHS		0		0  33224   lo0
83.102.146.96	  10.83.0.17		 UGHS		0		0	  -   xl0
85.21.0.0/26	   10.83.0.17		 UGS		 0		0	  -   xl0
85.21.29.242	   10.83.0.17		 UGHS		0		0	  -   xl0
85.21.52.254	   10.83.0.17		 UGHS		0		0	  -   xl0
85.21.79/24		10.83.0.17		 UGS		 0	54605	  -   xl0
85.21.88.130	   10.83.0.17		 UGHS		0		0	  -   xl0
85.21.90/24		10.83.0.17		 UGS		 0	 1805	  -   xl0
85.21.138.192/27   10.83.0.17		 UGS		 0		0	  -   xl0
85.21.138.210	  10.83.0.17		 UGHS		0		0	  -   xl0
89.178.92.91	   127.0.0.1		  UH		  0		0  33224   lo0
127/8			  127.0.0.1		  UGRS		0		0  33224   lo0
127.0.0.1		  127.0.0.1		  UH		  0	  160  33224   lo0
192.168.212.0/29   link#2			 UC		  0		0	  -   vr0
192.168.212.2	  4c:00:10:38:7c:11  UHLc		0   200786	  -   vr0
195.14.38.0/27	 10.83.0.17		 UGS		 0	69255	  -   xl0
195.14.38.10	   89.178.92.91	   UH		  0		0   1464   tun0
195.14.50.1		10.83.0.17		 UGHS		0	  339	  -   xl0
195.14.50.16	   10.83.0.17		 UGHS		0		0	  -   xl0
195.14.50.21	   10.83.0.17		 UGHS		0		1	  -   xl0
195.14.50.26	   10.83.0.17		 UGHS		0		0	  -   xl0
217.117.116.128/25 link#1			 UC		  0		0	  -   fxp0
217.117.116.129	00:19:5b:12:b4:03  UHLc		0	   11	  -   fxp0
217.117.116.197	127.0.0.1		  UGHS		0		0  33224   lo0
224/4			  127.0.0.1		  URS		 0		0  33224   lo0

default выходит через один из шлюзов vpn.corbina.net, а помимо него существуют еще внутренняя, корбиновская локальная и вторая сеть.

Что могло пойти не так: Если маршруты к VPN прописаны, то независимо от default шлюза создание туннеля должно было пойти через xl0, но важно чтобы был доступен DNS или vpn.corbina.net не разрешиться в один из IP. Если не прописан маршрут к Корбиновским DNS, то если они загрузились последними и стёрли DNS от второго провайдера, то доступ к Корбиновским DNS пойдёт через интернет второго провайдера, а там нам не ответят, так как нас не знают. В случае если маршруты к локальным ресурсам прописаны в обоих локальных сетях обоих провайдеров, то сработает любой DNS сервер любого из двух провайдеров.

Для того чтобы перейти к переключению между провайдерами нужно понять как организуется управление пакетами в pf и в таблице роутинга в случае двух каналов во внешний мир. Структуру обработки пакетов можно себе представить так:

openbsdpf.gif

Наша задача это запуск пакетов по красной стрелочке, но кто-то должен решать по какому из выходов отправлять пакет и какой адрес шлюза использовать. Рассмотрим 2 реализации механизма маршрутизации пакетов после NAT.

1) Решение на основе таблицы роутинга. Это неудобное решение, но его полезно понять чтобы потом перейти к новому решению. Предположим пакет отправляется из внутренней сети наружу и попадает в pf. Там на него действуют правила:

nat on xl0 from vr0/29 to <corbina> -> (xl0)
nat on tun0 from vr0/29 to any -> (tun0)

А именно его адрес отправки заменяется на адрес интерфейса xl0 или tun0 в зависимости куда пакет идёт. Дальше пакет попадает в OpenBSD, но до сих пор неизвестно какому шлюзу отправлять пакет. Что делает система? Она использует таблицу роутинга, где у нас написано, что пакеты надо отсылать VPN шлюзу в туннельный интерфейс если они идут в интернет и в локалку Корбины если они идут на локальные ресурсы. То есть используется определённая из красных стрелочек на выход и проблем нет.

Теперь если мы хотим поменять канал, то мы должны поменять правила трансляции адресов в pf, а также поменять таблицу роутинга чтобы ядро знало куда слать пакеты, у которых адреса уже подменяны на IP, выданный вторым провайдером. Это неудобно, но именно так я реализовал систему в начале. Пользуясь таким способом мы не сможем, например, отправлять пакеты с одними портами назначения одному провайдеру, а другие пакеты, второму провайдеру.

2) Решение на основе правил в pf. pf позволяет указывать пакетам какому шлюзу их надо доставлять и это решение идёт в обход таблицы роутинга. То есть пакет попадает сначала в pf, где ему делают NAT и указывают куда роутиться, а затем он попадает в OpenBSD, где его отправляют на нужный интерфейс выхода. И никаких двусмысленностей уже не возникает. Единственное, что нужно трогать при переключении между провайдерами для внутренней подсети это правила pf.

Перед рассмотрением конкретной реализации мы должны получить IP шлюзов каждого из провайдеров. Как посмотреть шлюз я так и не знаю, но пока я придумал способ запускать dhclient на том интерфейсе, где мы хотим узнать IP шлюза и смотреть его установившимся в роутинге. IP шлюза второго провайдера пусть будет фиксированным и равным 217.117.116.129. Шлюз Корбины это тот VPN сервер из пула, к которому мы подключились. Его IP я предлагаю парсить из настроек туннеля. Действительно запустите ifconfig tun0:

tun0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1464
	inet 89.178.92.91 --> 195.14.38.10 netmask 0xffffffff

Вот он наш 195.14.38.10 шлюз. Отпарсим его командой: ifconfig tun0|grep tun0: -A 1|tail -n 1|cut -f 4 -d ' ', а именно вырежем оттуда 2 строчки, возьмём вторую и вырежем оттуда четвёртое слово.

Теперь реализации переключения между провайдерами.

1) Через таблицу маршрутизации:

Создадим 2 файла правил pf. В одном (pf.conf.c) интернет будет идти через Корбину (он ничем не отличается от нашего старого), так что создадим его из старого командой cp /etc/pf.conf /etc/pf.conf.c.

Напомню его вид cat /etc/pf.conf.c:

table <corbina> persist file "/etc/additional.nets"
nat on xl0 from vr0/29 to <corbina> -> (xl0)
nat on tun0 from vr0/29 to any -> (tun0)

Второй файл назовём pf.conf.2 и будет он работать при падении Корбины. Вот его содержание:

nat on fxp0 from vr0/29 to any -> (fxp0)

То есть выходим в сеть через второго провайдера, а об остальном забудем. Можно оставить и старую строчку касательно внутренних ресурсов. Это кому как нравится. Видно, что эти файлы пока отличаются только тем, что указывают разные подменные IP для NAT. Остаётся сделать так чтобы таблица роутинга была согласована с текущими настройками pf.

Напишем такой скрипт переключения /bin/switch_2:

pfctl -f /etc/pf.conf.2
route change default 217.117.116.129

и скрипт переключения обратно switch_c:

gateip=`ifconfig tun0|grep tun0: -A 1|tail -n 1|cut -f 4 -d ' '`
echo "Using $gateip as VPN server"
pfctl -f /etc/pf.conf.c
route change default $gateip

В первом мы загружаем новые правила и меняем маршрут на шлюз второго провайдера.

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

Напомню, что этот способ плох тем, что любой сбой таблицы маршрутизации приведёт к рассогласованию её с правилами NAT и пакеты будут с IP первого провайдера, но отправляться (и исчезать) через другого провайдера. Далее нельзя делать policy based routing. Да и неправильно всё время при переключении дёргать систему маршрутизации самого роутера.

2) Способ только через правила pf.

Нужно добавить правило маршрутизации в pf. Это делается директивой route-to, которая используется в pass директивах. Я напишу новый файл конфигурации pf.conf.2 и объясню каждую строчку cat pf.conf.2:

proc = "fxp0"
internal = "vr0"
proc_gw = "217.117.116.129"
internal_net = "vr0/29"

# General rules
nat on $proc from $internal_net to any -> ($proc)
# Routing override
pass in quick on $internal from $internal_net to $internal
pass in on $internal route-to ($proc $proc_gw) from $internal_net to any

Первые 4 строчки сохраняют настройки и имена интерфейсов в переменные. Следующая значащая строка это правило NAT полностью эквивалентное тому, что было в pf.conf.2 ранее. Последние 2 директивы указывают куда делать роутинг. Их порядок важен. Первая из них говорит, что при обращении к самому роутеру нужно этот пакет больше не обрабатывать (quick), а пропустить до системы. Если эту строчку не писать, то связь с роутером прервётся. Не знаю что будет если поменять порядок этих двух строчек.

Вторая строчка говорит, что если что-то идёт из внутренней подсети куда угодно, то надо это не выкидывать и роутить на интерфейс $proc=fxp0 со шлюзом $pro_gw=217.117.116.129.

Для переключения надо только загрузить новые правила: pfctl -f /etc/pf.conf.2. Оформим это в виде скрипта /bin/switch_2:

echo "pfctl -f /etc/pf.conf.2"
pfctl -f /etc/pf.conf.2

Для выхода в инет через Корбину есть только одна новая проблема: шлюз всё время меняется и его нельзя вбить статически в файл настроек pf. Поэтому создадим файл, где вместо адреса шлюза будет стоять Corbina_gateway, а затем подменим это слово на отпарсенный адрес шлюза. Для этого нужен файл оригинал настроек pf. Мы назовём его origin.pf.conf.c:

corbina_tun = "tun0"
corbina_loc = "xl0"
internal = "vr0"
corbina_tun_gw = "Corbina_gateway"
corbina_loc_gw = "10.83.0.17"
internal_net = "vr0/29"

table <corbina> persist file "/etc/additional.nets"
# Local resource
nat on $corbina_loc from $internal_net to <corbina> -> ($corbina_loc)
# General rules
nat on $corbina_tun from $internal_net to any -> ($corbina_tun)
# Routing override
pass in quick on $internal from $internal_net to $internal
pass in on $internal route-to ($corbina_tun $corbina_tun_gw) from $internal_net
to any
pass in on $internal route-to ($corbina_loc $corbina_loc_gw) from $internal_net
to <corbina>

Здесь мы вверху задаём все настройки, а в качестве адреса шлюза туннеля используем параметр, который потом подменим.

Далее идёт 2 правила NAT для локальных и нелокальных ресурсов. Потом идёт правило быстрого пропускания связи с самим роутером. Ну а затем по правилу маршрутизации для каждого из правил NAT соответственно. Рекомендую сохранять именно такой порядок правил: для NAT самое общее правило идёт последним, а для pass in самое общее правило идёт первым.

Теперь нужно создать файл pf.conf.c на основе origin.pf.conf.c. Для этого воспользуемся awk, который способен легко подменять переменные в файле. Вот скрипт переключения на чисто Корбиновские ресурсы cat /bin/switch_c:

gateip=`ifconfig tun0|grep tun0: -A 1|tail -n 1|cut -f 4 -d ' '`
echo "Using $gateip as VPN server"
awk -v var=$gateip '{ gsub(/Corbina_gateway/,var,$0); print }' /etc/origin.pf.conf.c>/etc/pf.conf.c
echo "New configuration file for pf prepared (pf.conf.c)"
echo "pfctl -f /etc/pf.conf.c"
pfctl -f /etc/pf.conf.c

По строчкам:

1) Парсим как и раньше шлюз туннеля (см. выше если нужны подробные объяснения)

2) Выводим его для порядку

3) Заменяем в /etc/origin.pf.conf.c слово Corbina_gateway на значение, хранящееся в $gateip и выводим всё в файл /etc/pf.conf.c

4) Выводим радострное сообщение об этом.

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

6) Загружаем новые правила pf, которые появились после выполнения строчки 3.

Вне зависимости от того каким способом вы сделали настройку переключаться можно так: если инет от Корбины не работает по какой-либо причине, то запускаем switch_2. Снова хотим пользоваться Корбиной - запускаем switch_c. При переподключении возможно рвутся все текущие соединения выше нашего роутера. Так что надо переподключить аську, dc++ и всё остальное (это в случае если переключаться между двумя работающими каналами). При желании можно сделать web интерфейс и запускать скрипты через локальный сайт.

Мы уже можем использовать траффик двух провайдеров переключаясь между ними. Но идеально было бы купить 2 разных тарифных плана(анлим и с платным траффиком), а потом всё требующее скорости (http) пускать через одно соединение, а всё жирное, но не срочное, (peer-to-peer) пускать через второе. Это будет называться policy based routing и мы его настроим в следующем пункте.

Настройка policy based routing (понтово схитрим)

Сейчас мы напишем конфигурацию, в которой будут одновременно использоваться каналы обоих провайдеров. При этом пусть Корбина будет с анлимом, а второй провайдер будет без ограничения скорости. Тогда http мы запустим через второго провайдера, а всё остальное через Корбину. В результате http будет быстрым, а скачка будет по прежнему бесплатной.

Вот файл настроек origin.pf.conf:

corbina_tun = "tun0"
corbina_loc = "xl0"
proc = "fxp0"
internal = "vr0"
corbina_tun_gw = "Corbina_gateway"
corbina_loc_gw = "10.83.0.17"
proc_gw = "217.117.116.129"
internal_net = "vr0/29"

table <corbina> persist file "/etc/additional.nets"
# Local resource
nat on $corbina_loc from $internal_net to <corbina> -> ($corbina_loc)
# General rules
nat on $corbina_tun from $internal_net to any port != 80 -> ($corbina_tun)
nat on $proc from $internal_net to any port = 80 -> ($proc)
# Routing override
pass in quick on $internal from $internal_net to $internal
pass in on $internal route-to ($proc $proc_gw) proto { tcp udp } from $internal_net to any port 80
pass in on $internal route-to ($corbina_tun $corbina_tun_gw) proto { tcp udp } from $internal_net to any
port != 80
pass in on $internal route-to ($corbina_tun $corbina_tun_gw) proto icmp from $internal_net to any
pass in on $internal route-to ($corbina_loc $corbina_loc_gw) from $internal_net to <corbina>

 

Здесь из нового разбиение по протоколам: tcp и udp могут иметь порты, а icmp не может.

Чтобы получить работающие правила нужно подсунуть в них адрес шлюза туннеля как и раньше. Вот скрипт включения switch_normal cat /bin/switch_normal:

gateip=`ifconfig tun0|grep tun0: -A 1|tail -n 1|cut -f 4 -d ' '`
echo "Using $gateip as Corbina VPN server"
awk -v var=$gateip '{ gsub(/Corbina_gateway/,var,$0); print }' /etc/origin.pf.conf>/etc/pf.conf
echo "New configuration file for pf prepared (pf.conf)"
echo "pfctl -f /etc/pf.conf"
pfctl -f /etc/pf.conf

Всё аналогично тому, что мы рассмотрели чуть выше.

Проверял я, что всё работает именно как задумано тем, что зашёл на сайт, показывающий IP того, кто туда зашёл (наберите в гугле What is my IP). Я увидел IP второго провайдера (так как это http). А для проверки корбины я сделал tracert ya.ru под виндой. Она покажет все промежуточные скачки пинга от вас до ya.ru. Полезно сделать такое же для внутреннего ресурса tracert homenet.corbina.net, так как там у нас другие правила маршрутизации.

Помимо распределения по портам можно слить мощность каналов вместе, а именно каждое следующее соединение запускать в чередующийся канал. Об этом написано в мануалу к pf, а я этого не делал.

 

Copyleft

Запуниди Сергей, 2007

Изменено пользователем =Zap=

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас