Избитая тема про VPN, но...

[hamm]

Стандартно - Гугл, поиск по форуму только потом тема на форуме. Предыдущий поиск ожидаемых результатов не дал. Самое интерестное, что когда то утанавливал vpn под фряхой, и помню был какой то подвох с маршрутами, но уже забыл как решил. Теперь к делу. OC FreeBSD 6.1. pptpclient и libgnugetopt устанавливал из портов.
/etc/ppp/ppp.conf

vpn:
set authname 111
set authkey 111
set timeout 0
set ifaddr 0 0
disable IPV6CP
add default HISADDR
alias enable yes

Соединение устанавливаю pptp 192.168.10.100 vpn &. Вывод ifconfog

vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::215:f2ff:fe98:8bfc%vr0 prefixlen 64 scopeid 0x1
inet 192.168.10.199 netmask 0xffff0000 broadcast 192.168.255.255
ether 00:15:f2:98:8b:fc
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST,NEEDSGIANT> mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff000000
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.7 --> 10.0.0.1 netmask 0xffffffff
Opened by PID 1672

Далее сразу смотрим netstat -rn

Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 10.0.0.1 UGS 0 42 tun0
10.0.0.1 10.0.0.7 UH 1 0 tun0
127.0.0.1 127.0.0.1 UH 0 13848 lo0
192.168.0/16 link#1 UC 0 0 vr0
192.168.1.40 00:0a:48:07:5f:b1 UHLW 1 44 vr0 1088
192.168.10.100 00:80:48:43:0a:03 UHLW 1 949 vr0 796
192.168.10.199 00:15:f2:98:8b:fc UHLW 1 2 lo0
192.168.10.200 00:17:9a:bc:a2:5c UHLW 1 2337 vr0 99

Продуем пинговать ипник выданный нам серваком по VPN

PING 10.0.0.7 (10.0.0.7): 56 data bytes
64 bytes from 10.0.0.7: icmp_seq=0 ttl=64 time=0.262 ms
64 bytes from 10.0.0.7: icmp_seq=1 ttl=64 time=0.076 ms
64 bytes from 10.0.0.7: icmp_seq=2 ttl=64 time=0.073 ms
64 bytes from 10.0.0.7: icmp_seq=3 ttl=64 time=0.074 ms
^C
--- 10.0.0.7 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.073/0.121/0.262/0.081 ms

Теперь ипник VPN сервера

PING 10.0.0.1 (10.0.0.1): 56 data bytes
^C
--- 10.0.0.1 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

Удаленного хоста в Инете

PING 212.3.133.6 (212.3.133.6): 56 data bytes
^C
--- 212.3.133.6 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

тогда делаем tcpdump -i tun0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
02:31:12.270917 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 0, length 64
02:31:12.802555 IP 10.0.0.7.50138 > 212.3.133.6.domain: 18042+ PTR? 6.133.3.212.in-addr.arpa. (42)
02:31:13.271781 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 1, length 64
02:31:14.272801 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 2, length 64
02:31:15.273815 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 3, length 64
02:31:16.274825 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 4, length 64
02:31:17.275842 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 5, length 64
02:31:17.802885 IP 10.0.0.7.51802 > 212.3.133.6.domain: 18042+ PTR? 6.133.3.212.in-addr.arpa. (42)
02:31:18.276857 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 6, length 64
02:31:19.277867 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 7, length 64
02:31:20.278885 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 8, length 64
02:31:21.279902 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 9, length 64
02:31:22.280911 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 10, length 64
02:31:23.281927 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 11, length 64
02:31:24.282946 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 12, length 64
02:31:25.283960 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 13, length 64
02:31:26.284971 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 14, length 64
02:31:27.285996 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 15, length 64
02:31:27.804163 IP 10.0.0.7.62166 > 212.3.133.6.domain: 18043+ PTR? 7.0.0.10.in-addr.arpa. (39)
02:31:28.287026 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 16, length 64
02:31:29.288014 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 17, length 64
02:31:30.289041 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 18, length 64
02:31:31.290048 IP 10.0.0.7 > 212.3.133.6: ICMP echo request, id 34567, seq 19, length 64

Т.е пакеты уходят, к тому же биллинг, эти пакеты обсчитывает как исходяций траф. (скажу сразу ядро не пересобиралось и ставилось по дефолту без поддержки ipfw, так что не в фаере дело)
Еще кой чего интерестного. Лезем на сам VPN сервак (Debian 3.1) и пингуем оттуда клиенский адресс

PING 10.0.0.7 (10.0.0.7) 56(84) bytes of data.

--- 10.0.0.7 ping statistics ---
22 packets transmitted, 0 received, 100% packet loss, time 21008ms

При этом на клиенской машине FreeBSD tcpdump показывает!

2:33:20.712362 IP 10.0.0.1 > 10.0.0.7: ICMP echo request, id 14412, seq 1, length 64
02:33:20.712377 IP 10.0.0.7 > 10.0.0.1: ICMP echo reply, id 14412, seq 1, length 64
02:33:20.807775 IP 10.0.0.7.54770 > 212.3.133.6.domain: 18044+ PTR? 1.0.0.10.in-addr.arpa. (39)
02:33:21.720322 IP 10.0.0.1 > 10.0.0.7: ICMP echo request, id 14412, seq 2, length 64
02:33:21.720334 IP 10.0.0.7 > 10.0.0.1: ICMP echo reply, id 14412, seq 2, length 64
02:33:22.720411 IP 10.0.0.1 > 10.0.0.7: ICMP echo request, id 14412, seq 3, length 64
02:33:22.720424 IP 10.0.0.7 > 10.0.0.1: ICMP echo reply, id 14412, seq 3, length 64
02:33:23.720637 IP 10.0.0.1 > 10.0.0.7: ICMP echo request, id 14412, seq 4, length 64
02:33:23.720649 IP 10.0.0.7 > 10.0.0.1: ICMP echo reply, id 14412, seq 4, length 64
02:33:24.720692 IP 10.0.0.1 > 10.0.0.7: ICMP echo request, id 14412, seq 5, length 64
02:33:24.720704 IP 10.0.0.7 > 10.0.0.1: ICMP echo reply, id 14412, seq 5, length 64
02:33:25.721128 IP 10.0.0.1 > 10.0.0.7: ICMP echo request, id 14412, seq 6, length 64
02:33:25.721143 IP 10.0.0.7 > 10.0.0.1: ICMP echo reply, id 14412, seq 6, length 64
02:33:25.808755 IP 10.0.0.7.60594 > 212.3.133.6.domain: 18044+ PTR? 1.0.0.10.in-addr.arpa. (39)
02:33:26.720909 IP 10.0.0.1 > 10.0.0.7: ICMP echo request, id 14412, seq 7, length 64
02:33:26.720921 IP 10.0.0.7 > 10.0.0.1: ICMP echo reply, id 14412, seq 7, length 64
02:33:27.720947 IP 10.0.0.1 > 10.0.0.7: ICMP echo request, id 14412, seq 8, length 64
02:33:27.720959 IP 10.0.0.7 > 10.0.0.1: ICMP echo reply, id 14412, seq 8, length 64
02:33:28.720998 IP 10.0.0.1 > 10.0.0.7: ICMP echo request, id 14412, seq 9, length 64
02:33:28.721010 IP 10.0.0.7 > 10.0.0.1: ICMP echo reply, id 14412, seq 9, length 64
02:33:29.721100 IP 10.0.0.1 > 10.0.0.7: ICMP echo request, id 14412, seq 10, length 64

Вот 4 часа голову ломаю... может просто устал. Помогите плз. я невижу причины, кроме как где то в маршрутах на фряже намудрил (може маски подсети где несходятся??? незнаю что и думать...)

[Jay]

С момента установки VPN, весь траффик уходит на default gateway (10.0.0.1), потому что других маршрутов нет.
Вы определитесь, что вам надо слать в туннель, а что напрямую и просто статиком пропишите в rc.conf. Ну и "add default HISADDR" тогда уберите из ppp.conf.

