Miért a VPN-en keresztül válaszol a nyilvános Linux-szolgáltatásod

A socketben semmi sem emlékszik arra, melyik interfész szállította a kérést, ezért egy teljes alagútú VPN alapértelmezett útvonala elkaphat egy választ, amely a WAN-hoz tartozik. A szolgáltatás nem hagyja figyelmen kívül a bejövő interfészt; a Linux a helyben létrehozott választ a cél és a forráspolitika szerint irányítja. Egy forrásalapú szabály ehelyett csak a szolgáltatás válaszait küldheti egy teljes WAN-táblán keresztül, a szokásos kimenetet az alagúton hagyva. A port nyitva marad, miközben a válasz a rossz útvonalon távozik, ezért tűnik egyoldalúnak a tünet.

A tévhit: a válaszok azt az interfészt követik, amelyen érkeztek

Logikusnak tűnik, hogy az eth0-n érkező csomag az eth0-n távozzon. Az állapotmentes csomagszűrők így is megírhatók, és a bejövő oldalon a tcpdump pontosan ott mutatja a kérést, ahol várható. Az útválasztás nem így működik a gazdagép által létrehozott forgalom esetében.

Amint a szolgáltatás elfogadja a kapcsolatot, a válasza egy új, helyben létrehozott csomag. A kernel a válasz célja és forrása szerint megvizsgálja az útválasztási szabályokat, és a VPN alapértelmezett útvonala teljesen érvényes válasz. A socketben semmi sem emlékszik arra, melyik interfész szállította a kérést.

Ezért tűnik egyoldalúnak a tünet: a kérések megérkeznek, a válaszok eltűnnek. Ezért nem változtat semmit egy tűzfal-szabály hozzáadása a bejövő portra. A csomagot nem a befelé vezető úton blokkolják; a kifelé vezető úton máshová irányítják. Kövesd a választ forrás szerint minősített lekérdezéssel, és láthatóvá válik a kerülőút.

Amit a kernel valójában irányít: a forráscím

A szükséges fogantyú az a helyi cím, amelyet a szolgáltatás a válaszokhoz használ. Egy gazdagépen, amelynek szemléltető eth0-címe 192.0.2.10/24 és átjárója 192.0.2.1, ez a cím jelen van az interfészen. Felhőbeli VM-en a nyilvános cím feljebb lefordított lehet, és hiányozhat a vendégből, ezért azt a címet használd, amely ténylegesen a gazdagépen van.

Vizsgáld meg a jelenlegi állapotot, mielőtt táblaszámot vagy szabályprioritást foglalsz le. A meglévő házirend-szabályok elnyomhatják az újat, és egy azonos számú régi tábla már tartalmazhat független útvonalakat:

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

Ezután válassz táblát forrás szerint. A szabály azokra a válaszokra illeszkedik, amelyek már hordozzák a 192.0.2.10-et, pontosan arra a helyben lezárt forgalomra, amelyet mentesíteni szeretnél. A továbbított forgalom és más helyi címekről érkező csomagok nem illeszkednek.

Teljes visszatérő táblát építs, ne fél alapértelmezett útvonalat

Egy csak alapértelmezett útvonalat tartalmazó tábla nem elég. A kernelnek még mindig fel kell oldania az átjárót, és ehhez a kapcsolt előtagra van szükség ugyanabban a táblában. Az a tábla, amelyből ez az előtag hiányzik, az átjáró feloldásakor meghiúsul, még akkor is, ha az alapértelmezett útvonala helyesnek tűnik. Add hozzá mindkettőt, majd irányítsd a forrásszabályt a táblára:

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

A valódi előtagot és átjárót használd a példa másolása helyett. Egy /32-ként, on-link átjáróval konfigurált felhőinterfész más kapcsolt útvonalat igényel, és a rossz előtagból épített tábla már az első ugrásnál meghiúsul. A src attribútum az adott útvonal preferált forrását adja meg; nem helyettesíti a forrásszabályt.

A sorrend is számít. A széles szabály alacsonyabb prioritásszámmal előbb értékelődik, ezért a forrásszabályt minden olyan szabály előtt el kell érni, amely visszaküldené ezt a forgalmat a fő táblába. Ellenőrizd a prioritásokat a ip rule show segítségével a hozzáadás után, ne csak induláskor.

Ellenőrizd forrás szerint minősített lekérdezéssel

Kérd meg a kernelt, hogy irányítson egy tesztcélt a szolgáltatás címéről. A válasznak az eth0-t és a WAN-átjárót kell megneveznie, nem az alagutat:

ip -4 route get 198.51.100.25 from 192.0.2.10

Ezután hozz létre egy új engedélyezett kapcsolatot, és figyeld mindkét irányt. Egy lekérdezés, amely a helyes táblát választja, miközben az élő kapcsolat továbbra is meghiúsul, a fordított útvonal szűrésére vagy egy tűzfalszabályra utal, nem a táblára. Ellenőrizd ezeket a vezérlőket, mielőtt bármit globálisan letiltanál.

Helyezd a végleges útvonalakat és a szabályt az interfészt birtokló hálózatkezelő alá. A címváltozások, a DHCP-megújítás és a VPN-újracsatlakozások mind újraírják a kernel állapotát, és a kézzel hozzáadott szabály eltűnik vagy elavult átjáróra mutat a következő esemény után.

Hol ér véget ez a kivétel

A szabály egy forráscímről származó, helyben lezárt forgalmat mentesít. Nem terjed ki a Docker által közzétett portokra, a DNAT-ra vagy a gazdagépen keresztül továbbított szolgáltatásokra, mert ezek a csomagok továbbított forgalomként útválasztódnak, és soha nem hordozzák ugyanúgy a gazdagép helyi forrását. Az ilyen tervek általában a belépésnél beállított jelölést és a jelöléshez illeszkedő szabályt igényelnek.

Az sem éri el, hogy a gazdagép nyilvános címe megjelenjen az interfészen. Ha egy felső NAT birtokolja ezt a címet, a válasznak továbbra is azon az útvonalon kell távoznia, amelyet az a NAT vár, ezért a WAN-táblának az eredeti átjárót és előtagot kell tükröznie, nem egy kitalált nyilvános tartományt.

Tartsd dokumentálva a kivételt a táblaszámával, a szabály prioritásával és a pontos forráscímmel. A VPN vagy az interfész következő változása csendben eltörheti, és a három értéket megnevező feljegyzés gyorsabban ellenőrizhető, mint a tünet újrafelfedezése egy ügyféljelentésből.

Ha a szolgáltatás a forrás szerint minősített lekérdezés sikeressége után is a rossz útvonalon válaszol, hasonlítsd össze az élő socket forráscímét a szabályban szereplővel. Egy helyettesítő címhez kötött szolgáltatás a tesztelt címtől eltérő forrást választhat, és ez az eltérés a fennmaradó rés.