Miért töri el egy forrásport-szabály az egyik SSH-útvonaladat

Egy „sport 22” egyezés nem mondja meg, melyik SSH-belépéshez tartozik egy válasz. Szűkítse a házirendet a felügyeleti forgalomra egyetlen, csak WAN-ra vonatkozó tábla helyett.

Két felügyeleti belépés egy hoszton, egy szolgáltatási port és egy házirend, amelynek mindkettőn segítenie kellett volna. A szabály a 22-es forrásportra illeszkedik, a keresést egy olyan táblába küldi, amely csak a WAN alapértelmezését ismeri, és a VPN-belépés leáll az új bejelentkezések megválaszolásával, miközben a közvetlen belépés tovább működik. Ebben semmi sem rejtélyes, ha a szelektort helyesen olvassuk. A forrásport egy szolgáltatást azonosít, nem azt az útvonalat, amelyen a kapcsolat érkezett.

Két belépés, egy szolgáltatási port

A hosztnak van egy LAN-oldali címe és egy VPN-címe, és az sshd mindkettőn figyel. A közvetlen munkamenet és az alagút-munkamenet ezért megosztja a szolgáltatási portot, és csak abban tér el, hogy melyik helyi cím fogadja a kapcsolatot.

Ez a különbség elegendő a válaszútvonal kiválasztásához, és pontosan ez az a különbség, amelyet a portalapú szabály eldob. Mindkét munkamenet olyan válaszokat állít elő, amelyek forrásportja 22, így az erre a portra illeszkedő szabály nem tudja szétválasztani őket. Mindkét keresést ugyanabba a táblába küldi, és az egyikük olyan választ kap, amely nem illik. A javítás az, hogy arra a tulajdonságra illeszkedjünk, amely valóban különbözik.

Az is működne, ha minden belépés saját portot kapna, és ezt követelményként kezelni tervezési döntés, nem az SSH tulajdonsága.

Olvassa el a szabályt, majd a táblát

A házirend egy rendezett szelektor, és az első, amely használható választ ad, befejezi a keresést. Olvassa el a listát sorrendben, és jegyezze meg, melyik szabály nyerhet.

Ezután olvassa el a táblát, amelyre a szabály mutat, mert egy sikeresen feloldódó szabály nem feltétlenül hasznosan feloldódó szabály. Egy csak alapértelmezett útvonalat tartalmazó tábla a VPN-forrású választ a WAN-interfészen küldi ki. Egy későbbi táblában lévő konkrétabb útvonalat soha nem néznek meg, és ezért gyakran semmit sem változtat egy második tábla hozzáadása. A kiválasztott tábla az, amit meg kell vizsgálni.

ip -4 rule show
ip route show table 100
ip route show table main

Ez a két kimenet együtt magyarázza az eredményt; bármelyik önmagában téves következtetésre csábít.

Szűkítse a szabályt arra a forgalomra, amelyet ért

A két belépést elválasztó tulajdonság a helyi forráscím. Az erre a címre illeszkedő szabály csak az alagút-munkameneteket küldi a privát táblába, a közvetlen munkameneteket pedig a fő táblán hagyja.

Ezt a szabályt olyan táblával kell párosítani, amely tartalmazza a privát útvonalat és az adott alhálózat visszaútját. Mindkettőt a felügyeleti forgalomra szűkítse, ne a hoszt minden szolgáltatására. Egy szabály, amely elkapja az összes forgalmat erről a címről, átirányít minden mást is, amit a hoszt onnan küld. Itt a szűk legyőzi az okosat, mert a következő embernek el kell olvasnia.

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

Ha mindkét belépést egyetlen helyi címre fordítják, ez a megkülönböztetés eltűnik, és a tervezésnek helyette kapcsolat-tudatos állapotra van szüksége.

Tartsa külön a figyelőt, az engedélyt és a válasz kiválasztását

Három külön dolognak kell igaznak lennie, mielőtt egy munkamenet működik: a cím létezik, a szolgáltatás figyel rajta, és a válasz megtalálja a visszautat. Az útvonal módosítása csak a harmadikat javítja.

A figyelő konfigurációja saját fájl és saját újratöltés, és több figyelési cím normális. A hitelesítés megint harmadik döntés, és az útvonal-kivétel senkinek sem ad hozzáférést. Tartsa meg a hosztkulcs-ellenőrzést, a fiókhitelesítést és a forráskorlátozásokat mindkét belépésen, és álljon ellen a kísértésnek, hogy gyengítse az alagút többi ellenőrzését, hogy egy felügyeleti útvonal működjön.

Tartson olyan helyreállítási csatornát, amely nem függ a módosított útvonaltól, mert egy hiba itt magát a javítást zárja ki.

Új munkamenettel bizonyítsa, nem régivel

Egy meglévő terminál semmit sem bizonyít, mert a változtatás előtt engedték be. Nyisson friss munkamenetet minden szándékolt belépésen keresztül.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

Ezután ismételje meg a VPN újracsatlakozását, és próbálja újra, mert az újracsatlakozást túlélő útvonal nem ugyanaz, mint az olyan táblához adott útvonal, amelyet az újracsatlakozás kiürít. Figyelje meg az elutasított forrásokat külön az engedélyezettektől, hogy egy blokkolt kísérlet ne bújjon meg egy működő munkamenet mögött. Mentse el a helyi címet, a szabályt és a táblát az eredmény mellé. Ha inkább felosztja a portokat, jegyezze fel üzemeltetési döntésként, nem az SSH korlátjaként.

Kapcsolódó cikkek