Az átjáró saját admin oldalt szolgál ki: belső vagy nyilvános cím

Az admin oldal mobilnetről érkező telefonról válaszol, a VPN-hez csatlakozott laptopról viszont időtúllépésbe fut. Az alagúttal nincs semmi baj, mert a kérés soha nem lép be oda. A hosztnév az átjáró nyilvános címére oldódik fel, és az a cím csak azon alagút külsejéről érhető el, amelyet lezár. Ezt úgy lehet rendbe tenni, hogy a szolgáltatás belső belépést kap, nem pedig a külső végpontot mozgatjuk.

Az oldal kívülről töltődik be, nem az alagúton át

Két különböző kérés kerül összehasonlításra. Mobilnetről a böngésző közvetlenül eléri a nyilvános címet. Az alagút belsejéből ugyanaz a név ugyanarra a nyilvános címre oldódik, és a csomagnak most ki kell lépnie az alagúton, hogy elérjen egy címet az alagút saját távoli oldalán. Ugyanaz a név, ugyanaz a cím, két nagyon különböző helyzet.

A célútvonal címet választ, nem portot. A routing táblában semmi sem tudja, hogy a 443-as port az adminisztrációé és az 1194-es port a szállításé, ezért mindkettőt ugyanannak a célnak tekinti.

Ezért működik az oldal néha és néha nem, attól függően, melyik nevet és melyik hálózatot használta a kliens. Ez útvonalprobléma, nem hitelesítési probléma. Mindkét kliens tökéletesen hitelesít.

Tartsa elérhetőn a külső végpontot

A teljes alagút profiloknak kivételútvonalra van szükségük a VPN végpontjához, és az OpenVPN redirect-gateway beállítása pontosan ezt dokumentálja: a távoli végpont megtart egy útvonalat a korábban létező átjárón keresztül, hogy az alagút ne irányítson önmagába. Távolítsa el ezt a kivételt, és a titkosított szállítás követi az alagutat, ami hurokban fejezi be a munkamenetet. Ez a kivétel az oka, hogy a végpont címe elérhető marad az alagút belsejéből.

Ennek következménye, hogy a nyilvános cím a kliensről elérhető marad, és ezért a böngésző kérése arra a címre ugyanazt a kivételt követheti, és belépés nélkül kiléphet az alagútból. A kivétel végzi a dolgát, és a név okozza a kárt.

Mielőtt bármit módosítana, az útvonal döntését olvassa, ne az interfészek listáját. Az alábbi parancsok a döntést írják ki, nem a leltárt. Futtassa őket attól a klienstől, amelyik elbukott.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Ha a keresés a végpont útvonalát a fizikai átjárón keresztül mutatja, a viselkedés helyes, és az admin oldal egyszerűen rossz útra kerül. Ez az a pont, ahol a névfeloldás lesz a javítás.

Adjon a szolgáltatásnak privát nevet

A szolgáltatásnak olyan névre van szüksége, amely az alagúton belül az átjáró címére oldódik, miközben megőrzi a tanúsítvány és hosztnév szemantikát, amelyet az alkalmazás elvár. Az adminisztrációs névhez privát zónarekord a szokásos válasz, és érintetlenül hagyja a szállítási nevet.

Ne irányítsa át a szállítási nevet a belső címre, mert a következő alagútépítés olyan címet próbálna elérni, amely csak egy alagúton belül létezik. Ez a hiba olyan VPN-t eredményez, amely pontosan egyszer működik.

Ellenőrizze mindkét címcsaládot is, mert egy hátrahagyott AAAA rekord olyan helyre küldheti a böngészőt, amelyet a privát terv soha nem fedett le.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Igazítsa a szabályzatot ahhoz, ahol a folyamat fut

Az átjárón figyelő natív folyamat a helyi bemeneti úton érhető el, ezért a bemeneti lánc és a socket kötése dönti el, hogy a kérés elfogadásra kerül-e. Az átirányítási szabályok és az IP-átirányítás nem késztetnek helyi figyelőt válaszadásra. Engedélyezze az alagút forrásait a bemeneti szabályzatban, és erősítse meg, hogy a folyamat olyan címhez van kötve, amelyet az alagút elér.

A hosztporton közzétett konténer más úton halad, mert a csomag célcím-fordításon esik át és továbbítódik. Ez a kérés a hoszt továbbítási szabályzatával és a Docker saját szabályaival találkozik, ezért működhet egy natív figyelő ugyanazon portot elutasító konténer mellett.

Az indítási sorrend mindkét esetben számít, mert az olyan címhez való kötés, amely csak az alagút felállása után jelenik meg, csendben meghiúsul a boot során.

Ellenőrizze a privát hozzáférést és az elutasított nyilvános utat

Küldjön friss nevesített kérést egy jogosult klienstől, az alkalmazás saját identitásellenőrzéseinek érintetlenül hagyásával. Utána próbálja ki ugyanazt a szolgáltatást az alagúton kívülről, és erősítse meg, hogy nem válaszol. A privát név kényelmi eszköz, nem korlátozás, és a nyilvános címhez még kötött figyelő még mindig ki van téve. Ezt az utolsó ellenőrzést hagyja ki a legtöbb átvizsgálás.

A kötéseket és a szűrő állapotát olvassa, ne a felhasználóknak adott hosztnevet. A kitettség a socket tulajdonsága, nem a névé. Ez a megkülönböztetés minden DNS-változást túlél.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

Amikor a belső kérés visszaadja az oldalt és a külső kérés időtúllépésbe fut, a szolgáltatásnak egy szándékos privát útja van, és a szállítás elérhető marad. Amikor a külső kérés még válaszol, a figyelőt vagy egy közzétett konténerbejegyzést szűkíteni kell, mielőtt bárki csak belsőnek nevezné a szolgáltatást.