Tonnel aan, geen internet: waar die aanstuur ophou

Die kliënt maak verbinding, die tonnel dra ping na die poort, en niks anderkant dit antwoord nie. Daardie toestand is normaal vir ’n poort wat net ooit bedoel was om toegang tot beskermde netwerke te gee, en dit is ’n fout vir een wat as ’n voltonnel-uitgang geadverteer word. Voordat jy reëls verander, bevestig watter diens belowe is. Volg dan een enkele openbare versoek deur die vier plekke waar dit kan stop. Een versoek en een pakkie-opname beslis meer as ’n bladsy vol gissings.

Bevestig dat internet-uitgang ooit die ontwerp was

’n Split-tonnel-profiel stuur net die beskermde subnetwerke in die VPN in, so openbare blaaiwerk loop oor die plaaslike skakel en raak nooit die poort nie. ’n Voltonnel-profiel installeer ’n verstekroete in die tonnel, wat die poort verantwoordelik maak vir die hele pad. Albei is wettige ontwerpe, en om hulle te verwar lewer ’n foutverslag waar daar geen is nie. Lees die kliënt se aangekondigde roetes voordat jy enigiets anders toets, want die roetetabel beantwoord die vraag wat die kaartjie gewoonlik verkeerd kry.

Wat die kliënt installeer, is nie altyd wat die profiel bedoel nie. ’n Gepusde roete kan deur ’n plaaslike roete met ’n laer metriek oorheers word, en ’n kliënt wat sy LAN-roete behou terwyl hy ’n verstekroete byvoeg, gedra hom soos ’n split-tonnel vir daardie subnet.

Volg een enkele openbare versoek

Kies een enkele bestemming en volg dit van die kliënt na buite. Kontroleer op die kliënt of die pakkie werklik die tonnel kies en watter plaaslike adres dit as bron gebruik. Kontroleer dan die poort: kom die pakkie aan, en verlaat dit die openbare koppelvlak. Elkeen van daardie antwoorde verwyder ’n hele kategorie oorsaak.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

As die poort die pakkie nooit sien nie, is die kliëntroete of die tonnelkeuse verkeerd. As dit aankom en nie vertrek nie, is die probleem by die poort, en die oorblywende drie kontroles geld.

Kontroleer aanstuur, roete en vertaling

Die aanstuurriglyne wat saam met strongSwan kom, geld vir ’n poort van enige tonneltipe: die kern moet toegelaat word om pakkies tussen koppelvlakke te beweeg, en ’n bruikbare roete moet na die internet wys. Firewall-beleid moet dan die verkeer toelaat, en die bronadres moet een wees wat die openbare kant kan antwoord. ’n Privaat kliëntadres wat onveranderd na die internet aangestuur word, kry nooit ’n antwoord nie.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Bronvertaling is die gewone ontbrekende stuk. Daarmee herskryf die poort die kliënt se bron na sy openbare adres en hou die vloei dop; sonder dit het die antwoord nêrens om heen te gaan nie. Wolkeplatforms voeg ’n tweede grens by, waar die instansie se roetetabel of sekuriteitsgroep verkeer kan laat val wat die gasheer-firewall toelaat. Daardie grens is maklik om mis te kyk, want die gassisteem lyk van binne korrek opgestel.

Omgekeerde-pad-filtering op ’n asimmetriese opstelling kan ook geldige pakkies weggooi. Lees die teller op daardie reël eerder as om aan te neem dit is in orde, want ’n streng instelling op die openbare koppelvlak verwerp verkeer wat langs ’n ander pad aankom as wat die roetetabel voorspel.

Antwoordpad en oplosser is twee verskillende antwoorde

Let ook op die antwoord, nie net die versoek nie. As die versoek vertaal weg is en die antwoord na die vertaalde vloei terugkeer, werk aanstuur selfs wanneer die toepassing steeds misluk, en die volgende ondersoek hoort by die toepassing of by DNS.

’n Werf wat ’n HTTP-fout terugstuur, is bewys dat internet-aanstuur werk. ’n Naam wat nie oplos nie terwyl adrestoegang werk, is ’n oplosserprobleem, nie ’n NAT-probleem nie.

Toets ná ’n nou regstelling die kliënt weer, plus enige privaat hulpbron wat doelbewus beperk is. Om internettoegang toe te staan, moet nie stilweg toegang na elke netwerk wat aan die poort gekoppel is, verbreed nie.