Category Archives: Uncategorized
Из-за медленного VPN на работе озаботились настройкой маршрутизации. Нужно было настроить так, чтобы весь трафик, кроме того, для которого реально требовался VPN, шел обычным образом – через шлюз по умолчанию. В результате нашли путь, который нам нужен:
1. В свойствах адаптера VPN-соединения зайти в IPv4 -> Advanced и снять галочку “Use default gateway on remote network”, в IPv6 тоже. После снятия галочки весь траффик, который раньше шел через VPN – будет идти так, как было без него. После этого нам будет нужно явно добавить маршрут (маршруты), для которых VPN необходим.
2. Определить адрес шлюза VPN-соединения – открыть статус адаптера на вкладке Details. В нашем случае это адрес 172.19.71.70
3. Определить номер интерфейса VPN-соединения командой route print. В нашем случае это номер 42.
4. Определить, какая подсеть (или отдельные адреса) нуждается в том, чтобы быть маршрутизируемой через VPN. Для этого уже не получится просто подсмотреть куда-нибудь, нужно знать, к каким IP-адресам вы подключаетесь. Либо задайте сами (если вы знаете), либо спросите у знающего коллеги. В моём случае это адреса 192.168.*.*, поэтому маска будет 255.255.0.0
5. Записать команду
route -p add 192.168.0.0 mask 255.255.0.0 172.19.71.70 if 42
Параметр -p означает, что добавляемый маршрут будет сохранён (persistent). Параметр if 42 означает, что этот маршрут будет применяться только при поднятом интерфейсе 42 (то бишь при подключенном VPN). Если не указывать if, то маршрут будет работать только до дисконнекта VPN. При дисконнекте Windows увидит, что маршрут неприменим, и уберёт его. И даже после переподключения, несмотря на то, что маршрут создан с параметром -p, он не активизируется. Придётся его удалять и добавлять снова вручную – и так при каждом переподключении. А если указать if, то при отключении от VPN система поймёт, что маршрут не нужно убирать, а нужно только деактивировать его до повторного поднятия интерфейса.
6. Переподключиться к VPN
7. Проверить маршрутизацию до публичных серверов (yandex.ru, например) и до внутренних компьютеров, доступных только в контексте VPN.
tracert yandex.ru
tracert 192.168.1.4
Первый маршрут должен идти так же, как и при отключенном VPN. Второй – через шлюз VPN-подключения.
Меня всегда пугал этот инструмент. Пугал тем, что я НИЧЕГО не понимал в том, что он выводит. Я не понимал, как настраивать фильтры, не понимал, что вообще происходит и как это использовать. Мешал высокий порог вхождения. Когда-то такими же сложными для меня были Eclipse, IntelliJ IDEA, mercurial, maven ну и так далее. И чтобы преодолеть этот порог, обычно нужен хороший QuickStart – пятиминутный гайд, как включиться в работу. Без него всё идёт туго и невесело. Вот такой гайд я и хочу предложить.
Итак, задача наша такая – посмотреть TCP-пакеты, идущие “на” или “с” заданного IP-адреса.
1. Включаем wireshark, выбираем сетевой интерфейс, который будем мониторить. Можно выбрать несколько интерфейсов. Выбираем тот, который используется для нашего сетевого взаимодействия. То есть например у вас программа обращается к серверу, который расположен в интернете, и несколько интерфейсов: один Ethernet, подключенный к интернету, другой – Wi-Fi для взаимодействия в рамках вашей локальной сети. Нас в этой ситуации будет интересовать Ethernet-адаптер. Его и выбираем. Нажимаем Start.
2. Пошли пакетики, их очень много, и нам нужно задать правила для фильтрации. Так как нас интересует TCP протокол, то мы можем использовать например следующее правило:
tcp && (tcp.srcport == 80 || tcp.dstport == 80)
Первое условие отфильтровывает tcp-пакеты, второе – применяет дополнительные правила для порта.
Если нужно наложить условие на IP адреса, то это можно сделать так: ip.src_host == 87.31.220.35
3. Всё работает ! Достраивать правила для фильтрации несложно, поскольку есть автодополнение.
4. Если вы хотите перехватывать loopback-траффик (который идет через localhost), то тут, к сожалению, есть проблема. Дело в том, что этот траффик не доходит до сетевых адаптеров, и WireShark не в состоянии его перехватить. http://stackoverflow.com/questions/5847168/wireshark-localhost-traffic-capture Вот тут есть 2 решения этой проблемы: в первом случае предлагается установить Microsoft Loopback Adapter и натравить на него WireShark, во втором случае предлагается пошаманить с маршрутизацией. Судя по отзывам, оба способа работают, так что всё ок 🙂
За отладкой программы, которая постоянно посылает и принимает сообщения по GPRS с сервера, почувствовал необходимость в имитации плохого соединения, погуглил инструменты и нашел следующее:
1. SoftPerfect Connection Emulator – платная (100 баксов за standard edition), встала на мою Win7 x64 без проблем, позволяет выбрать сетевой интерфейс и задать ему скорость и различные побочные эффекты (% потерь пакетов, дубликаты пакетов, reordering). К сожалению, в триальной версии можно юзать сессии не более 30 секунд, потом сетевой интерфейс начинает работать как обычно и надо заново включать эмуляцию. 30 секунд – это слишком мало, поэтому стал искать дальше.
2. Wipfw – портированный с FreeBSD стандартный инструмент, позволяет делать почти все что и SoftPerfect, но, к сожалению, работает пока только на Windows XP или Windows Server 2003. Ну, мне большего и не надо, взял соседнюю свободную тачку, поставил туда wipfw и запустил серверное приложение. Все сработало наура, сначала подключился в обычном режиме, начал передавать данные и на второй машине включил 100% потери пакетов. Некоторые сообщения успели “отправиться” перед тем, как приложение поняло, что соединение не функционирует. И следующие сообщения уже были сохранены в локальном хранилище для отправки, когда соединение восстановится. Естественно, первые сообщения, “отправленные” на сервер – потерялись.
Минигайд по wipfw. Программа ставится как служба (service) сетевого интерфейса (ее видно, если зайти в свойства соединения), и висит постоянно.
А для манипуляции правилами нужно запускать ipfw.exe.
Вот так можно посмотреть список всех правил: ipfw.exe show
А так удалить все правила (программа спросит подтверждения): ipfw.exe flush
Полный запрет на прием IP-пакетов с хоста 172.28.1.4: ipfw.exe add deny ip from 172.28.1.4 to any
Потеря 30% пакетов: ipfw.exe add prob 0.3 deny ip from 172.28.1.4 to any
2