Порталот ја хостира сопствената административна страница: внатрешна или јавна адреса

Административната страница одговара од телефон на мобилни податоци и истекува од преносен сметач поврзан со VPN. Ништо на тунелот не е расипано, бидејќи барањето никогаш не влегува во него. Името на домаќинот се разрешува на јавната адреса на порталот, а таа адреса е достапна само од надвор од тунелот што го завршува. Поправката значи да ѝ се даде на услугата приватен влез, наместо да се преместува надворешната крајна точка.

Страницата се вчитува од надвор, а не низ тунелот

Се споредуваат две различни барања. Од мобилни податоци прелистувачот директно стигнува до јавната адреса. Од внатрешноста на тунелот истото име се разрешува на истата јавна адреса, а пакетот сега мора да излезе низ тунелот за да стигне до адреса на сопствената далечна страна на тунелот. Исто име, иста адреса, две сосема различни позиции.

Рутата до одредиштето избира адреса, а не порта. Ништо во табелата за рутирање не знае дека портата 443 е за администрација, а портата 1194 е транспортот, па двете се третираат како исто одредиште.

Затоа страницата понекогаш работи, а понекогаш не, зависно од тоа кое име и која мрежа ги користел клиентот. Ова е проблем на патека, а не проблем на автентикација. Двата клиенти се автентицираат сосема добро.

Држете ја надворешната крајна точка достапна

Профилите со целосен тунел бараат рута-исклучок за крајната точка на VPN, а опцијата redirect-gateway на OpenVPN документира точно тоа: далечната крајна точка задржува рута низ претходно постоечкиот портал, за тунелот да не рутира во себе. Отстранете го тој исклучок и шифрираниот транспорт го следи тунелот, што ја завршува сесијата во јамка. Токму тој исклучок е причината зошто адресата на крајната точка останува достапна од внатрешноста на тунелот.

Последицата е дека јавната адреса останува достапна од клиентот, поради што барањето на прелистувачот до таа адреса може да го следи истиот исклучок и да излезе без да влезе во тунелот. Исклучокот ја врши својата работа, а името ја прави штетата.

Пред да промените нешто, читајте ја одлуката за рутата, а не списокот на интерфејси. Командите подолу ја печатат одлуката, а не инвентарот. Извршете ги од клиентот што не успеа.

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

Ако пребарувањето покаже рута на крајната точка низ физичкиот портал, однесувањето е точно и административната страница едноставно се испраќа по погрешна патека. Токму тука разрешувањето имиња станува поправка.

Дајте ѝ на услугата приватно име

На услугата ѝ треба име што внатре во тунелот се разрешува на адресата на порталот, а истовремено ја задржува семантиката на сертификатот и името на домаќинот што ја очекува апликацијата. Приватен запис во зоната за административното име е вообичаениот одговор, и тој го остава името на транспортот недопрено.

Не преусмерувајте го името на транспортот кон внатрешната адреса, бидејќи следното воспоставување на тунелот тогаш би се обидело да стигне до адреса што постои само внатре во тунел. Таа грешка создава VPN што работи точно еднаш.

Проверете ги и двете фамилии на адреси, бидејќи заостанат запис AAAA може да го испрати прелистувачот некаде каде приватниот план никогаш не допрел.

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/

Усогласете ја политиката со местото каде што работи процесот

До нативен процес што слуша на порталот се стигнува по патеката на локалниот влез, па влезниот синџир и врзувањето на сокетот одлучуваат дали барањето се прифаќа. Правилата за проследување и IP проследувањето не го тераат локалниот слушател да одговори. Дозволете ги изворите на тунелот во влезната политика и потврдете дека процесот е врзан за адреса што тунелот може да ја стигне.

Контејнер објавен на порта на домаќинот следи друга патека, бидејќи пакетот се преведува по одредиште и се проследува. Тоа барање се среќава со политиката за проследување на домаќинот и со сопствените правила на Docker, поради што работен нативен слушател може да постои покрај контејнер што ја одбива истата порта.

Редоследот на стартување е важен во двата случаи, бидејќи врзување за адреса што се појавува само откако тунелот ќе се крене тивко пропаѓа при подигање.

Проверете приватен пристап и одбиена јавна патека

Направете ново именувано барање од овластен клиент, со недопрени сопствени проверки за идентитет на апликацијата. Потоа пробајте ја истата услуга од надвор од тунелот и потврдете дека не одговара. Приватното име е погодност, а не ограничување, а слушател што сѐ уште е врзан за јавната адреса сѐ уште е изложен. Токму таа последна проверка повеќето прегледи ја прескокнуваат.

Читајте ги врзувањата и состојбата на филтерот, а не името на домаќинот што го добиле корисниците. Изложеноста е својство на сокетот, а не на името. Таа разлика преживува секоја промена на DNS.

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/

Кога внатрешното барање ја враќа страницата, а надворешното барање истекува, услугата има една намерна приватна патека и транспортот останува достапен. Кога надворешното барање сѐ уште одговара, слушателот или објавениот запис на контејнерот треба да се стесни пред некој да ја опише услугата како само внатрешна.