Tinklų sietuvas talpina savo administravimo puslapį: vidinis ar viešasis adresas

Administravimo puslapis atsako iš telefono mobiliaisiais duomenimis, o iš nešiojamojo kompiuterio, prisijungusio prie VPN, pasibaigia laikas. Tunelyje niekas nesugedę, nes užklausa niekada į jį nepatenka. Prieglobos vardas išsprendžiamas į tinklų sietuvo viešąjį adresą, o tas adresas pasiekiamas tik iš išorės to tunelio, kurį jis užbaigia. Tai sutaisyti reiškia suteikti paslaugai vidinę įėjimo vietą, o ne perkelti išorinį galinį tašką.

Puslapis įkeliamas iš išorės, o ne per tunelį

Lyginamos dvi skirtingos užklausos. Mobiliaisiais duomenimis naršyklė pasiekia viešąjį adresą tiesiogiai. Iš tunelio vidaus tas pats vardas išsprendžiamas į tą patį viešąjį adresą, o paketas dabar turi išeiti per tunelį, kad pasiektų adresą savoje tolimoje tunelio pusėje. Tas pats vardas, tas pats adresas, dvi labai skirtingos pozicijos.

Paskirties maršrutas pasirenka adresą, o ne prievadą. Maršrutizavimo lentelėje niekas nežino, kad 443 prievadas skirtas administravimui, o 1194 prievadas yra transportas, todėl abu traktuojami kaip ta pati paskirtis.

Todėl puslapis kartais veikia, o kartais ne, priklausomai nuo to, kokį vardą ir kokį tinklą naudojo klientas. Tai kelio problema, o ne autentifikavimo problema. Abiejų klientų autentifikavimas veikia puikiai.

Išlaikykite išorinį galinį tašką pasiekiamą

Viso tunelio profiliams reikia išimties maršruto VPN galiniam taškui, ir OpenVPN parinktis redirect-gateway dokumentuoja būtent tai: nuotolinis galinis taškas išlaiko maršrutą per jau esamą tinklų sietuvą, kad tunelis nesukurtų maršruto į save. Pašalinkite tą išimtį ir šifruotas transportas seks tunelį, o tai užbaigs sesiją kilpoje. Būtent dėl šios išimties galinio taško adresas lieka pasiekiamas iš tunelio vidaus.

Pasekmė ta, kad viešasis adresas lieka pasiekiamas iš kliento, todėl naršyklės užklausa į tą adresą gali sekti ta pačia išimtimi ir išeiti neįėjusi į tunelį. Išimtis atlieka savo darbą, o žalą daro vardas.

Prieš ką nors keisdami skaitykite maršruto sprendimą, o ne sąsajų sąrašą. Toliau pateiktos komandos spausdina sprendimą, o ne inventorių. Vykdykite jas iš kliento, kuris nepavyko.

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

Jei paieška rodo galinio taško maršrutą per fizinį tinklų sietuvą, elgsena yra teisinga, o administravimo puslapis tiesiog siunčiamas neteisingu keliu. Būtent čia vardų sprendimas tampa pataisymu.

Suteikite paslaugai privatų vardą

Paslaugai reikia vardo, kuris tunelio viduje išsprendžiamas į tinklų sietuvo adresą, kartu išlaikant sertifikato ir prieglobos vardo semantiką, kurios tikisi programa. Privatus zonos įrašas administravimo vardui yra įprastas atsakymas, ir jis palieka transporto vardą nepaliestą.

Nenukreipkite transporto vardo į vidinį adresą, nes kitas tunelio sukūrimas tada bandytų pasiekti adresą, kuris egzistuoja tik tunelio viduje. Ši klaida sukuria VPN, kuris veikia lygiai vieną kartą.

Patikrinkite ir abi adresų šeimas, nes paliktas AAAA įrašas gali nusiųsti naršyklę ten, kur privatus planas niekada neapėmė.

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/

Suderinkite politiką su vieta, kurioje vyksta procesas

Prie vietinio proceso, klausančio tinklų sietuvo, patenkama vietinio įėjimo keliu, todėl įėjimo grandinė ir lizdo susiejimas nusprendžia, ar užklausa priimama. Persiuntimo taisyklės ir IP persiuntimas nepriverčia vietinio klausytojo atsakyti. Leiskite tunelio šaltinius įėjimo politikoje ir patvirtinkite, kad procesas susietas su adresu, kurį tunelis gali pasiekti.

Konteineris, paskelbtas prieglobos prievade, eina kitu keliu, nes paketas išverčiamas pagal paskirtį ir persiunčiamas. Ši užklausa susiduria su prieglobos persiuntimo politika ir Docker taisyklėmis, todėl veikiantis vietinis klausytojas gali egzistuoti kartu su konteineriu, kuris atsisako to paties prievado.

Paleidimo tvarka svarbi abiem atvejais, nes susiejimas su adresu, kuris atsiranda tik pakilus tuneliui, įkrovimo metu tyliai nepavyksta.

Patikrinkite privatų priėjimą ir atmestą viešąjį kelią

Atlikite naują įvardytą užklausą iš įgalioto kliento, palikdami pačios programos tapatybės patikras nepažeistas. Tada išbandykite tą pačią paslaugą iš tunelio išorės ir patvirtinkite, kad ji neatsako. Privatus vardas yra patogumas, o ne apribojimas, o klausytojas, vis dar susietas su viešuoju adresu, vis dar yra atviras. Būtent šią paskutinę patikrą dauguma apžvalgų praleidžia.

Skaitykite susiejimus ir filtro būseną, o ne prieglobos vardą, kurį gavo naudotojai. Atvirumas yra lizdo savybė, o ne vardo. Šis skirtumas išlieka po kiekvieno DNS pakeitimo.

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/

Kai vidinė užklausa grąžina puslapį, o išorinei užklausai pasibaigia laikas, paslauga turi vieną sąmoningą privatų kelią ir transportas lieka pasiekiamas. Kai išorinė užklausa vis dar atsako, klausytoją arba paskelbtą konteinerio įrašą reikia susiaurinti, kol kas nors paslaugą apibūdins kaip tik vidinę.