Ракувањето на PiVPN работи, страниците заглавуваат: проверете MASQUERADE

Телефонот го прикажува тунелот како поврзан, клиентот пријавува приватна адреса, а првата страница и понатаму виси на средина од вчитувањето. Таа комбинација ги испраќа повеќето луѓе во поставките за шифрирање и во температурата на процесорот, каде што всушност ништо не е расипано. Тунелот се крена, значи преговорите завршија; она што не успеа е следниот чекор, кога серверот се обидува да ги предаде пакетите на клиентот на интернет. Одете по истиот пат по кој одат тие пакети, и неусогласеноста обично се гледа во еден ред од NAT табелата.

Започнете од тоа до што клиентот може и не може да стигне

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

Адреса на тунел што одговара на ping додека јавните сајтови истекуваат по време е знак за проблем со препраќање или преведување, а не за скршено ракување. Сопствениот панел за состојба на клиентот не може да ги разликува, зашто знае само дека контролниот канал е кренат. Проверете го на серверот интерфејсот на тунелот со ip -br addr show tun0 и потврдете дека адресата доделена на клиентот паѓа во базенот што сте го конфигурирале. Ако базенот и адресата на клиентот не се совпаѓаат, поправете го тоа прво, зашто секое правило подолу се совпаѓа со базенот.

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

Прочитајте го правилото што одлучува дали пакетите излегуваат

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

Излистајте ја живата табела и читајте ја колоната за излезен интерфејс наместо само да го барате зборот 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, а горниот рутер не смее сам да филтрира приватни изворни адреси.

Докажете дека правилото се активира, потоа изолирајте што е и понатаму бавно

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

Споредете два преноса од истиот клиент, еден кон домаќин во локалната мрежа и еден низ тунелот кон истиот домаќин. Бавно во двата случаи упатува на излезниот канал на Pi или на Wi-Fi врската, не на VPN. Бавно само низ тунелот упатува на MTU и повторните испраќања, кои можете да ги проверите со ip -s link show tun0 пред да промените која и да е поставка за шифрирање.

За да го поништите експериментот, вратете ја копијата и вчитајте ја повторно, потоа потврдете дека оригиналното правило и неговите бројачи се вратиле. Запишете го излезниот уред и командата за вчитување во белешките на серверот, зашто следната промена на каналот пак ќе ја открие истата неусогласеност. Правилото што именува погрешен уред останува невидливо сето додека сообраќајот не го побара.