A webszerverén futó VPN-kliens elrontja a válaszait?
Egy forrásalapú útválasztási szabály helyreállíthat egy közzétett oldalt, miközben olyan forgalmat mentesít, amelyet soha nem szándékozott. Olvassa el a szelektort, mielőtt kiszélesíti a kivételt.
Az oldal ugyanazon a hálózaton lévő laptopról töltődik be, és minden más helyről időtúllépést ad, a gazdagép pedig saját kimenő forgalmához VPN-klienst is futtat. Ez a kombináció sajátos hibát okoz: a bejövő kapcsolat megérkezik, a válasz a rossz úton távozik, és a kívül lévő kliens soha nem lát választ. Mindkét fél ugyanabban a csomagrögzítésben látszik, ezért az események sorrendje az a rész, amelyet érdemes elolvasni.
A forrásalapú útválasztási szabály gyakran megszünteti a tünetet. Általában több forgalmat is mentesít, mint az oldal, amely kiváltotta, és éppen ezt érdemes megérteni a szabály mentése előtt.
A tünet: helyben válaszol, kívülről nem
A hálózaton belül a válasznak nem kell átkelnie az alagúton, ezért az oldal betöltődik, és a szolgáltatás egészségesnek látszik. Kívülről a kérés eléri a gazdagépet, és a válasz a VPN-be irányul, ahol a távoli végnek nincs oka elfogadni. A böngésző időtúllépést lát elutasítás helyett, ami az egyirányú útvonal, nem pedig a zárt port jele.
Erősítse meg a formát, mielőtt módosítja az útválasztást: a figyelő fut, a helyi kérés sikeres, és a külső kérés egyáltalán nem ad választ. Ez a három megfigyelés együtt a visszaútra mutat, nem a webszerver konfigurációjára. Egy ilyen tiszta aszimmetria hasznosabb bármely naplósornál, mert kizárja a figyelőt, mielőtt egyetlen hibaüzenetet is elolvasna.
Munka közben tartson nyitva egy független felügyeleti útvonalat. Egy szabály, amely megtöri a saját SSH-munkamenetét, egy tízperces javítást fizikai látogatássá változtat.
Mit egyeztet valójában egy forrásszelektor
A Linux szabályalapú útválasztásában egy olyan szabály, mint from 192.168.50.2, azokat a csomagokat egyezteti, amelyek forrása ez a cím. Nem kódolja, hogy a csomag egy otthoni routeren belépett beszélgetést folytat, és nem tudja, melyik folyamat hozta létre. A példában szereplő cím szemléltető; helyettesítse azzal a címmel, amelyet a gazdagép valóban használ. Tekintse a sort címekre vonatkozó kijelentésnek, és semmi többnek.
Ha a kiválasztott tábla hétköznapi alapértelmezett útvonalat biztosít, minden ilyen forrású csomag ugyanazt a kivételt veheti. Egy másik, ugyanahhoz a címhez kötött szolgáltatás örökli, és egy alkalmazás, amely szándékosan ehhez a címhez kötődik, szintén örökli. A szabályhivatkozás a forrást, a célt, a protokollt, a portot, a jelölést és a prioritást külön szelektorként sorolja fel, ami emlékeztet arra, hogy a forrás önmagában a legdurvább elérhető.
A prioritás dönti el az eredményt. A keresések sorrendben futnak, és az első eredményt adó tábla befejezheti a keresést, ezért egy túl korán elhelyezett szabály elrejthet egy konkrétabb útvonalat, amelyet egy későbbi tábla biztosított volna. Olvassa el a teljes rendezett listát, ne csak az Ön által hozzáadott egy sort. Egy soha nem egyező szabály semmibe sem kerül, míg egy túl korán egyező csendesen megváltoztat mindent mögötte.
Ellenőrizze a visszautat és a nem szándékolt forgalmat
Olvassa el a szabályokat és a táblákat, majd kérdezze meg a kernelt, melyik útvonalat venné egy adott forrás-cél pár. A gazdagépről tesztelni nem ugyanaz, mint kívülről tesztelni, ezért tegye meg mindkettőt.
ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'
Ezután fogadjon el egy új külső kapcsolatot, és külön egy olyan kérést, amelynek továbbra is a VPN-en keresztül kell kijutnia. Ha a második most közvetlenül kimegy, a kivétel szélesebb, mint a megoldott probléma, és az igazi teszt az, amelyet nem szándékozott megváltoztatni.
A nyilvános cím ellenőrzése a böngészőben csak azokat a kéréseket jelenti, amelyeket az a böngésző tett. Semmit sem mond a webszerver válaszairól, egy másik helyi alkalmazás forrásválasztásáról, vagy arról, mi történik a felügyeleti forgalommal a következő VPN-újracsatlakozás után.
Döntse el, mennyire lehet szűk a kivétel
Két terv védhető, és ezeket tudatosan kell megválasztani. Ha a gazdagép azért létezik, hogy ezt a szolgáltatást közzétegye, és a kimenő forgalma nem fontos, egy csak WAN-szabályzattal rendelkező dedikált helyi cím ésszerű megoldás, feltéve, hogy elfogadja a teljes hatókört. Ha csak bizonyos bejövő kapcsolatoknak kellene megfelelniük, a címválasztás túl durva, és elé kapcsolat-tudatos terv kívánkozik.
Rögzítse a szerződést, amelyre támaszkodik: a nyilvános leképezést, a gazdagép címét, amelyre a kérés kerül, és az útvonalat, amelyet a válasznak vennie kell. A VPN-szolgáltatón keresztül közzétett bejövő szolgáltatás más szerződés, mint az otthoni routeren keresztül közzétett, és az egyik példából másolt kivétel gyakran hibás a másikra.
A szabályzatot az útválasztást birtokló komponensben tárolja, ne illesszen parancsot egy indítási fájlba. A szabálysorrendnek, a hálózatváltás utáni tisztításnak és az újraindítás utáni újrajátszásnak mind túl kell élnie, a ki nem próbált indítási fájl pedig általában abban a pillanatban hibázik, amikor nem figyel. Fejezze be egy megvédhető elfogadási eredménnyel: egy közzétett oldal helyreállítva és egy független folyamat változatlanul.