/ 7.-vpn / 1.-gre / 3-itog.md
3-itog.md
 1  # Итого
 2  
 3  Если попытаться провести аналогии с осязаемым миром, то представим ситуацию, когда вы едете из деревни, инкапсулированные в автомобиль. Доезжаете до реки, и вам надо перебраться на другой берег и там продолжить своё путешествие в город.  
 4  На речном порту ваш автомобиль инкапсулируют в паром и переправляют через бушующие волны на другую сторону, где ваш автомобиль извлекают, и вы продолжаете движение. Так вот этот паром и был GRE-паромом.
 5  
 6  > Сделаем три ремарки:  
 7  > Во-первых, интерфейсы Loopback и адреса с маской /32 мы выбрали просто для теста, фактически это вполне бы могли быть интерфейсы fa1/0.15 и fa0/1.16 с подсетями 172.16.15.0/24 и 172.16.16.0/24, например, или любые другие.  
 8  > Во-вторых, мы тут всё ведём речи о публичных сетях и адресах, но на самом деле, конечно, это не имеет значения и туннели вполне можно поднимать даже внутри своей корпоративной сети, когда конечные сети и так имеют IP-связность без туннеля.  
 9  > В-третьих, несмотря на то, что теоретически обратно трафик может возвращаться и не по туннелю, создать его необходимо, чтобы конечный узел могу успешно декапсулировать GRE-пакеты
10  
11  Обычный GRE – яркий пример туннелирования, который очень просто настраивается и сравнительно легко траблшутится.  
12  Очевидно, вы уже догадываетесь, какие три большие проблемы подстерегают нас на этом поле?
13  
14  * Безопасность. Данные, инкапсулированные в GRE, передаются тем не менее в открытом виде.
15  * Сложность масштабирования. Если у вас 5-7 филиалов, обслуживание такого количества туннелей ещё кажется возможным, а если их 50? Причём туннелирование трафика зачастую производится на CPU, особенно на младшей и средней линейках, поэтому это лишняя нагрузка на процессор.
16  * Все филиалы будут взаимодействовать друг с другом через центральный узел, хотя могли бы напрямую.
17