>ну так -- поехало или не очень с новыми конфигами
>Ннеа.
>подготовка отключить от будующего шлюза локалку
>и выключить совсем firewall
........
>
Сделано.
>во первых
>установить adsl подключение (подразумевается xsdl мопед в режиме бриджа)
>решение ставим pppoeconf и настраиваем подключение -- не забываем указать clamp-mms (на
>всякий пожарный -- отключить всегда успеем)
Сделано.
>проверяем подключение
>pon dsl-provider
>смотрим какие ip адреса получили -- и прописались-ли ns сервера в resolv.conf
>
>ping'уем куда-нибудь -- и т/д и т/п
>
С землей никаких проблем. Все отлично.
>номер два
>прописываем статический маршрут на VPN сервер провайдера
>ip route add 80.81.208.6 dev ppp0 metric 1
>подобным образом прописываем маршруты до ns серверов
Здесь не понял. Прописывать до ns также через землю?
>[оверквотинг удален]
>
>далее pon [имя нашего файлика aka провайдера aka как не назовите --
>только в печку не кладите] (лирика и (c) Народная Мудрось)
>итак
>смотрим tail -f /var/log/syslog как проходит соеденение
>если нормально -- хмм, (что странно если с первого раза заведётся --
>шутю)
>проверяем какие ip, SAT пров нам выдал ну и как минимум пингуем
>шлюз по умолчанию -- на данный момент им должен являтся шлюз
>провайдера SAT
Так. Опции отлажены и проверены несколькими одминами. К опциям и файлу соединений никаких претензий.
>
>проверяем что у нас тут
>#cat /proc/sys/net/ipv4/conf/all/rp_filter
>должно быть 0
>ну и ставим 1
>echo 1 >>/proc/sys/net/ipv4/conf/all/rp_filter
>(незабываем заодно пописать всё это /etc/sysctl.conf "net.ipv4.conf.all.rp_filter = 1")
>
Вот тут не понял. Мне сказали, что наоборот - надо вырубить фильтр этот нафиг, поскольку он (тут я могу врать) не дает получать ответ с другого интерфейса, чем тот, с которого послан запрос. А мне именно это и надо - запрос УХОДИТ по земле, а ПРИХОДИТ через спутник.
Просьба тут прояснить. Вкл или выкл эту штуку.
>тут начинается самое весёлое
>szap -c /etc/channels.conf -x
>dvb-net -a dvb0_0 -p [PID провайдера]
>проверяем ip link -- должен быть виден интерфейс dvb0_0
>добавляем адрес ей
>ip addr add 192.168.0.1/24 dev dvb0_0
>
>вешаем tcpdump на dvb0_0
>#tcpdump -e -n -i dvb0_0 ip
дамп нихрена не кажет. Вобще. ЧТо пингую чонить, что не пингую - тишина.
>и наблюдаем попутно делаем запрос на www ресурс -- смотрим что-куда --
>
>и весь внимания (пока) о вознихших проблемах
>
Описываю ситуэйшн. Сначала упала винда. Сразу. Напрочь. Как тока достал DVB карту оно отказалось грузицо ВАБЩЕ. Ни в каком режиме. Правда в Event Tracker перед выключением для снятия карты написал "Windows MUST DIE! Debian Linux FOREVER!"
Может оно обиделось? Ну да это лирика.
После многочисленных и продолжительных танцев (как видите на улице 3:18 ночи, а я еще ни в одном глазу - танцую с четками по причине отсутствия бубна вокруг сервака) удалось добиться следующего:
1. Земля подключается без проблем. Все шлюзы прописываются, все работает
2. После подключения спутника и некоторой правки руками (ума не приложу, откуда берутся лишние маршруты после поднятия соединения ВПН) получаем такой роутинг:
192.168.1.1 0.0.0.0 255.255.255.255 dvb0_0
217.9.147.12 0.0.0.0 255.255.255.255 ppp0 (собссно это АДСЛ)
80.81.208.6 0.0.0.0 255.255.255.255 ppp0 (прописан руками маршрут по земле до ВПН)
10.0.0.0 0.0.0.0 255.255.255.0 eth0 (собссно локалка)
0.0.0.0 0.0.0.0 0.0.0.0 ppp1 (собссно интерфейс ВПНа)
Казалось бы, все шоколадно? Ан ХЕРВАМ_НА_БЛЮДЦЕ! (извиняюсь, но я сижу за этим уже 9 часов)
вот что в сислоге:
Oct 24 03:08:39 localhost pptp[6485]: anon log[pptp_read_some:pptp_ctrl.c:543]: read returned zero, peer has closed
Oct 24 03:08:39 localhost pptp[6485]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state)
Oct 24 03:08:39 localhost pppd[6479]: Exit.
Oct 24 03:08:56 localhost pppd[6514]: pppd 2.4.4 started by root, uid 0
Oct 24 03:08:56 localhost pptp[6515]: anon log[main:pptp.c:267]: The synchronous pptp option is NOT activated
Oct 24 03:08:56 localhost pppd[6514]: using channel 20
Oct 24 03:08:56 localhost pppd[6514]: Using interface ppp1
Oct 24 03:08:56 localhost pppd[6514]: Connect: ppp1 <--> /dev/pts/3
Oct 24 03:08:56 localhost pptp[6520]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Oct 24 03:08:56 localhost pptp[6520]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply
Oct 24 03:08:56 localhost pptp[6520]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.
Oct 24 03:08:57 localhost pppd[6514]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x63e66771> <pcomp> <accomp>]
Oct 24 03:08:57 localhost pptp[6520]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Oct 24 03:08:57 localhost pptp[6520]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.
Oct 24 03:08:57 localhost pptp[6520]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 12416).
Oct 24 03:08:57 localhost pppd[6514]: rcvd [LCP ConfReq id=0x1 <mru 1490> <asyncmap 0x0> <auth chap MS-v2> <magic 0xd8545a5> <pcomp> <accomp>]
Oct 24 03:08:57 localhost pppd[6514]: sent [LCP ConfAck id=0x1 <mru 1490> <asyncmap 0x0> <auth chap MS-v2> <magic 0xd8545a5> <pcomp> <accomp>]
Oct 24 03:08:57 localhost pppd[6514]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x63e66771> <pcomp> <accomp>]
Oct 24 03:08:57 localhost pppd[6514]: sent [LCP EchoReq id=0x0 magic=0x63e66771]
Oct 24 03:08:57 localhost pppd[6514]: rcvd [LCP EchoReq id=0x0 magic=0xd8545a5]
Oct 24 03:08:57 localhost pppd[6514]: sent [LCP EchoRep id=0x0 magic=0x63e66771]
Oct 24 03:08:57 localhost pppd[6514]: rcvd [CHAP Challenge id=0x11 <3fe520a6746f9c752d0c72d1c80193e5>, name = "pptpd"]
Oct 24 03:08:57 localhost pppd[6514]: sent [CHAP Response id=0x11 <2b94438bc34da2a827a439eae580fe14000000000000000046cc485d0b59e0541e35741e08bf9ffb6150a05ccfd9617a00>, name = "riackirov68"]
Oct 24 03:08:57 localhost pppd[6514]: rcvd [LCP EchoRep id=0x0 magic=0xd8545a5]
Oct 24 03:08:57 localhost pppd[6514]: rcvd [CHAP Success id=0x11 "S=9B736F2BBEBAB79287289D2A302CC0F103E93C41 M=Access granted"]
Oct 24 03:08:57 localhost pppd[6514]: CHAP authentication succeeded
Oct 24 03:08:57 localhost pppd[6514]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
Oct 24 03:08:57 localhost pppd[6514]: rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 80.81.208.6>]
Oct 24 03:08:57 localhost pppd[6514]: sent [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 80.81.208.6>]
Oct 24 03:08:57 localhost pppd[6514]: rcvd [IPCP ConfNak id=0x1 <addr 80.81.215.200>]
Oct 24 03:08:57 localhost pppd[6514]: sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 80.81.215.200>]
Oct 24 03:08:57 localhost pppd[6514]: rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 80.81.215.200>]
Oct 24 03:08:57 localhost pppd[6514]: Cannot determine ethernet address for proxy ARP
Oct 24 03:08:57 localhost pppd[6514]: local IP address 80.81.215.200
Oct 24 03:08:57 localhost pppd[6514]: remote IP address 80.81.208.6
Oct 24 03:08:57 localhost pppd[6514]: Script /etc/ppp/ip-up started (pid 6521)
Oct 24 03:08:57 localhost pppd[6514]: Script /etc/ppp/ip-up finished (pid 6521), status = 0x0
Oct 24 03:09:57 localhost pptp[6520]: anon log[logecho:pptp_ctrl.c:676]: Echo Reply received.
Oct 24 03:10:42 localhost pptp[6515]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 38 (expecting 37, lost or reordered)
Oct 24 03:10:42 localhost pptp[6515]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 39 (expecting 37, lost or reordered)
Oct 24 03:10:57 localhost pptp[6520]: anon log[logecho:pptp_ctrl.c:676]: Echo Reply received.
Oct 24 03:11:42 localhost kernel: device dvb0_0 left promiscuous mode
Oct 24 03:11:42 localhost kernel: audit(1193181102.683:3): dev=dvb0_0 prom=0 old_prom=256 auid=4294967295
Oct 24 03:11:44 localhost kernel: device dvb0_0 entered promiscuous mode
Oct 24 03:11:44 localhost kernel: audit(1193181104.696:4): dev=dvb0_0 prom=256 old_prom=0 auid=4294967295
Oct 24 03:11:57 localhost pptp[6520]: anon log[logecho:pptp_ctrl.c:676]: Echo Reply received.
Oct 24 03:12:57 localhost pptp[6520]: anon log[logecho:pptp_ctrl.c:676]: Echo Reply received.
------
Тут насколько я понимаю он периодически шлет LCP запросы (или как там это называется) и получает ответы. Типа все ништяк. Соединение не падает, все вродебы хорошо.
Вот таблица роутинга на этот момент:
darklion@debian:~$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 dvb0_0
217.9.147.12 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
80.81.208.6 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp1
----------
ВНИМАНИЕ! tcpdump молчит как партизан, пинга вовне нет. ВСЁ! Приехали! Пингуются только адреса ВПНсервера, выданный провом внешний айпи, выданный провом АДСЛ внешний айпи ну и локальные. НИЧЕГО извне. Внимание вопрос - какого...[censored]?
Вот что выдает szap (кстати как его научить выводить уровень сигнала в процентах?):
darklion@debian:~$ sudo szap -c /etc/channels.conf -n 1 -x Password:
reading channels from file '/etc/channels.conf'
zapping to 1 'SpaceGate':
sat 0, frequency = 11595 MHz V, symbolrate 29270000, vpid = 0x0000, apid = 0x0000
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
status 00 | signal be5d | snr 708f | ber 00007a9e | unc 00000000 |
status 1f | signal b673 | snr ce76 | ber 000002e0 | unc 00000000 | FE_HAS_LOCK
Вроде бы сигнал есть... какого рожна надо то еще?