alexkuklin (
alexkuklin) wrote2007-10-17 12:18 pm
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
(no subject)
Вчера имел феерическое развлечение с подключением к Корбине.
Ситуация такова:
на сетевом интерфейсе клиент получает адрес из сетки 10.x.x.x
PPTP-сервер - vpn.corbina.ru, адрес 85.21.0.x
То, что большая часть роутеров не умеет прописывать static route на vpn сервер - это фигня. Мне не сложно его прописать.
Но вот то, что после установления pptp-cоединения на другой стороне ppp сервер выдает тот же ip, что и у PPTP-сервера, меня лично повергло в ступор.
Что требуется для того, чтобы отправить пакет во внешний мир через PPTP? Завернуть его в GRE-пакет и отправить на PPTP-сервер. Куда смотрит роутинг на IP этого сервера? Правильно, в ppp. И мы снова пытаемся завернуть пакет в GRE-обертку и снова засунуть в ppp. Исходящий трафик на PPP-интерфейсе растет лавинообразно, но в eth ничего не уходит. Ну и канал падает по timeout.
Я, конечно, вкрутил туда source-based routing и объяснил, что пакеты от 10.0.0.0/8 надо отправлять через eth.
Но степень ненатурализма инженеров Корбины меня поразила. Для прямого решения задачи было достаточно поставить любой серый адрес, совершенно не обязательно выделять публичный IP.
Ситуация такова:
на сетевом интерфейсе клиент получает адрес из сетки 10.x.x.x
PPTP-сервер - vpn.corbina.ru, адрес 85.21.0.x
То, что большая часть роутеров не умеет прописывать static route на vpn сервер - это фигня. Мне не сложно его прописать.
Но вот то, что после установления pptp-cоединения на другой стороне ppp сервер выдает тот же ip, что и у PPTP-сервера, меня лично повергло в ступор.
Что требуется для того, чтобы отправить пакет во внешний мир через PPTP? Завернуть его в GRE-пакет и отправить на PPTP-сервер. Куда смотрит роутинг на IP этого сервера? Правильно, в ppp. И мы снова пытаемся завернуть пакет в GRE-обертку и снова засунуть в ppp. Исходящий трафик на PPP-интерфейсе растет лавинообразно, но в eth ничего не уходит. Ну и канал падает по timeout.
Я, конечно, вкрутил туда source-based routing и объяснил, что пакеты от 10.0.0.0/8 надо отправлять через eth.
Но степень ненатурализма инженеров Корбины меня поразила. Для прямого решения задачи было достаточно поставить любой серый адрес, совершенно не обязательно выделять публичный IP.
no subject
Клиент должен иметь возможность просто прописать ip-адрес на интерфейсе и не ебать мозг.
no subject
давать прямой линк - правильнее, но и много дороже, т.к. требует полностью управляемой сети.
далеко не все сети такие.
no subject
no subject
no subject
И второму концу оного, таки да, назначен левый адрес.
no subject
Только это резко снижает экономическую осмысленность, особенно на старте.
no subject
У всех остальных свитчи с мозгами.
no subject
no subject
no subject
no subject
no subject
no subject
можно и через mangle вкрутить, но зачем?
no subject
ИМХО должно быть так:
1) постоянный маршрут до pptp-сервера
2) и дефолтный маршрут - через шлюз, выданный pptp-сервером.
no subject
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
85.21.0.51 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
10.163.96.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0.1
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
# ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:89.179.x.x P-t-P:85.21.0.51 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1372 Metric:1
pptp сервер имеет тот же адрес, что и обратная сторона ppp0 - 85.21.0.51
итого, чтобы отправить пакет, его надо завернуть в GRE и отправить на 85.21.0.51
ну а пакеты на 85.21.0.51 положено доставлять через ppp0 (cмотрим на первую сточку машрутов)
теперь понятно?
no subject
Вот же ненатуралы... На кой ещё и GRE прикрутили сюда, непонятно. Могли бы просто pptp ограничиться.
no subject
no subject
Я про то, что нафиг надо давать тот же адрес второму концу туннеля, что и у vpn-сервера...
no subject
no subject
no subject
no subject
no subject
no subject
no subject