Hvers vegna opinber Linux-þjónusta þín svarar í gegnum VPN-ið

Ekkert í socketnum man hvaða tengi flutti beiðnina, svo sjálfgefna leið VPN með heilum göngum getur gripið svar sem á heima á WAN. Þjónustan hunsar ekki innkomandi tengið; Linux beinir svari sem er búið til á staðnum eftir áfangastað og uppsprettustefnu. Uppsprettutengd regla getur í staðinn sent aðeins svör þjónustunnar í gegnum fulla WAN-töflu og látið venjulega útleið vera á göngunum. Gáttin helst opin á meðan svarið fer út um röngu leiðina, og þess vegna virðist einkennið einhliða.

Ranghugmyndin: svör fylgja tenginu sem þau komu inn á

Það virðist rökrétt að pakki sem kemur inn á eth0 fari út á eth0. Hægt er að skrifa stöðulausar pakkasíur þannig, og tcpdump á innkomandi hlið sýnir beiðnina nákvæmlega þar sem búist er við henni. Beining virkar ekki þannig fyrir umferð sem hýsillinn býr sjálfur til.

Um leið og þjónustan tekur við tengingunni er svarið nýr pakki sem er búinn til á staðnum. Kjarninn skoðar beiningarreglurnar fyrir áfangastað og uppsprettu svarsins, og sjálfgefna leið VPN er fullkomlega gild lausn. Ekkert í socketnum man hvaða tengi flutti beiðnina.

Þess vegna virðist einkennið einhliða: beiðnir berast, svör hverfa. Þess vegna breytir regla í eldvegg fyrir innkomandi gátt líka engu. Pakkanum er ekki lokað á leiðinni inn; honum er beint annað á leiðinni út. Fylgdu svarinu með leit sem er skilyrt eftir uppsprettu og krókurinn verður sýnilegur.

Hvað kjarninn beinir í raun: uppsprettuheimilisfangið

Handfangið sem þú þarft er staðbundið heimilisfangið sem þjónustan notar fyrir svör. Á hýsli með dæmigerða eth0-heimilisfangið 192.0.2.10/24 og gáttina 192.0.2.1 er þetta heimilisfang til á tenginu. Á skýja-VM getur opinbera heimilisfangið verið þýtt ofar og vantað í gestinn, svo notaðu heimilisfangið sem hýsillinn hefur í raun.

Skoðaðu núverandi ástand áður en þú áskilur töflunúmer eða regluforsemd. Fyrirliggjandi stefnureglur geta skyggt á nýja, og gömul tafla með sama númeri gæti þegar borið ótengdar leiðir:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Veldu síðan töflu eftir uppsprettu. Reglan passar við svör sem þegar bera 192.0.2.10, nákvæmlega þá umferð sem lauk á staðnum og þú vilt undanþiggja. Framsend umferð og pakkar frá öðrum staðbundnum heimilisföngum passa ekki.

Byggðu fulla afturleiðartöflu, ekki hálfa sjálfgefna leið

Tafla með aðeins sjálfgefinni leið er ekki nóg. Kjarninn verður samt að leysa gáttina, og sú lausn þarf tengda forskeytið í sömu töflu. Tafla sem vantar þetta forskeyti mistekst við gáttarlausn jafnvel þótt sjálfgefna leið hennar líti rétt út. Bættu báðu við og beindu síðan uppsprettureglunni að töflunni:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Notaðu raunverulega forskeytið og gáttina í stað þess að afrita dæmið. Skýjatengi sem er stillt sem /32 með gátt á tenglinum þarf aðra tengda leið, og tafla byggð á röngu forskeyti mistekst á fyrsta hoppinu. Eiginleikinn src tilgreinir valið uppsprettu fyrir þá leið; hann kemur ekki í stað uppsprettureglunnar.

Röðin skiptir líka máli. Breið regla með lægra forgangsnúmeri er metin fyrst, svo uppsprettureglan verður að nást fyrir hvaða reglu sem myndi senda þessa umferð aftur í aðaltöfluna. Athugaðu forganginn með ip rule show eftir að hafa bætt henni við, ekki bara við ræsingu.

Staðfestu með leit sem er skilyrt eftir uppsprettu

Biddu kjarnann um að beina prófunaráfangastað frá heimilisfangi þjónustunnar. Svarið ætti að nefna eth0 og WAN-gáttina, ekki göngin:

ip -4 route get 198.51.100.25 from 192.0.2.10

Stofnaðu síðan nýja heimilaða tengingu og fylgstu með báðum áttum. Leit sem velur réttu töfluna á meðan lifandi tenging mistekst enn bendir á síun á bakleið eða reglu í eldvegg, ekki töfluna. Athugaðu þessi stýri áður en þú slökktir á einhverju á heimsvísu.

Settu endanlegu leiðirnar og regluna undir netstjórann sem á tengið. Heimilisfangsbreytingar, endurnýjun DHCP og endurtengingar VPN skrifa öll kjarnastöðuna upp á nýtt, og regla sem er bætt við handvirkt hverfur eða bendir á úrelta gátt eftir næsta atburð.

Hvar þessi undantekning endar

Reglan undanþiggur umferð sem lauk á staðnum frá einu uppsprettuheimilisfangi. Hún nær ekki yfir gáttir sem Docker birtir, DNAT eða þjónustur sem eru framsendar í gegnum hýsilinn, því þessir pakkar eru beint sem framsend umferð og bera aldrei staðbundna uppsprettu hýsilsins á sama hátt. Slíkar hannanir þurfa venjulega merki sem sett er við inngang og reglu sem passar við merkið.

Hún lætur heldur ekki opinbera heimilisfang hýsilsins birtast á tenginu. Þegar NAT ofar á heimilisfangið, verður svarið samt að fara út um þá leið sem sú NAT væntir, og þess vegna verður WAN-tafan að endurspegla upprunalegu gáttina og forskeytið frekar en ágiskað opinbert svið.

Haltu undantekningunni skjalfestri með töflunúmerinu, regluforsemdinni og nákvæmu uppsprettuheimilisfanginu. Næsta breyting á VPN-inu eða tenginu getur brotið hana hljóðlaust, og minnismiði sem nefnir þrjú gildi er fljótlegri að athuga en að enduruppgötva einkennið úr skýrslu viðskiptavinar.

Ef þjónustan svarar enn á röngu leiðinni eftir að leitin sem er skilyrt eftir uppsprettu gengur, berðu saman uppsprettuheimilisfang lifandi socketsins við það sem er í reglunni. Þjónusta sem er bundin við algilt heimilisfang getur valið aðra uppsprettu en heimilisfangið sem þú prófaðir, og það misræmi er eftirstandandi bilið.