С пингованием VPN-сервера... а показали бы вы еще вывод tcpdump во время PING 10.0.0.1 с фрюхи и с Debian. Ну и tcpdump во время PING 10.0.0.7, но с Debian. Тогда будет видно, где пакеты режутся.. Вполне возможно, что у вас на Debian'е icmp файрволлом убиты.

[hamm]

Соазу могу сказать. VPN сервак на дебиане во внутренней сети работает уже почти пол-года и остальных пару десятков человек проблемм VPN небыло (в т.ч. и у меня на данный момент сижу через него с под OpenSUSE 10.2). На попытку пинга 10.0.0.1 (т.е. VPN сервера) со стороны FreeBSD tcpdump на дэбе ничего не словил. СО стороны Дебиана ping до 10.0.0.1

PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.204 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.166 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.163 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.188 ms

--- 10.0.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 0.163/0.180/0.204/0.019 ms

право тут не надо быть экстрасенсом чтобы понять что проблемма где то в маршрутах на фряхе как я ранее и говарил. Но я там уже запутался в 2 маршрутах. Право, лучше разобраться с более сложной системой маршрутизации, чем с простой, но в которой ничего не работает! А задача проста - завернуть весь траф на этот Ифейс tun0 чтобы Инет на фряже появился) Вроде уже много людей vpn на фряхе поднимали и работают может сейчас - ну тов. помогить скажите что нетак. я что то упускаю...

[hamm]

netsta -rn с Фряхи.

Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 10.0.0.1 UGS 0 6 tun0
10.0.0.1 10.0.0.7 UH 1 158 tun0
127.0.0.1 127.0.0.1 UH 0 75583 lo0
192.168.0/16 link#1 UC 0 0 vr0
192.168.1.40 00:0a:48:07:5f:b1 UHLW 1 252 vr0 450
192.168.10.100 00:80:48:43:0a:03 UHLW 1 374 vr0 461
192.168.10.199 00:15:f2:98:8b:fc UHLW 1 2 lo0
192.168.10.200 00:17:9a:bc:a2:5c UHLW 1 12023 vr0 455

Internet6:
Destination Gateway Flags Netif Expire
::1 ::1 UH lo0
fe80::%vr0/64 link#1 UC vr0
fe80::215:f2ff:fe98:8bfc%vr0 00:15:f2:98:8b:fc UHL lo0
fe80::%lo0/64 fe80::1%lo0 U lo0
fe80::1%lo0 link#3 UHL lo0
ff01:1::/32 link#1 UC vr0
ff01:3::/32 ::1 UC lo0
ff01:4::/32 link#4 UC tun0
ff02::%vr0/32 link#1 UC vr0
ff02::%lo0/32 ::1 UC lo0
ff02::%tun0/32 link#4 UC tun0

[hamm]

UP

[gcc]

если сервер стоит в другой подсети, тогда добавить вот это !bg /sbin/route add HISADDR ip_маршрутизатора в /etc/ppp/ppp.linkup




