Пренасочување порта кон WireGuard peer зад NAT: DNAT плус SNAT
DNAT ја доставува барањето, но одговорот излегува од погрешна адреса. Додадете соодветно правило SNAT и поставете ги двете откако тунелот е конфигуриран.
Прелистувач бара https://203.0.113.10:8443, проксито ја прифаќа врската, а услугата на WireGuard peer никогаш не одговара. Правилото DNAT ја врши својата работа; делот што не успева е одговорот. Следете го пакетот низ двете преводи и правилото што недостига станува очигледно. Поправката е уште една NAT наредба во вистинскиот hook, а не нов тунел.
Следете едно барање од почеток до крај
Барањето пристигнува на јавниот интерфејс на проксито, со јавната адреса на клиентот како извор и адресата на проксито како одредиште. Во nat PREROUTING правилото DNAT го препишува одредиштето на адресата на тунелот на peer, 10.90.0.2. Потоа рутирањето го испраќа пакетот надвор преку wg0 и патеката за пренос е завршена.
На peer пакетот сега ја носи оригиналната јавна изворна адреса, бидејќи ништо не ја препишало. Услугата ја прифаќа врската и го испраќа својот одговор до својот стандарден gateway, кој е домашниот рутер пред peer. Тој рутер нема состојба за тек што никогаш не го видел и или го отфрла пакетот или го преведува на својата јавна адреса, што клиентот нема да го прифати.
Асиметријата е целиот проблем: барањето оди низ проксито, а одговорот се обидува да оди директно. Следењето врски на проксито помага само ако одговорот се враќа низ проксито, а таму не може да се врати додека изворната адреса сѐ уште покажува на оригиналниот клиент.
Додадете го повратниот превод
Препишете го изворот на пренесениот тек на адресата на тунелот на проксито пред да замине кон peer. Потоа услугата одговара на 10.90.0.1, проксито го прима и следењето врски ги превртува двата превода пред пакетот да се врати кај клиентот.
iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1Правилото POSTROUTING е намерно тесно: се совпаѓа со преведеното одредиште и интерфејсот на тунелот, па не го препишува неврзаниот сообраќај што случајно излегува преку wg0. Широко правило masquerade исто така би ја сокрило адресата на клиентот, но тоа би го правело за секој тек и би го отежнало ревидирањето на NAT табелата.
Поставете ги правилата таму каде што постои тунелот
Правилата што упатуваат на адресата или интерфејсот на тунелот мора да се извршуваат откако wg-quick ќе го конфигурира. Интерфејсот се создава пред PreUp, но адресите, MTU, DNS и рутите се применуваат потоа, а PostUp се извршува кога сето тоа е на место. Додавањата ставете ги во PostUp, а бришењата во PreDown.
PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1Бришењата мора да одговараат на додавањата токен по токен, вклучително совпаѓањата multiport и интерфејс. Бришење што се разликува во едно совпаѓање не отстранува ништо, а следното повторно поврзување додава втора копија од правилото. По неколку повторни поврзувања табелата содржи дупликати што тешко се припишуваат на конфигурациска линија.
Проверете го резултатот со iptables -t nat -S по повторно поврзување. Ако истото правило се појави двапати, линијата PreDown не се совпаѓа и чистењето тивко не успева.
Пренос, филтрирање и другиот NAT
Овозможете пренос на IPv4 трајно, потоа дозволете го пренесениот тек во табелата за филтрирање. DNAT се случува пред синџирот FORWARD, па правилото за филтер се совпаѓа со преведеното одредиште, а не со јавната адреса. Ако UFW управува со firewall, изразете го дозволувањето како правило за рута; обично правило за host не го покрива пренесениот сообраќај.
Два други слоја NAT сѐ уште можат да ја скршат патеката дури и кога правилата на проксито се точни. На домашна врска јавната адреса му припаѓа на рутерот, а отворањето на портата во неговиот firewall не е исто како создавање запис за пренос на порта што ја испраќа таа порта до проксито. Порта што однадвор изгледа отворена, а ништо не одговара, често токму го нема тоа мапирање.
На NAT VPS добавувачот мапира јавна порта на приватна адреса. Мапирањето мора да се совпаѓа со портата што ја објавувате, а несовпаѓањето изгледа идентично како скршен тунел. Потврдете го мапирањето на добавувачот пред да ја промените конфигурацијата на WireGuard.
Проверете ја повратната патека и прифатете ја цената
Поврзете се од мрежа што не е LAN на проксито, потоа проверете го парот на преводи додека врската е отворена:
conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080Записот во conntrack треба да ги покаже оригиналниот tuple, преведениот tuple и насоката на одговорот. Ако одговорот недостасува, peer не праќа низ тунелот, што обично значи дека правилото SNAT не е применето или дека сопствениот firewall на peer го отфрлил текот.
Рестартирајте еднаш за да докажете дека PostUp повторно ги применува правилата, потоа запрете го тунелот и потврдете дека PreDown ги отстранил. Мртвите правила што преживуваат прекин се причината зошто подоцнежна промена се однесува непредвидливо.
На крајот прифатете што чини SNAT. Услугата го гледа секое барање како да доаѓа од проксито, па затоа дневниците за пристап, ограничувањата на брзина по клиент и списоците со дозволени адреси повеќе не ги разликуваат корисниците. Случајот hairpin бара сопствен превод на изворот за клиентите на LAN на проксито. Ако на peer му се потребни вистински адреси на клиентите, алтернативата е повратна рута кон мрежата на клиентот, што е повеќе работа но ја зачувува информацијата.