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

VPN клиент може да хоства услуга, която LAN не може да отвори. Липсва обикновено обратният път: един маршрут, двойка DNAT или редът SNAT, който никой не добавя.

Тунелът ви е вдигнат, услугата слуша, а офисната 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 знае, че префиксът съществува, и няма представа кой клиент го притежава: пакетите пристигат, а демонът няма с какво да ги съпостави.

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

Форма на 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 клиентът вижда адреса на тунела на сървъра, така че отговорът следва тунела обратно до единствения хост, който може да отмени транслацията.

Потребителският фърмуер използва собствени имена на вериги и не генерира тази транслация вместо вас. На Tomato входящо правило попада в WANPREROUTING, а след това във филтърна верига като wanin, и набор от правила, който изглежда пълен, все още се нуждае от ръчен ред POSTROUTING. Това не е дефект на фърмуера; това е набор от правила, написан само за входящ трафик.

Защо правило, което изглежда правилно, все пак изхвърля пакета

Повечето от тези откази не са в правилото, в което се взирате. Проверете четири неща в този ред и спрете на първото, което не е изпълнено:

  • Ред на веригите. 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 потвърждава, че слушателят е на адрес, до който тунелът може да стигне.

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

Подобни статии