De gateway host syn eigen admin-side: innerlike of iepenbiere adres

In admin-side antwurdet fan in telefoan op mobile data en rint ôf fan in laptop dy't by de VPN oansletten is. Oan de tunnel is neat stikken, want it fersyk komt der nea yn. De hostnamme löst op nei it iepenbiere adres fan de gateway, en dat adres is allinnich berikber fan bûten de tunnel dy't it einiget. Dat reparearje betsjut de tsjinst in privee yngong jaan, ynstee fan it bûtenste einpunt te ferpleatsen.

De side laadt fan bûten en net troch de tunnel

Twa ferskillende fersiken wurde ferlike. Fan mobile data berikt de browser it iepenbiere adres direkt. Fan binnen de tunnel löst deselde namme op nei itselde iepenbiere adres, en it pakket moat no troch de tunnel nei bûten om in adres oan de eigen fiere kant fan de tunnel te berikken. Deselde namme, itselde adres, twa hiel ferskillende posysjes.

In bestimmingsrûte kiest in adres, net in poarte. Neat yn 'e rûtetabel wit dat poarte 443 foar behear is en poarte 1194 it transport, dus beide wurde as deselde bestimming behannele.

Dêrom wurket de side soms en soms net, ôfhinklik fan hokker namme en hokker netwurk de klant brûkte. It is in paadprobleem en gjin autentikaasjeprobleem. Beide klanten autentisearje prima.

Hâld it bûtenste einpunt berikber

Fol-tunnelprofylen hawwe in útsûnderingsrûte nedich foar it VPN-einpunt, en de redirect-gateway-opsje fan OpenVPN dokumintearret krekt dat: it fiere einpunt hâldt in rûte troch de al besteande gateway, sadat de tunnel net yn himsels rûtet. Helje dy útsûndering fuort en it fersifere transport folget de tunnel, wat de sesje yn in lus einiget. Dy útsûndering is de reden dat it einpuntadres fan binnen de tunnel berikber bliuwt.

It gefolch is dat it iepenbiere adres fan de klant ôf berikber bliuwt, wat ek ferklearret wêrom't in browserfersyk nei dat adres deselde útsûndering folgje kin en nei bûten gean kin sûnder de tunnel yn te kommen. De útsûndering docht syn wurk, en de namme docht de skea.

Lês de rûtebeslissing ynstee fan 'e ynterface-list foar't jo wat feroarje. De kommando's hjirûnder printsje de beslissing ynstee fan 'e ynventaris. Rin se fan de klant dy't mislearre.

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

As de syktocht de einpuntrûte troch de fysike gateway sjen lit, is it gedrach korrekt en wurdt de admin-side gewoan oer it ferkearde paad stjoerd. Dat is it punt dêr't namme-oplossing de fix wurdt.

Jou de tsjinst in privee namme

De tsjinst hat in namme nedich dy't binnen de tunnel nei it adres fan 'e gateway oplost, wylst de sertifikaat- en hostnamme-semantyk beholden bliuwt dy't de applikaasje ferwachtet. In privee sône-record foar de behearnamme is it gewoane antwurd, en it lit de transportnamme ûnoantaast.

Wizigje de transportnamme net nei it innerlike adres, want de folgjende tunnelopbou soe dan besykje in adres te berikken dat allinnich binnen in tunnel bestiet. Dy flater jout in VPN dy't krekt ien kear wurket.

Kontrolearje ek beide adresfamyljes, want in efterlitten AAAA-record kin de browser earne hinne stjoere dêr't it privee plan nea oer dekte.

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 it belied oan by wêr't it proses rint

In native proses dat op 'e gateway harket is berikber fia it paad fan lokale ynfier, dus de ynfierkeatling en de socket-binding beslisse oft it fersyk akseptearre wurdt. Trochstjoerregels en IP-trochstjoering krije in lokale listener net oan it antwurdzjen. Stean de boarnen fan 'e tunnel ta yn it ynfierbelied en befêstigje dat it proses bûn is oan in adres dat de tunnel berikke kin.

In container dy't op in hostpoarte publisearre is folget in oar paad, want it pakket wurdt op bestimming oerset en trochstjoerd. Dat fersyk moetet it trochstjoerbelied fan 'e host en Docker syn eigen regels, en dêrom kin in wurkjende native listener neist in container bestean dy't deselde poarte wegeret.

De startfolchoarder is yn beide gefallen wichtich, want in binding oan in adres dat pas ferskynt nei't de tunnel omheech komt, mislearret stil by it opstarten.

Kontrolearje privee tagong en in wegere iepenbier paad

Doch in nij neamd fersyk fan in autorisearre klant mei de eigen identiteitskontrôles fan 'e applikaasje yntakt. Probearje dêrnei deselde tsjinst fan bûten de tunnel en befêstigje dat it net antwurdet. In privee namme is in gemak en gjin beheining, en in listener dy't noch oan it iepenbiere adres bûn is, is noch bleatsteld. Dy lêste kontrôle is dejinge dy't de measte resinsjes oerslaan.

Lês de bindingen en de filterstatus ynstee fan 'e hostnamme dy't brûkers krigen. Bleatstelling is in eigenskip fan 'e socket en net fan 'e namme. Dat ûnderskied oerlibbet elke DNS-feroaring.

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/

As it innerlike fersyk de side weromjout en it bûtenste fersyk rint ôf, hat de tsjinst ien bewust privee paad en bliuwt it transport berikber. As it bûtenste fersyk noch antwurdet, moat de listener of in publisearre container-yngong ferfine wurde foar't immen de tsjinst as allinnich-yntern beskriuwt.