VPN (виртуальная частная сеть) часто воспринимают как волшебный зашифрованный туннель, который «скрывает» вашу личность. Но это восприятие очень абстрактно и иногда вводит в заблуждение. Я не являюсь экспертом в сетевых технологиях, но знаю достаточно, чтобы объяснить, что происходит на самом деле, когда вы включаете VPN.
Чтобы понять, как работает VPN, вот простой пример с HTTP-сервером. Давайте представим, что вы хотите подключиться к Google (например, по IP-адресу 1.2.3.4) на порту 80, и предположим, что ваш IP-адрес отправителя — 6.6.6.6. Это фактически ваш общедоступный IP-адрес маршрутизатора, а не ваш личный IP-адрес ноутбука, так что я упрощу объяснение и пропущу NAT.
Обычно без VPN ваш клиент отправляет сегмент SYN на порт 80, который упаковывается в IP-пакет с пунктом назначения IP 1.2.3.4 и исходным IP-адресом 6.6.6.6. Google отправляет ответ непосредственно вам с сегментом SYN/ACK, где IP-адрес назначения — 6.6.6.6, а исходный IP-адрес — 1.2.3.4, и так продолжается обмен. Ваш интернет-поставщик (Интернет-провайдер) видит IP-пакеты, которые вы отправляете туда и обратно на 1.2.3.4. Они могут решить провести глубокий анализ и просматривать содержимое, и это возможно в случае использования нешифрованного HTTP (порт 80), но не так легко для HTTPS (порт 443).
Теперь предположим, что вы развернули VPN, использующий протокол UDP, и вы используете VPN-сервер с IP-адресом 3.3.3.3. Клиент все равно создает IP-пакет SYN с адресом назначения 1.2.3.4 и исходным IP-адресом 6.6.6.6, но затем VPN-клиент перехватывает этот IP-пакет, шифрует его и помещает в новую датаграмму UDP с информацией о VPN. Затем эта UDP-датаграмма упаковывается в новый IP-пакет с адресом назначения 3.3.3.3 и исходным IP-адресом 6.6.6.6.
Этот IP-пакет покидает вашу сетевую карту (NIC), и ваш
интернет-поставщик видит, что вы направляетесь к 3.3.3.3, а не к 1.2.3.4,
потому что последний IP-пакет зашифрован и включен в этот внешний IP-пакет. VPN-сервер получает этот IP-пакет, распаковывает его, расшифровывает (этот процесс включает сложную логику по поиску ключа и т. д.), а затем определяет,что вы хотите подключиться к 1.2.3.4. VPN-сервер создает совершенно новый IP-пакет (или, возможно, повторно использует с нулевой копией), меняя исходный IP-адрес на свой собственный — 3.3.3.3, таким образом, SYN-сегмент достигает Google.
Google отправляет ответ с сегментом SYN/ACK на 3.3.3.3, VPN-сервер понимает, что этот пакет должен достичь вас (6.6.6.6), поэтому он создает новый IP-пакет со своим исходным IP-адресом 3.3.3.3 и адресом назначения 6.6.6.6, и помещает в него SYN/ACK.
Помните, что то же самое происходит, когда вы используете TLS. TLS Client Hello пересылается всю дорогу до Google через VPN, так же, как и любой другой пакет. Вот почему вы также получаете сквозное шифрование, и VPN на самом деле не может читать HTTPS-трафик. Это означает, что да, вы действительно подвергаетесь двойному шифрованию и расшифрованию при использовании VPN.
Почему UDP, а не TCP, для VPN? Вы можете использовать TCP, но в этом случае может возникнуть проблема «TCP meltdown«, когда два алгоритма управления перегрузкой конфликтуют друг с другом (внешнее и внутреннее TCP-соединение). С UDP проще пересылать только утерянные пакеты и иметь более простую логику повторной передачи без всей сложности TCP.
Помните, что это всего лишь одна реализация, и вы можете создать собственный протокол VPN, чтобы достичь того же результата.
