Gwekdraer huisves sy eie adminbladsy: binne- of publieke adres

'n Adminbladsy antwoord vanaf 'n selfoon op mobiele data en hou op reageer vanaf 'n skootrekenaar wat by die VPN aangesluit is. Niks aan die tonnel is stukkend nie, want die versoek gaan nooit daar in nie. Die gasheernaam los op na die gwekdraer se publieke adres, en daardie adres is net van buite die tonnel bereikbaar wat hy beëindig. Om dit reg te maak beteken om die diens 'n private inskrywing te gee eerder as om die buitenste eindpunt rond te skuif.

Die bladsy laai van buite en nie deur die tonnel nie

Twee verskillende versoeke word vergelyk. Vanaf mobiele data bereik die blaaier die publieke adres direk. Van binne die tonnel los dieselfde naam op na dieselfde publieke adres, en die pakkie moet nou deur die tonnel uitgaan om 'n adres aan die tonnel se eie ver kant te bereik. Dieselfde naam, dieselfde adres, twee baie verskillende posisies.

'n Bestemmingsroete kies 'n adres, nie 'n poort nie. Niks in die roetertabel weet dat poort 443 vir administrasie is en poort 1194 die transport is nie, so albei word as dieselfde bestemming behandel.

Dis hoekom die bladsy soms werk en soms nie, afhangend van watter naam en watter netwerk die kliënt gebruik het. Dit is 'n padprobleem eerder as 'n verifikasieprobleem. Albei kliënte verifieer heeltemal goed.

Hou die buitenste eindpunt bereikbaar

Voltonnelprofiele het 'n uitsonderingsroete vir die VPN-eindpunt nodig, en OpenVPN se redirect-gateway-opsie dokumenteer presies dit: die afgeleë eindpunt hou 'n roete deur die bestaande gwekdraer sodat die tonnel nie in homself in roeteer nie. Verwyder daardie uitsondering en die versleutelde transport volg die tonnel, wat die sessie in 'n lus beëindig. Daardie uitsondering is hoekom die eindpuntadres van binne die tonnel bereikbaar bly.

Die gevolg is dat die publieke adres vanaf die kliënt bereikbaar bly, wat ook verduidelik hoekom 'n blaaierversoek na daardie adres dieselfde uitsondering kan volg en kan uitgaan sonder om die tonnel binne te gaan. Die uitsondering doen sy werk, en die naam doen die skade.

Lees die roetebesluit eerder as die koppelvlaklys voordat jy enigiets verander. Die opdragte hieronder druk die besluit eerder as die inventaris. Voer hulle uit vanaf die kliënt wat gefaal het.

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

As die opsoek die eindpuntroete deur die fisiese gwekdraer wys, is die gedrag korrek en word die adminbladsy bloot op die verkeerde pad gestuur. Dit is die punt waar naambepaling die oplossing word.

Gee die diens 'n private naam

Die diens het 'n naam nodig wat na die gwekdraer se adres binne die tonnel oplos, terwyl die sertifikaat- en gasheernaamsemantiek behou word wat die toepassing verwag. 'n Private sone-inskrywing vir die administrasienaam is die gewone antwoord, en dit laat die transportnaam ongemoeid.

Moenie die transportnaam na die binne-adres herwys nie, want die volgende tonnelopbou sou dan probeer om 'n adres te bereik wat net binne 'n tonnel bestaan. Daardie fout lewer 'n VPN op wat presies een keer werk.

Kontroleer ook albei adresfamilies, want 'n AAAA-rekord wat agtergelaat is, kan die blaaier stuur na 'n plek wat die private plan nooit gedek het nie.

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/

Pas die beleid aan by waar die proses loop

'n Inheemse proses wat op die gwekdraer luister, word deur die plaaslike-invoerpad bereik, so die invoerketting en die sokketbinding bepaal of die versoek aanvaar word. Deurstuur-reëls en IP-deurstuur laat nie 'n plaaslike luisteraar antwoord nie. Laat die tonnelbronne in die invoerbeleid toe en bevestig dat die proses aan 'n adres gebind is wat die tonnel kan bereik.

'n Houer wat op 'n gasheerpoort gepubliseer is, volg 'n ander pad, want die pakkie word op sy bestemming vertaal en deurgestuur. Daardie versoek ontmoet die gasheer se deurstuurbeleid en Docker se eie reëls, en daarom kan 'n werkende inheemse luisteraar saam met 'n houer bestaan wat dieselfde poort weier.

Beginvolgorde maak in albei gevalle saak, want 'n binding aan 'n adres wat eers verskyn nadat die tonnel opkom, faal stilweg by die opstart.

Kontroleer private toegang en 'n geweierde publieke pad

Maak 'n nuwe genoemde versoek vanaf 'n gemagtigde kliënt met die toepassing se eie identiteitskontroles ongeskonde. Probeer dan dieselfde diens van buite die tonnel en bevestig dat dit nie antwoord nie. 'n Private naam is 'n gerief eerder as 'n beperking, en 'n luisteraar wat steeds aan die publieke adres gebind is, is steeds blootgestel. Daardie laaste kontrole is die een wat die meeste hersienings oorslaan.

Lees die bindings en die filtertoestand eerder as die gasheernaam wat gebruikers gekry het. Blootstelling is 'n eienskap van die sokket eerder as van die naam. Daardie onderskeid oorleef elke DNS-verandering.

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/

Wanneer die binne-versoek die bladsy teruggee en die buite-versoek uit tyd loop, het die diens een doelbewuste private pad en bly die transport bereikbaar. Wanneer die buite-versoek steeds antwoord, moet die luisteraar of 'n gepubliseerde houerinskrywing vernou word voordat iemand die diens as slegs-intern beskryf.