Miért kell az URL-nek 80-as vagy 443-as porton belépés, és nem 45000-esen

Írjon be egy gazdagépnevet a böngészőbe, és a séma dönti el a célportot: 80 http-hez, 443 https-hez. A DNS-válaszban semmi sem írja ezt felül, és a gépén lévő egyetlen továbbítási szabály sem tud hallgatót kitalálni a szolgáltató peremén. Amikor egy VPN-szolgáltató magas nyilvános portot ad, például 45000-et, a kifejezett URL működik, a tiszta pedig nem. A rés a belépési pontnál van, nem az alkalmazáson belül.

Járja végig egyszer a böngészőtől a folyamatig vezető utat, és a három közzétételi lehetőség megszűnik rejtélyesnek tűnni.

Nézze meg, hová megy valójában a kérés

A böngésző feloldja a nevet egy címre, majd csatlakozik ehhez a címhez a séma alapértelmezett portján, kivéve ha az URL másikat nevez meg. A szolgáltató pereme dönti el, mi történik a beérkező kapcsolattal. Ha a továbbítási táblája csak a 45000-et rendeli a belső címéhez, a 80-as portra irányuló kapcsolatnak nincs hová mennie, és elutasítják vagy eldobják, mielőtt a gépe egyáltalán részt venne.

Ez az elutasítás a peremen történik, ezért az alkalmazás naplói semmit sem mutatnak. A naplók hiánya arról tanúskodik, hol állt meg a csomag, nem arról, hogy az alkalmazás hibás.

Miért nem tudja egy helyi szabály megjavítani a peremet

Az átirányítás vagy a DNAT-szabály az alkalmazás gazdagépén a már megérkezett csomagokra hat. A szolgáltatónál a 80-as portra küldött csomagok soha nem érkeznek meg, így a szabály soha nem értékelődik ki. Ez a legtöbbször elvesztegetett óra az egész problémában.

A DNS sem tudja hordozni a portot. HTTP-specifikáció határozza meg a séma alapértelmezéseit, és az A vagy AAAA rekord címet ad vissza, míg a CNAME másik nevet. A böngésző továbbra is hozzáfűzi a séma portját, ezért csak az URL-ben szereplő kifejezett port változtatja meg a célt.

Első lehetőség: a kifejezett port megtartása

Gyakran a helyes válasz a nem látványos. Tegye közzé a teljes URL-t a porttal, fejezze be a TLS-t egy olyan belépésen, amely támogatja, és győződjön meg arról, hogy minden generált hivatkozás megtartja ugyanazt az eredetet. Egy kis, ellenőrzött közönség számára ez teljes, és nem kerül semmibe egy látható portszámon kívül.

Ellenőrizze az átirányításokat és a sütik hatókörét, amíg ott van, mert a backend, amely a saját gazdagépnevét írja egy Location fejlécbe, semmissé teszi a megoldást.

Második lehetőség: valódi belépés az alapértelmezett porton

Egyes szolgáltatók és tárhelymegoldások dokumentált szolgáltatásként továbbítják a 80-at és a 443-at megosztott vagy dedikált címen. Kérdezze meg, mi van valójában benne, ahelyett hogy feltételezné, hogy egy nyilvános kilépési cím tetszőleges bejövő portokat jelent. A dedikált kimenő cím semmit sem mond a bejövő továbbításról.

Erősítse meg írásban a tulajdonjogot és az elérhetőséget, beleértve azt is, mi történik a belépéssel, amikor az alagút másik címmel újra csatlakozik. Az alagúttal együtt mozgó belépés olyan kieséseket okoz, amelyek DNS-hibáknak tűnnek.

Harmadik lehetőség: tegyen frontendet elé

Egy elérhető címen futó fordított proxy képes a 443-on figyelni és a TLS-t lezárni és külön kapcsolatot nyitni a backend felé a VPN-en keresztül. A látogatók a frontend nevét és alapértelmezett portját látják, miközben a frontend az ön nevében beszél a backend magas portjával. Ez azért működik, mert az architektúrát változtatja meg ahelyett, hogy a belépési ponttal harcolna. A backendnek ekkor egyáltalán nincs szüksége bejövő portra a nyilvános interneten.

Az is megváltozik, amit üzemeltet. A frontend birtokolja a nyilvános TLS-t, a hozzáférési szabályzatot, a naplókat és az elérhetőséget, és korlátoznia kell a backend kiválasztását a tervezett szolgáltatásra. Ha a frontend és a backend közötti ugrás HTTPS-t használ, tartsa meg a tanúsítvány-ellenőrzést azon az ugráson.

Tartson meg egy eredetet

A frontend nyilvános gazdagépneve, sémája és portja alkotja azt az eredetet, amelyet a látogatók használnak, ezért állítsa be az alkalmazás külső URL-jét, az átirányításokat és a sütiket erre az eredetre. Küldje el az eredeti gazdagépet és a továbbított sémát, ha az alkalmazás abszolút hivatkozásokat épít. Az a válasz, amely a felhasználókat privát névre vagy magas portra küldi vissza, semmissé teszi a most felépített tiszta belépést.

Ezután a közönségre gondolva döntsön. Egy rövid URL indokolhatja a kezelt frontendet, és nem érdemes véletlenül nyilvánossá tenni egy csak VPN-re szánt privát szolgáltatást.