[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sudo ws root



Покотиленко Костик -> debian-russian@lists.debian.org  @ Fri, 12 Dec 2008 13:46:22 +0200:

 >>  >> > > VPN это отдельная печальная история и может создать намного больше
 >>  >> > > проблем, чем вариант с ssh.
 >>  >> >
 >>  >> > Например?
 >>  >> 
 >>  >> Начиная от проблем с безопасностью
 >> 
 >>  ПК> Помню только одну проблему с безопасностью, которая и ssh касалась,
 >>  ПК> т.к.  ода используют openssl.
 >> 
 >> У openvpn проблема с безопасностью врожденная.  Заключается она в том,
 >> что аутентификацию он умеет, а авторизацию - нет.  Ну, почти.
 >> 
 >>  >>  и заканчивая настройкой с учетом параметров маршрутизаторов на пути
 >>  >> траффика - приходится эмпирически параметры подбирать, как уж там,
 >>  >> mtu вроде и проч.
 >> 
 >>  ПК> Вы про что? Не слышал такого.
 >> 
 >> Про устройство IP в курсе?  Словосочетание "фрагментирование пакетов"
 >> слышал?  Что будет, если попытаться затуннелировать пакет максимального
 >> для данной физической сети размера, представляешь?

 ПК> Если попытаться затоннелировать пакет максимального для данной
 ПК> физической сети размера, он пройдёт, а если размер пакета IP
 ПК> превысит MTU - ICMP[Fragmentation needed] вернётся. Или, в случае с
 ПК> VPN не так? Я с этим не сталкивался, поэтому если тут есть грабли -
 ПК> выкладывайте.

Тут есть три варианта:

1) PMTU discovery сработает.  Все бы ничего, но делать его придется для
каждой сессии.

2) Пакет таки порежут (если в случае TCP у пакета туннеля не стоит флаг
DF или он вообще не TCP).  Поедет два пакета.  Второй будет состоять из
заголовков по крайней мере наполовину

3) "Продвинутые" сисадмины по дороге не слышали про PMTU, и вместо
возвращения Fragmentation needed пакет просто пропадет.

Разумная альтернатива - ограничить MTU на входе туннеля.  Вручную, в
конфиге.  О чем тебе и сказали.

-- 
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru

When C++ is your hammer, everything looks like a thumb
 -- Latest seen from Steven M. Haflich, in c.l.l


Reply to: