A teljes alagút a strongSwanban 0.0.0.0/0-t igényel mindkét oldalon

A teljes alagúthoz 0.0.0.0/0 kell a kliens remote_ts és az átjáró local_ts értékeként, valamint továbbítás, NAT és visszaút. Ellenőrizze mind a négyet.

Egyetlen privát alhálózathoz működő strongSwan-kapcsolat nem fog internetes forgalmat továbbítani csak azért, mert valaki szerkesztett egy sort. A teljes alagút megállapodás két fél között arról, mely címeket védi a child SA, és mindkét fél a másikat önmagához viszonyítva nevezi meg. Az egyik oldalt jól, a másikat rosszul állítja be, és a child SA vagy nem jön fel, vagy a szándéknál szűkebben jön fel. Az alábbi öt ellenőrzés ezt a megállapodást követi a klienstől az átjárón át az internetig.

Először a kliens szelektorát ellenőrizze

A kliens a túloldalon védendő címeket remote_ts-ként írja le, és minden, amit küld, a saját kiosztott címéről indul. Internetes forgalom esetén ennek az értéknek le kell fednie azokat a célokat, amelyeket a felhasználó ténylegesen elér, ami a gyakorlatban a teljes IPv4-teret jelenti. Az a kliens, amely még mindig egy alhálózatot sorol fel, osztott alagutat kér, akármi is a profil neve a felületen. A forrásoldal általában dynamic, mert a cím a csatlakozáskor kerül kiosztásra. Az oda írt rögzített forrás megtörik, amint a címkészlet megváltozik.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

A töredék nem teljes kapcsolatfájl, és ez feltételezi, hogy a hitelesítés, az identitások és a virtuális címkészlet már be van állítva. A kliens forrásszelektorának és a kiszolgáló által kiosztott címnek továbbra is egyeznie kell, különben a child SA olyan hatókörrel jön fel, amelyre egyik fél sem számított. Töltse be a swanctl --load-all paranccsal, és olvassa el a kimenetet, mielőtt sikert feltételez. Egy feldolgozható fájlt még mindig elutasíthat egy olyan szelektor, amely nem fedi át a másik fél javaslatát.

Az átjáró szelektorát a saját oldalán ellenőrizze

Az átjáró ugyanazt a fogalmat ellenkező irányból olvassa. Az internetes célok az átjáró számára helyiek, ezért az ő local_ts értéke a széles, és a remote_ts írja le a kliens címkészletet. Ez az inverzió a leggyakoribb hiba a teljes alagút konfigurációjában, és túléli az ellenőrzést, mert mindkét sor külön-külön hihetőnek tűnik.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

A kliens töredékének bemásolása az átjáró fájljába olyan szelektorpárt hoz létre, amely semmi hasznosat nem ír le, mert mindkét fél ugyanazt a szerepet követelné. Ez a strongSwan továbbítási útmutatója kifejezetten dokumentálja a kliens és az átjáró párosítását, és érdemes a kapcsolatfájl mellett olvasni, nem a hiba után. Az átjáró fájljának szüksége van arra a címkészlet-definícióra is, amelyre a remote_ts hivatkozik. Egy nem létező címkészletet megnevező szelektor panasz nélkül betöltődik, és csatlakozáskor meghiúsul.

A régi ipsec.conf bal és jobb szerepet használ különböző kulcsokkal, és a rightsubnet sor nem közvetlen helyettesítője a swanctl-értéknek. Tartsa a két szintaxist külön fájlokban, ahelyett hogy az egyiket a másikba illesztené. Egy könyvtárban keverni őket az az út, ahogy egy működő kapcsolat újraindítás után csendben visszaáll.

A tárgyalt child SA-t ellenőrizze, nem a fájlt

Egy mentett konfiguráció a szándékot bizonyítja, és semmi többet. A másik fél szűkítheti a kértet, és egy meglévő child SA nem cserélődik ki csak azért, mert az alatta lévő fájl megváltozott. Erősítse meg, mi van valóban telepítve, mielőtt bármi mást módosít.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Az első parancs megmutatja, mit töltött be a démon, a második a létrejött child SA-kat, a harmadik pedig azokat a szabályzatokat, amelyeket a kernel alkalmazni fog. Ha a fájl 0.0.0.0/0-et mond, és a lista egyetlen alhálózatot mutat, a tárgyalás szűkítette a hatókört, és a fájl újraolvasása nem fogja megmagyarázni. Szüntesse meg a child-ot, indítsa újra, és hasonlítsa össze újra mindhárom kimenetet. Az ugyanazzal a szűk hatókörrel visszatérő child-ot a túloldal szűkíti, nem a helyi fájl, és ez beszélgetés a másik rendszergazdával, nem helyi módosítás.

Olvassa mindkét irányt a szabályzatlistában, mert az az alagút, amely az egyik irányt telepíti és a másikat nem, útválasztási probléma konfigurációs jelmezben. Az előre- és hátrairányú szabályzatoknak ugyanazt a szelektorpárt kell tükörképben megnevezniük, és a hiányzó tükör a démon vagy a javaslat hibája, nem a szelektor szövegéé.

Ellenőrizze a továbbítást és a visszautat

Egy szelektor beengedi a forgalmat az átjáróhoz, de nem készteti az átjárót arra, hogy tovább irányítsa azt a forgalmat. A továbbítást engedélyezni kell, a tűzfalnak át kell engednie az áramlást, és a válasznak vissza kell találnia a kliens címkészletéhez. Ez három külön követelmény, és mindegyik más tünettel hiúsul meg. A hiányzó továbbítási szabály fekete lyukként viselkedik, míg a hiányzó visszaút egyirányú alagútként.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

A privát klienscímek általában szándékos forrásfordítást igényelnek, mielőtt elhagyhatnak egy nyilvános interfészt, míg a kifejezetten irányított kiosztás más kezelést kíván. Ha NAT van a játékban, tartsa meg a megvalósítás által támogatott kivételeket, hogy a biztonsági szabályzatnak ellenőriznie kellő forgalom ne forduljon le mellette. Egy másik átjáróról másolt széles masquerade-szabály sokkal több folyamot változtat meg, mint amennyit a szerzője szándékozott. Csak a kliens címkészletére írja meg a szabályt, és hagyjon megjegyzést arról, miért létezik.

A kliensen a háttérrendszer által telepített útvonalakat erősítse meg, ne azokat, amelyeket feltételezett. Az útvonal-telepítést kikapcsolt kezelőnek kézzel karbantartott útválasztási tervre van szüksége, és ezt a tervet minden alagútváltozáskor frissíteni kell. Újracsatlakozás után ellenőrizze az útválasztási táblázatot, ne csak friss indítás után.

Ellenőrizze, mit nem fed le még az alagút

A szelektorpár az IPv4-et fedi le, és semmi mást. Az IPv6, a DNS és bármely alkalmazásszintű szabályzat külön döntés, amelyet egy széles IPv4-szelektor csendben figyelmen kívül hagy. Egy minden IPv4-csomagot szállító alagút még mindig kiszivárogtathat minden névkeresést.

Mondja ki kifejezetten a tervezett DNS-útvonalat, mert a teljes alagút, amely még mindig a helyi feloldón keresztül oldja fel a neveket, a lekérdezéseket az alagúton kívülre szivárogtatja, és elrontja a privát neveket. Ha a kliens IPv6-címet kap, annak a címcsaládnak ugyanerre a kezelésre van szüksége, különben a gazdagép egy olyan útvonalat részesít előnyben, amelyet az alagút nem véd. Teszteljen olyan névvel, amelyre csak a privát oldal tud válaszolni, és a nyilvános választ szivárgásnak tekintse.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Erősítse meg a láncot ezzel a két paranccsal és a fenti listából a tárgyalt szelektorokkal. Ha a traceroute a helyi routert mutatja első ugrásként, a forgalom nem használja az alagutat, bármit is állítanak a szelektorok. Az internetes hozzáférés csak akkor teljes, ha a kiválasztott forgalmat a tervezett átjáró beengedi, továbbítja és visszahozza. A 0.0.0.0/0 megtalálása egy profilban ennek a láncnak a kezdete, nem a bizonyítéka.

Kapcsolódó cikkek