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

Поправите сачувани скуп правила, не само онај који ради

Измена само живеће табеле траје до следећег рестарта, што је тачно довољно дуго да вас увери да је проблем решен. Правила која се враћају при подизању живе у датотеци коју пакет за трајност firewall-а поново учитава. На Pi сликама заснованим на Debianu та датотека је обично /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 пре него што промените било коју крипто поставку.

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