LINUX.ORG.RU
Форум — Admin  

Hostapd раздача pptp на archlinux

 , ,


1

1

Всем привет. Юзаю archlinux и сегодня столкнулся с такой проблемой: нужно раздать интернет с PPTP(ppp0) по WiFi(wlp8s0). Перечитал много инфы, однако ничего не вышло. Сначала пытался поднять мост, однако, brctl отказывается поднимать мост с VPN подключением. В итоге, остановился на NAT. Tracert выдает невнятную информацию: такое ощущение что половина пакетов просто теряются + не приходит ответ от сервера. Не буду говорить о своей криворукости в отношении iptables - это и так понятно. Уважаемые форумчане, надеюсь на вашу помощь. Дайте хотя бы наводку, в какую сторону копать.

Подключение к pptp (запостил, ибо там юзается route): 

pptpsetup --create NIKS --server vpn.niks.by --username USER --password PASS --start
ip route add default dev ppp0

Запуск точки доступа: 

#!/bin/bash
iptables -F
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
ifconfig wlp8s0 192.168.150.1
dnsmasq
sysctl net.ipv4.ip_forward=1
hostapd /etc/hostapd/hostapd.conf
killall dnsmasq

P.S. dnsmasq сконфигурен нормально

← HP Probook + OpenSUSE 13.1 wifi + bluetooth не работают
Софтварный рейд и использование памяти →

Tracert выдает невнятную информацию: такое ощущение что половина пакетов просто теряются + не приходит ответ от сервера.

А ping то работает? И вобще, запускатей tcpdump и смотрите, какие пакеты приходят и уходят.

Ну, можете показать ″iptables-save″ и ″ip route″, может кто что и заметит.

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

Ping работает. Еще до этого юзал sniffit. Итог - снова невнятный. Для некоторых серверов приходят ответы, для некоторых - нет. В iptables-save смысла нету. При запуске юзается iptables -F.

ip route: 

[biohazard@AndrewComp ~]$ ip route
default via 172.23.140.0 dev ppp0 
default dev ppp0  scope link 
172.16.0.0/12 via 172.31.0.1 dev enp2s0  metric 202 
172.23.140.0 dev ppp0  proto kernel  scope link  src 172.24.24.229 
172.31.0.0/16 dev enp2s0  proto kernel  scope link  src 172.31.21.36  metric 202 
172.31.21.36 via 127.0.0.1 dev lo  metric 202 
192.168.0.0/16 via 172.31.0.1 dev enp2s0  metric 202 
192.168.150.0/24 dev wlp8s0  proto kernel  scope link  src 192.168.150.1 
217.21.42.0/27 via 172.31.0.1 dev enp2s0  metric 202 
217.21.42.192/27 via 172.31.0.1 dev enp2s0  metric 202 
217.21.42.222 via 172.31.0.1 dev enp2s0  src 172.31.21.36

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

Ах да, чуть не забыл

enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.31.21.36  netmask 255.255.0.0  broadcast 172.31.255.255
        inet6 fe80::8aae:1dff:fe7f:30f5  prefixlen 64  scopeid 0x20<link>
        ether 88:ae:1d:7f:30:f5  txqueuelen 1000  (Ethernet)
        RX packets 533843  bytes 142724448 (136.1 MiB)
        RX errors 0  dropped 78  overruns 0  frame 0
        TX packets 81733  bytes 14802993 (14.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 171522  bytes 12502878 (11.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 171522  bytes 12502878 (11.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1400
        inet 172.24.24.229  netmask 255.255.255.255  destination 172.23.140.0
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 93023  bytes 84497322 (80.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 63381  bytes 10236743 (9.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp8s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.150.1  netmask 255.255.255.0  broadcast 192.168.150.255
        inet6 fe80::5eac:4cff:fe70:e7d  prefixlen 64  scopeid 0x20<link>
        ether 5c:ac:4c:70:0e:7d  txqueuelen 1000  (Ethernet)
        RX packets 310  bytes 176319 (172.1 KiB)
        RX errors 0  dropped 2  overruns 0  frame 0
        TX packets 231  bytes 28882 (28.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
BioHazarD
() автор топика
Ответ на: комментарий от post-factum

Все равно пакеты не приходят назад на девайсы. Пингуется лучше - даже доходит до гугла. Но 80 все равно не грузит. Timeout на девайсах, подключенных через меня

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

Попробуй-ка ещё на выходе своего ppp зафиксировать ttl всех пакетов с помощью iptables. Рецепт нагугли сам, а то мне с мобилки влом.

Были случаи особо странных провайдеров ограничивать так раздатчиков интернетов.

post-factum ★★★★★
()
Ответ на: комментарий от BioHazarD

Ещё меня это смущает:

192.168.0.0/16 via 172.31.0.1 dev enp2s0 metric 202
192.168.150.0/24 dev wlp8s0 proto kernel scope link src 192.168.150.1

Маршруты перекрываются.

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

Не помогло 

[biohazard@AndrewComp ~]$ ip route
default dev ppp0  scope link 
172.16.0.0/12 via 172.31.0.1 dev enp2s0  metric 202 
172.23.140.0 dev ppp0  proto kernel  scope link  src 172.24.24.229 
172.31.0.0/16 dev enp2s0  proto kernel  scope link  src 172.31.21.36  metric 202 
172.31.21.36 via 127.0.0.1 dev lo  metric 202 
192.168.0.0/16 via 172.31.0.1 dev enp2s0  metric 202 
192.168.247.104 via 127.0.0.1 dev lo  metric 303 
193.168.150.0/24 dev wlp8s0  proto kernel  scope link  src 193.168.150.1 
217.21.42.0/27 via 172.31.0.1 dev enp2s0  metric 202 
217.21.42.192/27 via 172.31.0.1 dev enp2s0  metric 202 
217.21.42.222 via 172.31.0.1 dev enp2s0  src 172.31.21.36

BioHazarD
() автор топика
Ответ на: комментарий от post-factum

Маршруты всегда перекрываются, так как default перекрывает всех.

Другое дело, что это какая то ерунда понаписана в таблице, скрипт что-ли какой поработал?
В чём вот смысл маршрута: 

172.31.21.36 via 127.0.0.1 dev lo  metric 202

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

Пингуется лучше - даже доходит до гугла.

Эти рецепты никак не должны были отразиться на ICMP-пакетах (пингах). Обычный ping-пакет короткий, на него MTU не подействует, а MSS и TCP timestamps вобще только к tcp имеют отношение. Так что, если у вас внезапно меняется качество ping'а, возможно, что у вас просто с радиосигналом проблемы и огромные потери пакетов.

mky ★★★★★
()
Ответ на: комментарий от post-factum

Сейчас попробую. Отпишусь о результатах

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

Это дефолтный роут, который создает wicd при создании enp2s0 

[root@AndrewComp biohazard]# ip route
172.16.0.0/12 via 172.31.0.1 dev enp2s0  metric 202 
172.31.0.0/16 dev enp2s0  proto kernel  scope link  src 172.31.21.36  metric 202 
172.31.21.36 via 127.0.0.1 dev lo  metric 202 
192.168.0.0/16 via 172.31.0.1 dev enp2s0  metric 202 
217.21.42.0/27 via 172.31.0.1 dev enp2s0  metric 202 
217.21.42.192/27 via 172.31.0.1 dev enp2s0  metric 202

Это я прописываю для работоспособности интернета после поднятия ppp0 

ip route add default dev ppp0

Итого: 

[biohazard@AndrewComp ~]$ ip route
default dev ppp0  scope link 
172.16.0.0/12 via 172.31.0.1 dev enp2s0  metric 202 
172.23.140.0 dev ppp0  proto kernel  scope link  src 172.24.24.229 
172.31.0.0/16 dev enp2s0  proto kernel  scope link  src 172.31.21.36  metric 202 
172.31.21.36 via 127.0.0.1 dev lo  metric 202 
192.168.0.0/16 via 172.31.0.1 dev enp2s0  metric 202 
217.21.42.0/27 via 172.31.0.1 dev enp2s0  metric 202 
217.21.42.192/27 via 172.31.0.1 dev enp2s0  metric 202 
217.21.42.222 via 172.31.0.1 dev enp2s0  src 172.31.21.36

Где же абсурд? Неужели wicd?

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

Абсурд в маршруте: 

172.31.21.36 via 127.0.0.1 dev lo  metric 202
хотя он не должен ни на что влиять. Нагуглил, что в последней версии dhcpd эту ошибку уже исправили и больше он не создаёт подобную бессмыслицу.

А вы пробовали пинговать по wifi ближайшие хосты большими (а не дефолтными) пакетами? Чтобы как-то подтвердить, что со связью всё надёжно.

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

Я пробовал юзать внешний интерфейс, а девайсы находятся в пределах одной небольшой комнаты. Ошибка не разрешилась.

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

Я пробовал юзать внешний интерфейс

Что это значит? ″ping 172.31.21.36″ не работает?

а девайсы находятся в пределах одной небольшой комнаты

Если какая-то ошибка в драйвере, то может быть выставлен низкий уровень сигнала или выбран зашумлённый канала или ещё что. У вас должны быть чёткие пинги на 192.168.150.1, на 172.31.21.36 и на 172.31.0.1 (если в POSTROUTING добавить NAT для enp2s0 интерфейса). Причём ping должен ходить как обычный, так и большими пакетами (1000, 2000 байт), в винде это ″ping -l 1000″, в Линуксе ″ping -s 1000″. И пока не будет устойчивого пинга на 172.31.21.36 рассуждать о правилах iptables, маршрутах, настройках DNS и опциях tcp преждевременно.

mky ★★★★★
()

Установит правильные mtu, сделать на сервере iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Если не помогло, сделать на клиенте mtu=576. Проверить DNS и работу с самого сервера.

ktulhu666 ☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← HP Probook + OpenSUSE 13.1 wifi + bluetooth не работают
Admin
Софтварный рейд и использование памяти →