SNAT, DNAT и Masquerade: шта ради свако VPN NAT правило

Поставите снимање са обе стране VPN пролаза и један ток може показати четири различите адресе. Изворни NAT преписује место одакле пакет тврди да долази; одредишни NAT преписује место куда иде. Masquerade није трећи смер, то је правило изворног NAT-а које узима адресу од излазног интерфејса уместо фиксне вредности. Именујте које од три стварно требате и већина тикета „VPN је покварен“ своди се на питање о повратном путу.

Шта свако правило преписује

Изворни NAT, обично написан SNAT, мења изворну адресу тока док напушта рутер или пролаз. Услуга која прима одговара на преведену адресу, а кутија која преводи поништава промену користећи стање које је чувала за ту везу. На Linux-у то стање живи у conntrack-у, зато conntrack -L исписује оригиналне и повратне торке једне поред других.

Одредишни NAT, DNAT, мења одредиште уместо тога. Пакет упућен на јавну адресу на UDP 51820 може се преписати на интерни WireGuard сервер на 10.8.0.2:51820. Тако кућни рутер или облак балансер објављује VPN слушаоца, и то не говори ништа о томе шта тунел сме да носи после.

Masquerade припада породици SNAT. Правило не именује адресу; користи ону коју излазни интерфејс има кад пакет изађе. Linux му даје сопствену мету, и то је уобичајен избор на WAN интерфејсу који адресу добија од DHCP или PPPoE.

Где мапа живи, одређује квар

Запишите торку на свакој граници: пре тунела, унутар њега и на јавном интерфејсу. Снимање унутар тунела легитимно се разликује од оног изван њега, и свако ко пореди та два а не зна где се превод догађа тражиће погрешног домаћина.

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

Друга честа грешка је очекивати да тунел ствара рутабилност. Приватном клијенту чији пакети излазе на интернет треба ваљан излазни аранжман: подразумевана рута, пролаз који прослеђује и обично изворни превод на јавну адресу. Шифровање само по себи не чини приватну адресу доступном.

Masquerade или експлицитни SNAT

Упоредите их по томе шта обећавају. Masquerade бира излазну адресу, експлицитни SNAT је фиксира. На пролазу са стабилном јавном адресом фиксирање даје логовима и партнерским листама дозвола једну предвидиву вредност. На динамичном WAN линку фиксирана SNAT адреса постаје погрешна у тренутку кад се закуп промени, а Masquerade је направљен управо за тај случај.

Обим је важан колико и избор. Masquerade правило које погађа сваки пакет који напусти пролаз, без ограничења извора или одредишта, преводи и саобраћај који сте намеравали да оставите нетакнутим, укључујући саобраћај ка другим приватним мрежама. Ограничите правило на опсег клијената, жељено одредиште и интерфејс.

IPsec заснован на политици ту највише боли. strongSwan-ов водич за прослеђивање пролази кроз укључивање IP прослеђивања и додавање правила изворног NAT-а за клијенте, а иста документација покрива и изузимање саобраћаја који мора да задржи оригиналну адресу. Преведите извор пре него што га сигурносна политика погоди, и тунел може стати док саобраћај и даље пада, јер пакет више не изгледа као преговарани селектор.

Одлучите и шта далеки крај треба да види. После превода услуга види пролаз, а не појединачног клијента. То поједностављује повратно рутирање и истовремено изравнава логове и обесмишљава листе дозвола по клијенту. Ако је очување адреса клијената важно, планирајте рутирани повратни пут уместо да их кријете да би тест прошао.

Читање правила на Linux пролазу

Пролаз за даљински приступ са клијентима на 10.8.0.0/24 и WAN интерфејсом по имену eth0 треба укључено прослеђивање и филтерску политику која допушта ток пре него иједно NAT правило помогне. Верзија са iptables држи оба смера у табели nat:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

nftables облик користи иста два кука са именованим интерфејсом и експлицитним ланцем:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Оба исечка претпостављају да филтерски ланац већ прихвата прослеђени ток. NAT није правило дозволе, и исправно преведен пакет може и даље бити одбачен једну табелу касније. Потврдите живу мапу са conntrack -L, потврдите шта је учитано са nft list ruleset или iptables-save -t nat, па снимите на оба интерфејса да видите да се адреса заиста мења.

Начини квара који изгледају као лоше правило

Саобраћај типа укоснице је класика. Интерни клијент који до интерног сервера долази преко јавне адресе сервера треба DNAT на улазу и изворни превод на повратном излазу, иначе сервер одговара право клијенту и одговор бива одбијен. Исправка је друго, уже правило за тај случај интерно-према-јавном, а не шире Masquerade правило за све.

Двоструки превод је тихи. Клијент који је већ иза NAT-а на нивоу оператера долази на ваш пролаз са адресом коју не можете рутирати назад, па преводите поново. Ради, али логови сада носе два скока приватног адресирања и свака истрага треба обе мапе. IPsec заснован на политици додаје трећи обрт: преведите пре поклапања политике и добијате SA који је подигнут без саобраћаја који пролази, што се чита као грешка у заштитном зиду, не у NAT-у.

Затим ту је тест који пролази и распоређивање које пада. Ручно покретање NAT наредбе доказује механизам, не конфигурацију. Правило додато у току рада нестаје при поновном покретању или на следећем догађају интерфејса, а Masquerade правило везано за интерфејс који мења број може тихо променити адресу коју далеки крај види. Ставите правило у конфигурацију заштитног зида који га поседује и поново тестирајте после поновног повезивања.

Контролна листа пре него што сачувате правило

Прво именујте смер: извор, одредиште или обоје. Затим одредите ко мора да држи стање — пролаз, рутер изнад или IPsec партнер — и потврдите да се повратни пут враћа кроз њега. Ограничите правило на опсег клијената, одредиште и интерфејс које заиста имате на уму, и унапред одлучите да ли далеки крај треба да види пролаз или оригиналну адресу клијента.

Тестирајте са клијента, не са пролаза. Прегледач на самом пролазу може потпуно заобићи правило превода за клијенте, па страница која тамо ради не доказује ништа о тунелу. Пошаљите један захтев који потиче од клијента, гледајте бројаче и conntrack табелу, и поновите после поновног повезивања тунела и промене WAN адресе ако је било шта од тога могуће тамо где радите.