Beindu aðeins einni staðbundinni vefþjónustu fram hjá VPN eftir porti

Ein þjónusta hýsilsins verður að svara internetinu um líkamlega uppstreymisleiðina á meðan allt annað á vélinni heldur áfram að nota göngin. Þrjú skilyrði ráða því hvort beining byggð á stefnu geti borið þessa byrði, og hvert þeirra er ódýrt að athuga áður en þú skrifar reglu. Þjónustan verður að enda á þessum hýsli en ekki bak við DNAT eða framsent port, reglur VPN-sins sjálfs verða að leyfa undantekninguna, og þú verður að para svarið en ekki beiðnina. Ef eitt af þremur bregst hlaðast skipanirnar hér fyrir neðan án villu en gera ekkert gagnlegt.

Athugaðu skilyrðin þrjú áður en þú skrifar reglu

Gámur sem birtir port í gegnum DNAT, eða þjónn sem situr bak við framsendingu ports, býr til pakka sem eiga ekki uppruna sinn á þessum hýsli. Þessir pakkar eru framsendir, svo regla sem byggir á staðbundnu inntaki hýsilsins sér þá aldrei og umferðin heldur áfram að taka sjálfgefna leið. Staðfestu hvar þjónustan keyrir í raun áður en þú heldur áfram, því þetta er skilyrðið sem fólk villist oftast á.

Annað skilyrðið er stefna en ekki vélfræði. Sérhver leið sem fer fram hjá göngunum er undantekning frá tilgangi þeirra, og á stýrðum hýsli tilheyrir sú ákvörðun þeim sem á stefnuna, ekki þeim sem kembir tímamörk.

Paraðu svarið en ekki áfangaport biðlarans

Svar frá þjóni sem hlustar á TCP 443 yfirgefur hýsilinn með upprunaporti 443. Vafri á sama hýsli sem tengist fjarlægri HTTPS síðu sendir skammvinn upprunaport og áfangaport 443. Bæði er umferð á porti 443 og aðeins eitt þeirra ætti að taka WAN-töfluna, þess vegna myndi samsvörun á áfangaporti grípa ranga helminginn.

Stefna svarsins er það sem þú getur greint. Paraðu upprunaportið, takmarkaðu regluna við pakka sem eru búnir til staðbundið, og reglan nær yfir eigin svör þjónustunnar án þess að snerta beiðnir vafrans.

Byggðu fulla afturhvarfstöflu áður en reglan bendir á hana

Tóm tafla þýðir engin leið, sem lítur út eins og biluð þjónusta frekar en biluð stefna. Fylltu hana fyrst, með töflunúmeri og forgangi sem ekkert annað á hýslinum gerir tilkall til:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Lestu tölurnar af lifandi hýsli í stað þess að afrita þær. ip -4 rule show segir þér hvaða forgangar eru teknir, og að bæta reglu við forgang sem er þegar til breytir hljóðlega röð tveggja reglna sem hvor um sig lítur vel út.

Tveir valar gera hér raunverulega vinnu. iif lo er leiðin sem kjarninn tilkynnir pakka sem hýsillinn bjó sjálfur til, svo reglan getur ekki óvart gripið framsenda umferð sem kemur að utan. ipproto tcp sport 443 þrengir það að einni flutningseiningu og einu porti, sem er eins þröngt og krafan leyfir. Fjarlægðu samskiptaregluvalinn og reglan grípur líka UDP 443, sem er önnur þjónusta með aðra hegðun.

Haltu einkasvörum inni í göngunum

Ef sami hlustandinn svarar líka biðlarum á einkahliðinni mun sjálfgefin WAN-leið sem grípur allt í töflu 100 reyna að senda þau svör til baka um uppstreymisleiðina. Bættu við einkaforskeytunum sem eiga ekki að fylgja sjálfgefnu WAN-leiðinni, eða leyfðu þeim að falla til næstu stefnureglu:

ip -4 route add table 100 throw 10.90.0.0/24

Throw-leið endar leitina í þessari töflu og skilar pakkanum aftur til reglulistans, svo VPN-stefnan sem fylgir fær tækifæri sitt. Hún beinir engu sjálf inn í göngin, og ef engin síðari regla hefur samsvarandi leið mistekst pakkinn samt; staðfestu næstu stefnu í stað þess að gera ráð fyrir að throw sé lagfæring.

Sía á öfugri leið og eldveggsreglur hýsilsins gilda enn um beiðnina sem berst. Skoðaðu raunverulega úrskurði þeirra áður en þú slakar á sannprófuninni, því beiningarundantekning lætur rp_filter ekki samþykkja afturleið sem hún telur ómögulega.

Prófaðu TCP, svo QUIC, svo endurræsingu

Opnaðu eina tengingu frá heimiluðum utanaðkomandi biðlara og eina frá einkahliðinni, og skoðaðu svo svaraleitina með raunverulegum vistföngum og portum. Ef ytra svarið tekur töflu 100 en einkasvarið ekki, er stefnan að gera það sem þú baðst um.

HTTP/3 er veitt um UDP og verður ekki parað af TCP-reglu, svo QUIC-hlustandi þarf sitt eigið val, annars heldur hann áfram að nota göngin á meðan HTTPS virkar. Geymdu þær reglur sem þú lendir í hjá þeirri einingu sem á viðmótið, og staðfestu þær eftir endurtengingu eða DHCP-endurnýjun. Þegar samkeppnisstjórnandi fjarlægir keyrsluleið eftir endurræsingu er það eignarhaldsvandamál sem á að laga við upptökuna, ekki ástæða til að bæta víðtækari NAT-reglum ofan á.