Csak egy helyi webszolgáltatást irányítson a VPN-en kívülre port szerint

Egy hosztszolgáltatásnak a fizikai felső linken kell válaszolnia az internetnek, miközben a gépen minden más tovább használja az alagutat. Három feltétel dönti el, hogy a házirend-alapú forgalomirányítás elbírja-e ezt a terhelést, és mindegyik olcsón ellenőrizhető a szabály megírása előtt. A szolgáltatásnak ezen a hoszton kell végződnie, nem DNAT vagy továbbított port mögött, a VPN saját szabályainak engedélyezniük kell a kivételt, és a választ kell egyeztetni, nem a kérést. Ha bármelyik elbukik, az alábbi parancsok tisztán betöltődnek, de semmi hasznosat nem tesznek.

Ellenőrizze a három feltételt a szabály megírása előtt

Egy konténer, amely DNAT-tal tesz elérhetővé egy portot, vagy egy porttovábbítás mögött álló kiszolgáló olyan csomagokat állít elő, amelyek nem ezen a hoszton keletkeznek. Ezeket a csomagokat továbbítják, ezért a hoszt helyi bemenetére épülő szabály soha nem látja őket és a forgalom továbbra is az alapértelmezett útvonalat veszi. Erősítse meg, hol fut valójában a szolgáltatás, mielőtt folytatja, mert ezt a feltételt rontják el az emberek a leggyakrabban.

A második feltétel házirend, nem mechanika. Minden útvonal, amely megkerüli az alagutat, kivétel az alagút céljából, és egy felügyelt hoszton ez a döntés a házirend tulajdonosáé, nem azé, aki egy időtúllépést hibakeres.

A választ egyeztesse, ne az ügyfél célportját

Egy TCP 443-on figyelő kiszolgáló válasza forrásport 443-mal hagyja el a hosztot. Ugyanazon a hoszton egy böngésző, amely távoli HTTPS-oldalhoz kapcsolódik, rövid életű forrásportot és 443-as célportot küld. Mindkettő 443-as port forgalom, és csak az egyiküknek kellene a WAN-táblát használnia, ezért a célport szerinti egyeztetés a rossz felét fogná meg.

A válasz iránya az, amit meg tud különböztetni. Egyeztesse a forrásportot, korlátozza a szabályt a helyben létrehozott csomagokra, és a szabály lefedi a szolgáltatás saját válaszait anélkül, hogy hozzányúlna a böngésző kéréseihez.

Építsen teljes visszatérési táblát, mielőtt a szabály rá mutat

Az üres tábla azt jelenti, nincs útvonal, ami inkább tűnik törött szolgáltatásnak, mint törött házirendnek. Töltse fel először egy olyan táblaszámmal és prioritással, amelyre a hoszton semmi más nem tart igényt:

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

Olvassa le a számokat az élő hosztról ahelyett, hogy lemásolná őket. ip -4 rule show megmondja, mely prioritások foglaltak, és egy már létező prioritásra tett szabály csendben megváltoztatja két, külön-külön rendben lévőnek tűnő szabály sorrendjét.

Két szelektor végzi itt az igazi munkát. iif lo az, ahogyan a kernel jelenti a hoszt által maga előállított csomagokat, így a szabály nem foghatja el véletlenül a kívülről érkező továbbított forgalmat. ipproto tcp sport 443 egyetlen átviteli protokollra és egyetlen portra szűkíti, ami olyan szoros, amilyen szigorú a követelmény engedi. Vegye ki a protokollszelektort, és a szabály az UDP 443-at is elkapja, ami más viselkedésű, más szolgáltatás.

Tartsa a privát válaszokat az alagúton belül

Ha ugyanaz a figyelő a privát oldal ügyfeleinek is válaszol, a 100-as táblában mindent elkapó WAN-alapértelmezés megpróbálja ezeket a válaszokat a felső linken visszaküldeni. Adja hozzá azokat a privát előtagokat, amelyeknek nem szabad követniük a WAN-alapértelmezést, vagy engedje át őket a következő házirend-szabályra:

ip -4 route add table 100 throw 10.90.0.0/24

A throw-útvonal befejezi a keresést ebben a táblában, és visszaadja a csomagot a szabálylistának, így a következő VPN-házirend megkapja a maga esélyét. Maga nem irányít semmit az alagútba, és ha egyetlen későbbi szabálynak sincs megfelelő útvonala, a csomag továbbra is elbukik; ellenőrizze a következő házirendet ahelyett, hogy a throw-t javításnak tekintené.

A fordított útvonal szűrése és a hoszt tűzfalszabályai továbbra is érvényesek a beérkező kérésre. Nézze meg a tényleges döntéseiket, mielőtt lazítja az ellenőrzést, mert az útvonal-kivétel nem teszi azt, hogy rp_filter elfogadjon egy általa lehetetlennek tartott visszatérési útvonalat.

Tesztelje a TCP-t, majd a QUIC-et, majd egy újraindítást

Nyisson egy kapcsolatot egy engedélyezett külső ügyféltől és egyet a privát oldalról, majd vizsgálja meg a válaszkeresést a tényleges címekkel és portokkal. Ha a külső válasz a 100-as táblát veszi, a privát pedig nem, a házirend azt teszi, amit kért.

A HTTP/3 UDP-n keresztül szolgálódik ki, és egy TCP-szabály nem fogja egyeztetni, ezért a QUIC-figyelőnek saját szelektorra van szüksége, különben tovább használja az alagutat, miközben a HTTPS működik. Mentse el a választott szabályokat az interfészt birtokló komponensnél, és erősítse meg őket újracsatlakozás vagy DHCP-megújítás után. Ha egy versengő kezelő újraindítás után eltávolít egy futásidejű útvonalat, az tulajdonjogi probléma, amelyet a forrásnál kell megoldani, nem ok arra, hogy szélesebb NAT-szabályokat tegyen rá.