Јавен префикс преку OpenVPN: поправка на повратниот пат

Гледајте како тунелот се крева и клиентот го пингува спротивниот крај, а потоа јавна адреса што припаѓа зад VPN-от одговара од друго место или воопшто не одговара. Овој симптом обично нема никаква врска со шифрата или сертификатите. Префиксот што го насочува давателот се доставува како IP рута, и неговото пренесување преку OpenVPN значи да се репродуцира таа рута на две нивоа и да се сочува изворната адреса на повратниот пат. Не е потребно премостување на WAN, и додавањето на адресата на интерфејс не ја создава горната рута.

Префиксот прво мора да се насочи кон вас

Прашајте го давателот како се доставува блокот. Префиксот насочен кон главната адреса на вашиот сервер е нешто друго од адресите што давателот очекува да ги достигне директно на WAN сегмент. Само првиот модел работи со дизајнот овде.

Ако давателот го насочува 198.51.100.64/28 кон вашиот влезен сервер, пакетите за тој опсег пристигнуваат на серверот и застануваат таму, освен ако не ги препраќате. Ако давателот наместо тоа го премостува опсегот кон вашиот uplink, серверот мора да одговори со ARP за него, што е друг проблем.

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

Две нивоа на насочување: рута во јадрото и iroute

OpenVPN му треба префиксот на две места. Јадрото мора да знае дека префиксот му припаѓа на тунелскиот уред, за да влезат препратените пакети во OpenVPN наместо во стандардната рута. OpenVPN исто така мора да знае кој автентификуван клиент го поседува префиксот, а тоа е записот iroute во директориумот специфичен за клиентот.

Рутата на страната на серверот изгледа вака, при што префиксот и маската мора да одговараат на распределбата:

ip route add 198.51.100.64/28 dev tun0

Конфигурацијата специфична за клиентот доделува сопственост. Ставете ја во CCD датотеката именувана по заедничкото име на клиентскиот сертификат, и потврдете дека токму тој директориум серверот навистина го чита:

iroute 198.51.100.64 255.255.255.240

Документацијата на OpenVPN за насочени мрежи ги опишува двете нивоа и зошто се одделени. Рута во јадрото без iroute испраќа пакети во тунелот без сопственик, и OpenVPN ги отфрла. iroute без рутата во јадрото ги остава пакетите на стандардниот пат на серверот. Двете грешки изгледаат од страната на клиентот како скршен тунел.

Каде живее адресата на услугата

Делегираниот префикс не е исто што и сопствените адреси на тунелот. Нумерирајте ја врската од приватниот простор ако сакате, и поставете ја јавната адреса на услугата таму каде што услугата навистина работи.

На Linux клиент што ја завршува услугата локално, доволна е една адреса на домаќин:

ip address add 198.51.100.70/32 dev lo

Ако префиксот се насочува понатаму кон VM домаќин или друга LAN, наместо тоа конфигурирајте го тој низводен пат и неговата повратна рута. Доделувањето на секоја адреса во блокот на VPN клиентот не е потребно и подоцна создава конфликти.

Зачувајте го јавниот извор на повратниот пат

Одговорот од делегираниот префикс мора да излезе низ тунелот и да стигне до рутата на давателот. Ако оддалечениот домаќин го испраќа преку својот ISP, изворната адреса изгледа лажна, и давателот или дестинацијата го отфрлаат. Решението е правило засновано на изворот или посебна табела за насочување, а не поширок NAT. Без него услугата работи од тунелскиот партнер и не успева од секое друго место.

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

iptables -t nat -S POSTROUTING

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

Проверете ги двата правци пред да му верувате

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

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

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

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

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

На крајот, тестирајте го случајот на неуспех. Запрете го тунелот и потврдете дека јавниот префикс не истекува низ обичниот uplink. Враќањето на VPN треба да ја врати услугата без да ги прошири портите што домаќинот ги отвора.