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

Ставете фаќање од двете страни на 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 адресата ако било што од тоа е можно таму каде што работите.