решил сделать тунель, первый раз
vpn сервер 1.1.1.1, установил pptpclient
(по сканировал nmap'ом, типо порт pptp там открыт)

ядро

options IPFIREWALL
options IPFIREWALL_FORWARD

сделал конфиги

/etc/ppp/ppp.linkdown

vpn:
!bg /sbin/route delete HISADDR
!bg /sbin/route change default ip_маршрутизатора

/etc/ppp/ppp.linkup

vpn:
!bg /sbin/route delete HISADDR
!bg /sbin/route add HISADDR ip_маршрутизатора
!bg /sbin/route change default HISADDR

/etc/ppp/ppp.conf

default:
set log phase chat lcp ipcp ccp tun command
vpn:
set log Phase Warning Alert Error command
#set log Phase lcp ipcp ccp tun command
set device "!pptp ВПН_СЕРВЕР --nolaunchpppd"
set mtu max 1500
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj
#enable dns
set timeout 0
set openmode passive
delete ALL
add default HISADDR
set timeout 0
alias enable yes
set authname d
set authkey ***

появился tun0

ppp -ddial vpn

работает

[hamm]

Нет сервер и клиент в одной сети 192.168.10.199/16 и 192.168.10.100/16. Щас попробую сделать как написано.

[hamm]

Ради интереса пересобрал ядро следуя документации и потратил на это 1.5 часа. помимо указанных опций фаера дописал ещё опцию IPFIREWALL_DEFAULT_TO_ACCEPT, чтобы уже никаких вопросов не возникало, даже сделал излишек, прописал в rc.conf помимо firewall_enable=YES ещё и firewall_type="open". Ну это чтобы совсем исключить фаер. Посмотрел и 65535 правило allow ip fom any to any было и oт rc.confа 65500 allow ip from any to any. ВСЕ более таблица пуста. Твой скрипт юзал дял поднятия VPN - ну картина не меняется. Ну ТОВ. знатоки FreeBSD скажите в ЧЕМ ПРОБЛЕММА! кто нибудь знает?????? Есть тут люди которые действительно секут в этом?!

Кстати после отключения поддержки IPv6 в ведре... netstat -rn - но это дела не меняет...

Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 10.0.0.1 UGS 0 0 tun0
10.0.0.1 10.0.0.7 UH 1 0 tun0
127.0.0.1 127.0.0.1 UH 0 4792 lo0
192.168.0/16 link#1 UC 0 0 vr0
192.168.1.40 00:0a:48:07:5f:b1 UHLW 1 66 vr0 1161
192.168.1.241 00:0d:61:1f:e6:15 UHLW 1 22 vr0
192.168.3.13 00:11:2f:3d:29:d5 UHLW 1 19 vr0 1078
192.168.10.100 00:80:48:43:0a:03 UHLW 1 16 vr0 1194
192.168.10.200 00:17:9a:bc:a2:5c UHLW 1 538 vr0 1113

Скажите что надо выложить или какая ещё инфа надо чтобы разобраться помимо той кучи инфы что тут есть.

TEST_UTM5# wget ya.ru
--16:56:59-- http://ya.ru/
=> `index.html'
Resolving ya.ru... failed: hostname nor servname provided, or not known.

тоже инфа для размышления... что icmp непричем... enable DNS в скрипте включен.

[IPhoenixI]

Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 10.0.0.1 UGS 0 0 tun0
10.0.0.1 10.0.0.7 UH 1 0 tun0
127.0.0.1 127.0.0.1 UH 0 4792 lo0
192.168.0/16 link#1 UC 0 0 vr0
192.168.1.40 00:0a:48:07:5f:b1 UHLW 1 66 vr0 1161
192.168.1.241 00:0d:61:1f:e6:15 UHLW 1 22 vr0
192.168.3.13 00:11:2f:3d:29:d5 UHLW 1 19 vr0 1078
192.168.10.100 00:80:48:43:0a:03 UHLW 1 16 vr0 1194
192.168.10.200 00:17:9a:bc:a2:5c UHLW 1 538 vr0 1113

Минуточку 10.0.0.1 и 10.0.0.7, что здесь айпи сервера, что айпи выданый ВПН сервером?
Мой совет, убейте таблицу маршрутизации и создайте заново.
При соединении с ВПН сервером, если адрес 10.0.0.1 - это адрес сервера, а 10.0.0.7 ваш адрес то маршрут должен выглядеть так:
route -nq change default 10.0.0.7
тоесть дефолтный маршрут должен быть адрес вашего интерфейса.
В rc.local пропишите
route -nq add 192.168.10.100 192.168.10.199
дабы не потерять сервер при смене дефолтного маршрута.

[hamm]

Вот это ближе к теме. Да, насколько я начинаю вспоминать это ближе к правде. Но при попытке выполнить route -nq change default 10.0.0.7 фряха мне отвечает
route: writing to routing socket: Address already in use. Причем в разном синтаксисе команды по разному. Если я очищаю таблицу и пробую добавить его руками получаю add net default: gateway 10.0.0.7: Network is unreachable. Вот.

[hamm]

Товарищи. Скажите а кто нибуть создавал VPN из под FreeBSD 6.1 до Debian 3.1. Потому что наткнулся я на такой материал.... http://osdir.com/ml/security.firewalls.m0n...8/msg00336.html
Вобщем интересные дела получаются!