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

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

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

Поврзани статии