A ajunge la un /24 aflat departe printr-un tunel: NETMAP, DNAT sau rută?
Mapează un prefix întreg cu NETMAP, adaugă reguli DNAT pentru fiecare gazdă sau rutează intervalul real, și decide după ce trebuie să vadă partea îndepărtată și cine poate porni traficul.
Poți ajunge la o subrețea din spatele unui punct final de tunel în trei moduri, iar un minut de strângere de fapte descalifică de obicei două. Faptele sunt dacă serverele de acolo trebuie să distingă utilizatorii, dacă cineva de acolo va apela vreodată spre intervalul tău, și cine poate edita routerul de la capătul îndepărtat. Răspunde la acestea trei și proiectarea se alege singură. Restul presupune că tu administrezi punctul final și poți edita firewall-ul acestuia.
Trei opțiuni și ce schimbă de fapt fiecare
Maparea prefixului, DNAT per gazdă și un prefix rutat mută toate pachetele între aceleași două intervale, dar schimbă lucruri diferite. Maparea inventează un interval alias și rescrie adresele aritmetic în zbor. Regulile per gazdă și ele rescriu, doar că fiecare destinație este numită manual. Un prefix rutat nu rescrie nimic: pachetele păstrează adresele reale și ambele capete sunt de acord unde locuiesc acele adrese.
| 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 |
Începe eliminarea din partea îndepărtată, unde constrângerile sunt cel mai greu de schimbat. Dacă un server de acolo scrie adresele clienților în jurnale, le verifică față de o listă de permisiuni sau le predă altui sistem, traducerea sursei îi distruge singurul identificator. Dacă partea îndepărtată trebuie și să apeleze spre interior, traducerea este exclusă complet, pentru că nimeni de acolo nu știe că aliasul există. Doar când partea îndepărtată doar răspunde la cereri devin opțiunile mai ieftine sigure.
Perechi de prefixe și de ce dimensiunile trebuie să coincidă
NETMAP este o țintă din tabela nat care lucrează pe o pereche de prefixe de lungime identică. Nu are o tabelă per adresă în interior: scoate prefixul, păstrează biții de gazdă și îi reatașează noului prefix, de aceea un /24 se mapează pe un /24 și niciodată pe un /25. Poziția decide direcția: o potrivire de destinație în PREROUTING rescrie unde merge un pachet, iar o potrivire de sursă în POSTROUTING rescrie de unde a venit.
O gazdă la 192.168.2.17 apare clienților tăi ca 10.50.1.17, iar ultimul octet nu este decor — este același număr pe ambele părți. Adaugă mâine o gazdă la 192.168.2.40 și aliasul ei este 10.50.1.40, fără regulă de editat.
Clienții au în continuare nevoie de o rută pentru intervalul alias care indică spre cutia ta, dacă aliasul nu cade într-o subrețea pe care o ating deja. Gateway-ul nu are nevoie de o rută pentru alias, pentru că traducerea destinației rulează în PREROUTING, înainte de căutarea rutei. Și forwarding-ul trebuie pornit, altfel kernelul aruncă pachetul după rescriere. Cele trei comenzi de mai jos sunt întreaga configurație pe un gateway în stil Debian, cu clienții pe br0, aliasul pe 10.50.1.0/24 și tunelul pe 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 MASQUERADERăspunsul trebuie să-și găsească singur drumul înapoi
Rescrierea destinației decide doar unde este livrat un pachet. Serverul îndepărtat tot trebuie să răspundă la o adresă la care ajunge, și asta se poate aranja în două feluri. Tradu sursa ca răspunsurile să se întoarcă la cutia ta, sau lasă sursa și dă părții îndepărtate o rută pentru intervalul clienților.
Masquerade pe ieșire este drumul mai scurt: o regulă în POSTROUTING și partea îndepărtată vede adresa tunelului tău, deci nu are nevoie de o rută proprie. Costul este că fiecare utilizator se prăbușește într-o singură adresă, iar jurnalele per utilizator nu mai înseamnă nimic. Dacă lași sursa intactă, informația se păstrează, dar atunci site-ul îndepărtat trebuie să trimită răspunsurile pentru intervalul clienților înapoi prin tunel.OpenVPN server asta este un push "route 10.50.9.0 255.255.255.0", plus o route 192.168.2.0 255.255.255.0 linie.
Eșecul scump este să faci jumătate din fiecare. Dacă măștilezi o parte din trafic în timp ce partea îndepărtată poartă și o rută de întoarcere pentru alt trafic, răspunsurile ajung pe o interfață unde intrarea de urmărire a conexiunii nu a fost văzută niciodată. Clientul raportează un timeout pentru o cerere pe care serverul a înregistrat-o ca servită. Ambele direcții ale unui flux trebuie să treacă prin aceeași instanță netfilter: un singur gateway care traduce, nu două firewall-uri în serie.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nCitește intrarea în ambele direcții: tuplul original păstrează aliasul tău pe destinație, iar tuplul de răspuns poartă adresa reală. Dacă tuplul de răspuns lipsește, problema este drumul de întoarcere, nu regula. Dacă contoarele PREROUTING nu s-au mișcat niciodată, pachetul nu a ajuns niciodată la acel hook.
Coliziuni și căutarea care rulează prima
Două intervale diferite pot intra în coliziune, iar ambele eșecuri arată ca un tunel stricat, nu ca o regulă proastă. Aliasul pe care îl inventezi trebuie să fie nefolosit pe tot drumul, iar intervalul îndepărtat real nu trebuie să existe deja în rețeaua ta. Un duplicat produce trafic intermitent către gazda greșită, mai greu de diagnosticat decât o conexiune refuzată. Întreabă tabela de rutare înainte de a adăuga o regulă.
Pe gateway, ip route get 192.168.2.17 ar trebui să numească dispozitivul tunelului; un bridge local înseamnă că intervalul îndepărtat este umbrit și nicio regulă nat nu îl repară. Dacă rețeaua ta folosește deja 192.168.2.0/24, renumerotează site-ul îndepărtat în loc să stivuiesti o mapare peste coliziune.
Testarea dintr-un client real, apoi păstrarea
Testează de pe o mașină care va folosi cu adevărat aliasul, nu de pe gateway, pentru că traficul generat local nu traversează niciodată PREROUTING la fel. Deschide o conexiune către o gazdă cu alias și urmărește contoarele și intrarea conntrack apărând împreună, apoi închide-o și confirmă că intrarea pleacă. O intrare veche indică o conexiune pe jumătate deschisă, ceea ce de obicei înseamnă că răspunsul nu s-a întors niciodată.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Două sau trei conexiuni reușite dovedesc aritmetica, dar nu spun nimic despre persistență sau despre următorul inginer. Salvează regulile acolo unde procesul de boot le citește, ceea ce pe Debian și Ubuntu înseamnă iptables-save > /etc/iptables/rules.v4 cu netfilter-persistent activat. O mapare care dispare la repornire este mai rea decât niciuna, pentru că întreruperea vine fără nicio schimbare recentă de învinovățit.
Lasă o notă lângă reguli: intervalul alias, intervalul real, motivul perechii și care parte poate iniția. Acea notă separă un proiect de o grămadă de reguli pe care nimeni nu îndrăznește să le șteargă. Ea rezolvă și întrebarea de mai târziu, când site-ul îndepărtat adaugă o gazdă și o adresă pe care nimeni nu a configurat-o răspunde deja. Dacă nota spune că partea îndepărtată are nevoie de o rută de întoarcere, următoarea persoană știe că eliminarea regulii de masquerade rupe conectivitatea. Documentația este ieftină aici; redescoperirea unei dependențe de NAT la trei dimineața nu este.