Достизање удаљене /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Одговор мора сам да нађе пут назад
Преписивање дестинације само одлучује где ће пакет бити достављен. Удаљени сервер и даље мора да одговори на адресу до које долази, а то се може уредити на два начина. Преведите извор да би се одговори враћали на вашу кутију, или оставите извор и дајте удаљеној страни руту за опсег клијената.
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 зависности у три сата ујутру није.