Достъп до отдалечена мрежа /24 през тунел: NETMAP, DNAT или маршрут?
Съпоставете цял префикс с NETMAP, добавете правила DNAT за всеки хост или маршрутизирайте реалния диапазон и решете според това какво трябва да вижда далечната страна и кой може да започва трафик.
До подмрежа зад края на тунел можете да стигнете по три начина и една минута събиране на факти обикновено отхвърля два. Фактите са дали сървърите там трябва да различават потребителите, дали някой там някога ще се свърже към вашия диапазон и кой може да редактира рутера на далечния край. Отговорете на тези три и дизайнът се избира сам. Останалото предполага, че вие управлявате края и може да редактирате неговата защитна стена.
Три варианта и какво всъщност променя всеки от тях
Съпоставянето на префикс, DNAT за всеки хост и маршрутизиран префикс местят пакети между същите два диапазона, но променят различни неща. Съпоставянето измисля псевдодиапазон и пренаписва адресите аритметично в движение. Правилата за всеки хост също пренаписват, само че всяка дестинация се именува ръчно. Маршрутизираният префикс не пренаписва нищо: пакетите запазват реалните адреси и двете страни се съгласяват къде живеят тези адреси.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
Започнете елиминирането от далечната страна, където ограниченията са най-трудни за промяна. Ако сървър там записва адресите на клиентите в журнали, проверява ги срещу списък за разрешение или ги предава на друга система, преводът на източника унищожава единствения му идентификатор. Ако далечната страна също трябва да се обажда, преводът отпада напълно, защото там никой не знае, че псевдодиапазонът съществува. Само когато далечната страна просто отговаря на заявки, по-евтините варианти стават безопасни.
Двойки префикси и защо размерите трябва да съвпадат
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Отговорът трябва сам да намери обратния път
Пренаписването на дестинацията само решава къде да бъде доставен пакетът. Сървърът от далечната страна все още трябва да отговори на адрес, който достига, и има два начина да се уреди това. Преведете източника, за да се връщат отговорите към вашата машина, или оставете източника непокътнат и дайте на далечната страна маршрут за диапазона на клиентите.
Маскирането на изхода е по-краткият път: едно правило в POSTROUTING и далечната страна вижда адреса на вашия тунел, така че не се нуждае от собствен маршрут. Цената е, че всички потребители се сгъват в един адрес и журналите по потребител престават да значат нещо. Оставянето на източника непокътнат запазва тази информация, но тогава далечният сайт трябва да изпраща отговорите за диапазона на клиентите обратно през тунела. На OpenVPN сървър това е изпратен 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Прочетете записа в двете посоки: оригиналният кортеж запазва псевдонима като дестинация, докато кортежът на отговора носи реалния адрес. Ако кортежът на отговора липсва, проблемът е в обратния път, а не в правилото. Ако броячите на PREROUTING никога не са мръднали, пакетът никога не е достигнал тази кука.
Сблъсъци и търсенето, което се изпълнява първо
Два различни диапазона могат да се сблъскат и двете повреди изглеждат като счупен тунел, а не като лошо правило. Псевдонимът, който измислите, трябва да е неизползван по целия път, а реалният диапазон на далечната страна не трябва вече да съществува във вашата мрежа. Дубликатът създава периодичен трафик към грешен хост и това е по-трудно за диагностициране от отказана връзка. Попитайте таблицата за маршрутизация, преди да добавите правило.
На шлюза ip route get 192.168.2.17 трябва да назове устройството на тунела; локален мост означава, че далечният диапазон е засенчен и никое правило 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. Съпоставяне, което изчезва при рестартиране, е по-лошо от никакво, защото прекъсването идва без скорошна промяна, която да обвиним.
Оставете бележка до правилата: псевдодиапазона, реалния диапазон, причината за двойката и коя страна може да инициира. Тази бележка разделя дизайн от купчина правила, които никой не смее да изтрие. Тя също решава по-късния въпрос, когато далечният сайт добави хост и адрес, който никой не е конфигурирал, вече отговаря. Ако бележката казва, че далечната страна се нуждае от обратен маршрут, следващият човек знае, че премахването на правилото за маскиране прекъсва свързаността. Документацията тук е евтина; преоткриването на зависимост от NAT в три през нощта не е.