Доступ да аддаленай сеткі /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 у тры гадзіны ночы — не.