Зашто ваш LAN не може да достигне услугу на VPN клијенту

Ваш тунел је активан, услуга слуша, а канцеларијски LAN и даље не добија ништа назад. Нико није покварио VPN. Са LAN стране, адреса тунела преносног рачунара не постоји док нешто не каже LAN-у како да је достигне, и одговор мора да се врати истим путем којим је захтев отишао. Видео сам људе како три пута изнова граде потпуно исправан тунел пре него што је ико погледао повратни пут.

Није тунел то што се покварило

Оба краја седе на приватним опсезима, што је нормалан случај, а не погрешна конфигурација. Адреса попут 10.8.0.6 стварна је унутар тунела и не постоји нигде другде, па LAN нема разлога да јој ишта шаље. Пре него што додирнете усмеравање, потврдите да је услуга уопште доступна унутар тунела: на клијенту ss -ltn показује да ли се слушалац везује за 127.0.0.1, за LAN интерфејс или за адресу тунела. Демон везан само за loopback не одговара никоме осим себи, и томе не помаже никаква рута, DNAT ни прослеђивање порта.

Прокси на порту 80 или 443 други је алат с другом видљивошћу. Он премешта захтеве, а не пакете, па је погрешан слој за сирову везу с базом података, и управо посезање за њим доводи до тога да овај проблем заврши три алата дубоко пре него што ико било шта измери.

Облик руте: реците LAN-у где је базен

Статичка рута на LAN приступнику најчистији је одговор када се LAN и базен тунела не преклапају. Усмерите базен на машину која завршава тунел:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

То исправља само један смер, и зато половичне верзије ове промене изгледају као напредак. Тунелској страни треба одговарајућа половина, иначе одговор напушта клијента преко његове властите подразумеване руте и умире на путу:

push "route 192.168.1.0 255.255.255.0"

За подмрежу која стоји иза једног клијента, а не иза сервера, серверу требају и системска рута и унос iroute у датотеци тог клијента под client-config-dir. Без iroute OpenVPN зна да префикс постоји и нема појма који клијент га поседује: пакети долазе, а демон нема с чим да их упари.

Ево мита који вреди именовати. Рута чини адресу доступном; она не чини другу страну вољном да одговори. Site-to-site партнери додају још један слој поврх тога, јер удаљени приступник прихвата само изворе унутар префикса наведених у његовој политици, а преносни рачунар који долази из кућног базена није унутар њих.

Облик NAT-а: DNAT према унутра и линија SNAT-а коју сви прескачу

Када не можете да дирате LAN приступник или желите да објавите тачно један порт, превођење на VPN хосту ради без икакве руте на LAN-у. Објавите порт, проследите га и преведите извор на путу у тунел:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Трећа линија је она која изостане. Прескочите је и клијент види изворну LAN адресу као извор, одговара преко своје подразумеване руте, а тај одговор одлази у тунел уместо назад према LAN-у. Хоће ли веза преживети, тада зависи од усмеравања које никада нисте планирали. Уз SNAT клијент види адресу тунела сервера, па одговор следи тунел назад до јединог хоста који може да поништи превођење.

Потрошачки firmware користи властита имена ланаца и не генерише то превођење за вас. На Tomato-у долазно правило пада у WANPREROUTING, а затим у филтерски ланац попут wanin, и скуп правила који изгледа потпун још увек треба ручну POSTROUTING линију. То није грешка firmware-а; то је скуп правила написан само за долазни саобраћај.

Зашто правило које изгледа исправно ипак одбацује пакет

Већина тих кварова није у правилу у које буљите. Проверите четири ствари овим редом и зауставите се на првој која не важи:

• Редослед ланаца. iptables -I умеће на врх, а -A додаје на крај, па раније допуштено или блокирајуће правило одлучује прво.
• Погрешан ланац. Саобраћај адресиран на сам усмеравач пролази кроз INPUT, а прослеђени саобраћај га никада не дира. Објава једне услуге може да захтева правила у оба.
• Ознаке смера. -i tun0 се подудара са саобраћајем који долази од клијената, а -o tun0 са саобраћајем који одлази према њима. REJECT са погрешном ознаком блокира нешто што нисте намеравали.
• Ограничење извора. Прослеђивање које прихвата једну адресу клијента ради од тог клијента и одбацује сваки други извор без речи.

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

Локално прослеђивање, када се на LAN-у ништа не може променити

SSH локално прослеђивање заобилази цело питање. Не треба му рута на LAN-у, ни сарадња клијентовог заштитног зида, ни порт објављен било где:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Услуга се тада појављује на localhost:3000 машине која држи тунел, и нигде другде. То је граница: једна радна станица, један порт, и прослеђивање умире са сесијом ако га нешто не рестартује. За администратора који проверава припремну базу података то је прави алат. За камеру или скенер до којих други људи морају да дођу није, јер би сваки корисник требао властито прослеђивање.

Проверите оба смера пре него што додате још једно правило

Превођење оставља трагове, а читање их је боље од нагађања. На VPN хосту conntrack -L показује да ли је превођење уопште настало, iptables -t nat -L -n -v показује да ли су се бројачи померли, а tcpdump -ni any port 3000 показује која је изворна адреса заправо стигла. На клијенту ss -ltn потврђује да је слушалац на адреси коју тунел може да достигне.

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