https://www.opennet.ru/openforum/vsluhforumID6/16311.html Есть головная точка. В ней стоит контроллер домена на Windows 2003 R2 SP2.<br>Есть несколько филиалова - которые уже пару лет успешно авторизауются на контроллере. <br>Каналы организованны на обрудовании Cisco, путем создания IPSec тунелей.<br>Так вот, появилась одна точка до которой поднят тунель через Internet. И вот в этой ОДНОЙ точке не наследуются групповые политики. Убирал в политиках определиние медленных линий Slow Link. Не помогает. <br>Канал в принципе хороший, ширина порядка 512Кбит, отклик 30-40 ms.<br><br>Обшарил весь microsoft.com, но вот склоняюсь к тому, что дело в канале... что можно подкрутить ?<br><br>interface Tunnel1<br> description to_RPSB_Kozlova<br> ip address 192.168.40.12 255.255.255.252<br> ip mtu 1300<br> ip tcp adjust-mss 1259<br> keepalive 15 4<br> tunnel source xxxxxx<br> tunnel destination xxxxxx<br> crypto map CRYPTO1<br> https://www.opennet.ru/openforum/vsluhforumID6/16311.html#7 Tue, 22 Jul 2008 08:41:25 GMT &gt;[оверквотинг удален]<br>&gt;&gt;двух сторон, поставь с двух сторон на интерфейсах которые смотрят в <br>&gt;&gt;локалку ip tcp adj 1280 <br>&gt;&gt;и в реестре винды поставь MTU 1370 - всё прекрасно работает, древовидная <br>&gt;&gt;структура нашего холдинга по таким правилам работает, групповые политики отлично применяются. <br>&gt;&gt;Я долго рыл эту проблему, там решение или Керберос переводить в <br>&gt;&gt;режим TCP транзакций, либо врукопашную править MTU на зенетах АД. <br>&gt;<br>&gt;А можно по подробней откуда эти цифры? 1280, 1370 <br>&gt;И "и в реестре винды поставь MTU 1370" это ставить на всех <br>&gt;виндах которые лезут к контролеру через gre/ipsec тунель? <br><br>Вообще циска советует ставить при решениях GRE+IPSEC размер MTU 1400, если максимальный MTU на WAN интерфейсе 1500, иначе учитывать оверхед WAN интерфейса. Соответственно MSS ставить 1360.<br><br>Вот ссылочка:<br><br>http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml#sc5<br> https://www.opennet.ru/openforum/vsluhforumID6/16311.html#6 Tue, 22 Jul 2008 05:33:40 GMT &gt;[оверквотинг удален]<br>&gt;&gt;размер MTU равном того, чего вы подсчитали для своего GRE over <br>&gt;&gt;IPSec соединения. <br>&gt;<br>&gt;Убери все правила ip mtu/ ip tcp ... итд c tun0 с <br>&gt;двух сторон, поставь с двух сторон на интерфейсах которые смотрят в <br>&gt;локалку ip tcp adj 1280 <br>&gt;и в реестре винды поставь MTU 1370 - всё прекрасно работает, древовидная <br>&gt;структура нашего холдинга по таким правилам работает, групповые политики отлично применяются. <br>&gt;Я долго рыл эту проблему, там решение или Керберос переводить в <br>&gt;режим TCP транзакций, либо врукопашную править MTU на зенетах АД. <br><br>А можно по подробней откуда эти цифры? 1280, 1370 <br>И "и в реестре винды поставь MTU 1370" это ставить на всех виндах которые лезут к контролеру через gre/ipsec тунель?<br> https://www.opennet.ru/openforum/vsluhforumID6/16311.html#5 Wed, 04 Jun 2008 17:18:46 GMT &gt;[оверквотинг удален]<br>&gt;&gt;IPSEC добавляет overhead к пакету. <br>&gt;&gt;Всё должно работать и c IPSEC. <br>&gt;&gt;ESP (encryption and hash) Additional bytes - 56 <br>&gt;&gt;GRE Additional bytes - 24 <br>&gt;<br>&gt;Всё верно, но лучше проблему передачи больших керберосовских УДП пакетов не фрагментируя, <br>&gt;ибо АД этого не любят и работать групповая политика не будет <br>&gt;между доменами в GRe... Для этого ручками в реестре нужно указать <br>&gt;размер MTU равном того, чего вы подсчитали для своего GRE over <br>&gt;IPSec соединения. <br><br>Убери все правила ip mtu/ ip tcp ... итд c tun0 с двух сторон, поставь с двух сторон на интерфейсах которые смотрят в локалку ip tcp adj 1280<br>и в реестре винды поставь MTU 1370 - всё прекрасно работает, древовидная структура нашего холдинга по таким правилам работает, групповые политики отлично применяются. Я долго рыл эту проблему, там решение или Керберос переводить в режим TCP транзакций, либо врукопашную править MTU на зенетах АД.<br> https://www.opennet.ru/openforum/vsluhforumID6/16311.html#4 Wed, 04 Jun 2008 17:14:57 GMT &gt;[оверквотинг удален]<br>&gt;ip tcp adjust-mss 1260 <br>&gt;<br>&gt;Можно просто задать adjust-mss без mtu <br>&gt;и последовательно его уменьшать на 20 <br>&gt;до работоспособности. <br>&gt;<br>&gt;IPSEC добавляет overhead к пакету. <br>&gt;Всё должно работать и c IPSEC. <br>&gt;ESP (encryption and hash) Additional bytes - 56 <br>&gt;GRE Additional bytes - 24 <br><br>Всё верно, но лучше проблему передачи больших керберосовских УДП пакетов не фрагментируя, ибо АД этого не любят и работать групповая политика не будет между доменами в GRe... Для этого ручками в реестре нужно указать размер MTU равном того, чего вы подсчитали для своего GRE over IPSec соединения.<br> https://www.opennet.ru/openforum/vsluhforumID6/16311.html#3 Wed, 28 May 2008 12:46:57 GMT &gt; ip mtu 1300<br>&gt; ip tcp adjust-mss 1259 <br><br>Нужно:<br>(ip tcp adjust-mss) = (ip mtu) - 40<br><br>Пример:<br>ip mtu 1300<br>ip tcp adjust-mss 1260<br><br>Можно просто задать adjust-mss без mtu<br>и последовательно его уменьшать на 20<br>до работоспособности.<br><br>IPSEC добавляет overhead к пакету.<br>Всё должно работать и c IPSEC.<br>ESP (encryption and hash) Additional bytes - 56<br>GRE Additional bytes - 24<br><br> https://www.opennet.ru/openforum/vsluhforumID6/16311.html#2 Fri, 23 May 2008 12:07:37 GMT &gt;[оверквотинг удален]<br>&gt;<br>&gt;покрути МТУ, идей больше нет, а вообще это не канальная проблема - <br>&gt;если по тунелю radmin и RDP лазят без проблем то капай <br>&gt;маздай. А вообще в подобных ситуациях М$ не гарантирует работоспособность (насколько <br>&gt;они вообще что то могут гарантировать), для таких случаев у них <br>&gt;созданы решения: Лес контролеров, доверительнве отношения, репликация, ДФС - читайте изучайте <br>&gt;- может будет меньше проблем :). М$ очень не любит работать <br>&gt;по тунелям которые не они сами создают (объяснение тех подержки - <br>&gt;у них есть свои "гарантированные" решения типа ISA и так тадалее <br>&gt;:)) <br><br>решил проблему - если так можно сказать. Отключил IPSec шифрование и групповая политика начала наследоваться...<br> https://www.opennet.ru/openforum/vsluhforumID6/16311.html#1 Wed, 21 May 2008 06:04:00 GMT &gt;[оверквотинг удален]<br>&gt;<br>&gt;interface Tunnel1 <br>&gt; description to_RPSB_Kozlova <br>&gt; ip address 192.168.40.12 255.255.255.252 <br>&gt; ip mtu 1300 <br>&gt; ip tcp adjust-mss 1259 <br>&gt; keepalive 15 4 <br>&gt; tunnel source xxxxxx <br>&gt; tunnel destination xxxxxx <br>&gt; crypto map CRYPTO1 <br><br>покрути МТУ, идей больше нет, а вообще это не канальная проблема - если по тунелю radmin и RDP лазят без проблем то капай маздай. А вообще в подобных ситуациях М$ не гарантирует работоспособность (насколько они вообще что то могут гарантировать), для таких случаев у них созданы решения: Лес контролеров, доверительнве отношения, репликация, ДФС - читайте изучайте - может будет меньше проблем :). М$ очень не любит работать по тунелям которые не они сами создают (объяснение тех подержки - у них есть свои "гарантированные" решения типа ISA и так тадалее :))<br>