Достигнување на оддалечена /24 преку тунел: NETMAP, DNAT или рута?

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

Три опции и што всушност менува секоја од нив

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

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

Парови префикси и зошто големините мора да се совпаѓаат

NETMAP е цел на nat табелата што работи на пар префикси со иста должина. Внатре нема табела по адреса: го отстранува префиксот, ги задржува битовите на домаќинот и повторно ги прикачува на новиот префикс, затоа /24 се мапира на /24 и никогаш на /25. Позицијата ја одредува насоката: совпаѓањето на дестинацијата во PREROUTING препишува каде оди пакетот, а совпаѓањето на изворот во POSTROUTING препишува од каде дошол.

Домаќин на 192.168.2.17 им се појавува на вашите клиенти како 10.50.1.17, а последниот октет не е декорација — тоа е истиот број од двете страни. Утре додајте домаќин на 192.168.2.40 и неговиот алијас е 10.50.1.40, без правило што треба да се уредува.

На клиентите уште им треба рута за опсегот на алијасот што покажува кон вашата кутија, освен ако алијасот не паѓа во подмрежа што тие веќе ја достигнуваат. На портата не ѝ треба рута за алијасот, бидејќи преведувањето на дестинацијата се извршува во PREROUTING, пред пребарувањето на рутата. И проследувањето мора да биде вклучено, инаку јадрото го отфрла пакетот по препишувањето. Трите команди подолу се целата конфигурација на порта во стил на Debian со клиенти на br0, алијас на 10.50.1.0/24 и тунел на tun0.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Одговорот мора сам да го најде патот назад

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

Masquerade во излезната насока е пократок пат: едно правило во POSTROUTING и далечната страна ја гледа вашата тунелска адреса, па не ѝ треба сопствена рута. Цената е што секој корисник се собира во една адреса, а дневниците по корисник престануваат да значат нешто. Оставањето на изворот недопрен ја чува таа информација, но тогаш далечната локација мора да ги враќа одговорите за опсегот на клиентите назад низ тунелот.OpenVPN сервер тоа е push-испратено push "route 10.50.9.0 255.255.255.0", плус route 192.168.2.0 255.255.255.0 линија.

Скапиот неуспех е да се направи половина од секое. Ако маскирате дел од сообраќајот додека далечната страна носи и повратна рута за друг сообраќај, одговорите пристигнуваат на интерфејс каде записот за следење на врската никогаш не бил виден. Клиентот пријавува истек на време за барање што серверот го забележал како опслужено. Двете насоки на текот мора да ја поминат истата netfilter инстанца: една порта преведува, а не два огнени ѕида во серија.

conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -n

Прочитајте го записот во двете насоки: оригиналната tuple го чува вашиот алијас на дестинацијата, додека одговорната tuple ја носи вистинската адреса. Ако одговорната tuple недостасува, проблемот е повратниот пат, а не правилото. Ако бројачите на PREROUTING никогаш не се помрднале, пакетот никогаш не стигнал до тој hook.

Судари и пребарувањето што се извршува прво

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

На портата, ip route get 192.168.2.17 треба да го именува тунелскиот уред; локален bridge значи дека далечниот опсег е засенчен и ниту едно nat правило нема да го поправи. Ако вашата мрежа веќе користи 192.168.2.0/24, пренумерирајте ја далечната локација наместо да натрупувате мапирање врз сударот.

Тестирање од вистински клиент, потоа задржување

Тестирајте од машина што навистина ќе го користи алијасот, не од портата, бидејќи локално генерираниот сообраќај никогаш не го поминува PREROUTING на ист начин. Отворете врска кон еден домаќин со алијас и гледајте како бројачите и conntrack записот се појавуваат заедно, потоа затворете и потврдете дека записот си оди. Застарен запис покажува на полуотворена врска, што обично значи дека одговорот никогаш не се вратил.

curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17

Две или три успешни врски ја докажуваат аритметиката, но не кажуваат ништо за трајноста или за следниот инженер. Зачувајте ги правилата таму каде што ги чита процесот за подигање, што на Debian и Ubuntu значи iptables-save > /etc/iptables/rules.v4 со вклучен netfilter-persistent. Мапирање што исчезнува при рестартирање е полошо од никакво, бидејќи прекинот доаѓа без неодамнешна промена што би се обвинила.

Оставете белешка покрај правилата: опсегот на алијасот, вистинскиот опсег, причината за парот и која страна смее да иницира. Таа белешка го дели дизајнот од куп правила што никој не се осмелува да ги избрише. Таа го решава и подоцнешното прашање, кога далечната локација додава домаќин и адреса што никој не ја конфигурирал веќе одговара. Ако белешката вели дека на далечната страна ѝ треба повратна рута, следниот човек знае дека отстранувањето на masquerade правилото ја прекинува поврзаноста. Документацијата овде е евтина; повторното откривање на NAT зависност во три часот наутро не е.