VPN клиентите се поврзуваат, но нема интернет: три делови што недостасуваат

Клиентот добива адреса, серверот одговара на ping, и сепак секоја страница истекува. Повеќето луѓе во овој момент почнуваат да го уредуваат профилот на клиентот, што обично е залуден труд: штом тунелот е кренат, серверот мора да се однесува како рутер. Три услови мора да важат истовремено пред пакетот да излезе и да се врати одговор, и симптомот е ист кој и да недостасува.

Зошто работен тунел уште нема излез

Јадрото мора да проследува пакети меѓу интерфејсите, што е стандардно исклучено на повеќето Linux дистрибуции. Сообраќајот мора да се преведе во адреса на која надворешниот свет може да одговори, освен ако секој нагорен рутер веќе не го знае повратниот пат до подмрежата на тунелот. Патеката за проследување на огнениот ѕид мора да го дозволи сообраќајот во двете насоки, вклучително одговорите.

Секое од овие може да се поправи одделно, и токму тоа е стапицата. Вклучувањето проследување без правило за превод остава пакетите да излегуваат со приватно извориште и без повратен пат. Додавањето превод без правило за проследување го остава јадрото да го испушти пакетот еден чекор подоцна.

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

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

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

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

Направете ја постојана во датотека под /etc/sysctl.d/, потоа примени ја таа датотека наместо да рестартирате за да дознаете. На FreeBSD еквивалентот е net.inet.ip.forwarding, а за постојаност — gateway_enable=YES во rc.conf. Уред што пријавува дека проследувањето е исклучено објаснува цела класа извештаи „пакетите пристигнуваат, а ништо не се враќа”. Проверувајте го поставувањето и по секое надградување, бидејќи повторно изградено јадро или заменет слика на уред можат да го ресетираат без да кажат никому.

Изберете masquerade или една фиксна адреса за превод

Со динамична надворешна адреса, masquerading е наједноставната правилна форма. Наведете ја подмрежата на тунелот како извориште, а надворешниот интерфејс како излез.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Со статична јавна адреса, преводот на извориштето токму во таа адреса е попредвидлив и полесно се проверува.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Втората форма носи стапица за одржување: тврдо кодирана адреса што подоцна се менува го држи тунелот работоспособен, додека пристапот до интернет тивко запира. Или користете masquerade, или ажурирајте го правилото секогаш кога давателот ќе ве премести. Интерфејсот исто така е важен, бидејќи рутер што го дели сопствениот нагорен тунел мора да преведува преку тој тунел, а не преку физичкиот WAN.

Табелата за филтрирање е третата порта

Проследувањето и преводот можат истовремено да бидат точни, додека пакетот уште умира во табелата за филтрирање. ufw е чест виновник: неговата политика за проследување доаѓа како DROP, а остатокот од поставувањето може да изгледа сосема точно, додека тоа едно поставување го убива сообраќајот. Да се подигне е свесна безбедносна одлука, а не поле за штиклирање.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

Мостен тунел бара различен одговор. Адресата му припаѓа на мостот, а не на физичкиот порт, така што потчинувањето на интерфејсот ја отстранува адресата што ја имал претходно и домаќинот изгледа недостапен додека самиот мост не добие адреса, што може да ја обезбеди dhclient br0. Тој дефект изгледа како VPN проблем, а е проблем на второто ниво. Проверете ја сопствената адреса на мостот пред да го допрете огнениот ѕид, бидејќи промена во филтерот не може да поправи домаќин што повеќе нема адреса од која да праќа.

Каде да гледате кога страницата никогаш не се вчитува

Пингнете ја адресата на тунелот на серверот за да докажете дека тунелот постои. Потоа пуштете traceroute од клиентот до јавна адреса и прочитајте каде запира: на серверот пакетот пристигнува, но не се проследува или преведува; зад серверот проблемот е нагорен и надвор од вашите раце.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

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

На серверот, набљудувајте го надворешниот интерфејс додека клиент вчитува страница. Сообраќајот што излегува со приватна изворна адреса значи дека недостасува превод, а целосното отсуство на одговор значи дека патеката за проследување или нагорниот повратен пат го испушта.

Ако оддалечените клиенти треба да достигнат и домаќини на LAN-от на серверот, запомнете дека LAN-от бара повратен пат до подмрежата на тунелот. Тоа е рутирање, а не превод, и тоа е чекорот што најчесто се заборава откако интернет патеката конечно ќе проработи.