Ръкостискането на PiVPN работи, страниците забиват: проверете MASQUERADE

Телефонът показва тунела като свързан, клиентът съобщава частен адрес, а първата страница все още виси по средата на зареждането. Тази комбинация изпраща повечето хора в настройките за шифроване и температурите на процесора, където всъщност нищо не е сбъркано. Тунелът се вдигна, значи преговорите са приключили; провалила се е следващата стъпка, когато сървърът се опитва да предаде пакетите на клиента към интернет. Извървете същия път, по който минават тези пакети, и несъответствието обикновено се вижда в един ред от NAT таблицата.

Започнете с това до какво клиентът има и няма достъп

От свързания клиент заредете страница, която живее в публичния интернет, и отбележете дали се проваля веднага, или забива по средата. После отворете ресурс на собствения частен адрес на VPN сървъра и сравнете двата резултата.

Адрес на тунела, който отговаря на ping, докато публичните сайтове изтичат по време, е признак за проблем с препращането или транслацията, а не за счупено ръкостискане. Собственият панел за състояние на клиента не може да ги разграничи, защото знае само, че контролният канал е вдигнат. Проверете на сървъра интерфейса на тунела с ip -br addr show tun0 и потвърдете, че зададеният на клиента адрес попада в пула, който сте настроили. Ако пулът и адресът на клиента не съвпадат, поправете това първо, защото всяко правило по-долу се съпоставя с пула.

След това попитайте сървъра през кой интерфейс би достигнал публичен адрес. ip route get 203.0.113.9 отпечатва избраното устройство и източник на първия си ред. Запишете името на устройството, защото точно тази стойност трябва да съдържа правилото NAT.

Прочетете правилото, което решава дали пакетите излизат

MASQUERADE пренаписва пакет само когато пакетът излезе през интерфейса, посочен в правилото. Правило, ограничено до кабелно устройство, не прави нищо за трафика, който излиза през Wi-Fi, и пакетът запазва частния си адрес на източника чак до upstream рутера. Този рутер няма обратен маршрут към вашия пул на тунела, затова изхвърля отговора, и клиентът вижда връзка, която се отваря и после умира. Симптомът зависи от това колко от страницата пристига, преди да е нужен първият отговор.

Избройте живата таблица и четете колоната за изходящ интерфейс, вместо да търсите само думата MASQUERADE. Изходът в добавяща форма е по-лесен за сравнение от форматиран списък:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

На Raspberry Pi, който някога е ползвал Ethernet, а сега ползва Wi-Fi, старото име почти винаги е цялата история. Инсталаторът е записал каквото устройство е присъствало при настройката, и запазеният набор правила го възпроизвежда при всяко зареждане. Сравнете устройството от търсенето на маршрут с това в правилото, преди да променяте нещо друго. Ако съвпадат, интерфейсът не е вашият проблем и трябва да преминете към броячите в последния раздел. Ако се различават, поправката е редакция на една дума във файла за персистентност.

Поправете запазения набор правила, а не само работещия

Редакцията само на живата таблица оцелява до следващото рестартиране, което е точно достатъчно дълго, за да ви убеди, че проблемът е решен. Правилата, които се връщат при зареждане, живеят във файл, който пакет за персистентност на защитната стена презарежда. На образи за Pi на базата на Debian този файл обикновено е /etc/iptables/rules.v4.

Направете копие, преди да го пипате, после заменете изходящия интерфейс в реда MASQUERADE с устройството, което записахте, например -o wlan0 вместо -o eth0. Оставете диапазона на източника както е, освен ако пулът на клиентите ви не се е променил. Презаредете и потвърдете, че правилото вече сочи правилното устройство:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Две съседни настройки лесно се забравят. sysctl net.ipv4.ip_forward трябва да показва 1, а upstream рутерът не бива сам да филтрира частни адреси на източника.

Докажете, че правилото сработва, после изолирайте какво още е бавно

Броячите са единственото честно доказателство, че дадено правило е съвпаднало. Пуснете подробния списък, започнете изтегляне на клиента и го пуснете отново. Колоните за пакети и байтове до вашето правило трябва да растат, а правило, което остава на нула, още не съвпада. Ако броячите се движат, но страниците още се провалят, сравнете диапазона на източника с действителния пул с grep -n "^server " /etc/openvpn/server.conf. Ако се движат и страниците се зареждат, но пропускливостта е слаба, транслацията е свършена и оставащият проблем е другаде.

Сравнете два трансфера от един и същ клиент, един към хост в локалната мрежа и един през тунела към същия хост. Бавно и в двата случая сочи към изходящия канал на Pi или Wi-Fi връзката, а не към VPN. Бавно само през тунела сочи към MTU и повторни предавания, които можете да прегледате с ip -s link show tun0 преди да промените каквато и да е крипто настройка.

За да отмените експеримента, възстановете копието и го презаредете отново, после потвърдете, че първоначалното правило и броячите му са се върнали. Запишете изходящото устройство и командата за презареждане в бележките на сървъра, защото следващата промяна на канала ще открие същото несъответствие. Правило, което сочи грешно устройство, остава невидимо, докато трафикът не го поиска.