VPN verbind maar firewall blokkeer steeds: hoe om te bepaal watter een

Die kliënt sê verbind, die hulpbron weier steeds, en die gewone volgende stap is om iets af te skakel. Beide kontroles in daardie sin doen verskillende take: die VPN bou 'n pad vir gedekte verkeer, en 'n firewall besluit per verbinding of die verkeer mag deur. 'n Werkende tonnel met 'n weieragtige beleid lyk presies soos 'n stukkende tonnel uit die gebruiker se stoel, so die taak is om te vind watter laag antwoord. Hier is die orde wat ek volg, met die lesing wat vir jou sê om te stop.

Skei die pad van die beleid

Begin met die vorm van die fout, want dit is gratis inligting. As 'n pakket in die stille weggegooi word, volg 'n tydsverloop: die kliënt probeer weer, niks kom terug nie, en die opdrag hang tot dit tou opgooi. 'n Verwerping lewer 'n weiering of 'n herstel: iets het geantwoord en nee gesê. 'n Diens wat nie luister nie, weier op die gasheer self, met geen firewall betrokke nie.

Daardie drie uitkomste wys na verskillende lae. Tydsverloop beteken 'n beleid êrens laat dit stilweg val, of die roete verlaat nooit die masjien nie. Geweier beteken jy het die gasheer bereik en sy stapel of sy gasheer-firewall het geweier. Niks hoegenaamd, met die tonnel-koppelvlak op en geen roete na die bestemming nie, beteken die pad is verkeerd en geen firewall-reël sal dit regmaak nie.

Lees die pad in een slag

Bevestig dat die tonnel die bestemming dek voordat jy na 'n enkele reël kyk. 'n Gesplete tonnel wat net die kantoor-subnet dra, sal nie 'n versoek na 'n ander reeks stuur nie, en die fout lyk dan soos 'n firewall-blok wat nie een is nie:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Die roete-uitvoer noem die koppelvlak waarmee die pakket sal vertrek en die bronadres wat dit sal dra. As daardie koppelvlak jou fisiese NIC eerder as die tonnel is, is die probleem roetering of die tonnel se toegelate reekse, en dit hoort by die VPN-konfigurasie eerder as by die firewall.

Een VPN-spesifieke lokval verdien sy eie toets. In WireGuard is 'n eweknie se AllowedIPs beide 'n roete en 'n kriptografiese filter: 'n pakket waarvan die bronadres nie by die eweknie se toegelate stel pas nie, word laat val voordat enige firewall-reël geraadpleeg word. Dus kan 'n heeltemal korrekte gasheer-firewall agter 'n stil weggegooi sit wat soos 'n beleid lyk, en die oplossing is 'n sleutel-konfigurasie-reël eerder as 'n reël.

Lees die beleid op die laag wat antwoord

Sodra die pad reg is, stap die beleid van die gasheer uitwaarts en let op die een laag waarvan die tellers beweeg:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Die luisterende sok antwoord 'n ander vraag as die reëls. As niks op die poort luister nie, word die verbinding deur die kern geweier en geen inkomende reël is relevant nie. As die sok bestaan en die verbinding verstryk vanaf 'n afgeleë kliënt, gebeur 'n druppeling êrens op die pad, en die reël-tellers sê vir jou of dit hier gebeur.

Skakel aanmelding aan vir die profiel of ketting wat jy vermoed eerder as om van buite af te raai. 'n Enkele aangetekende druppeling wat die bron, bestemming en poort noem, identifiseer die laag en die reël, en dit bewys ook dat die pakket aangekom het, wat geen hoeveelheid kliënt-kant toetsing kan vasstel nie.

Lees die gateway-besluit wanneer die tonnel daar eindig

Op 'n werf-tot-werf- of afgeleë-toegang-gateway verifieer die VPN 'n gebruiker en magtig die beleid 'n hulpbron, en dit is aparte toekennings. 'n Gebruiker wat in die tonnel toegelaat word, word nie outomaties na elke interne gasheer toegelaat nie, en die weiering kom dikwels van 'n deurstuur-reël terwyl die tonnel self gesond is. Dieselfde skeiding verskyn in IPsec, waar die sekuriteitsbeleid wat verkeer kies, verskil van die filter wat dit toelaat, en daarom word die twee gedokumenteer as verskillende meganismes in RFC 4301.

Kontroleer die terugpad net so sorgvuldig as die uitgaande pad. Toestandbeheer vereis dat die antwoord gesien word, so asimmetriese roetering deur die tonnel in een rigting en om dit in die ander rigting veroorsaak druppelinge wat lukraak lyk en net van sommige kliënte af reproduseer. As verkeer die gateway bereik en stop, lees die deurstuur-reël en die terugroete saam voordat jy enigiets verbreed.

Die gateway is ook waar 'n NAT- of maskerade-reël die werklike bron kan wegsteek. As interne gashere die gateway-adres sien in plaas van die kliënt, sal hul gasheer-firewall-reëls wat by die kliënt-poel pas, nooit pas nie, en die oplossing hoort op die gateway eerder as op elke bediener.

Verander die engste laag, en verifieer dan

Weerstaan die breë herstel. Om die gasheer-firewall af te skakel, 'n reël by te voeg wat enige verkeer toelaat, of elke koppelvlak in 'n vertroude profiel te dwing, verwyder elkeen die kontrole wat sy werk gedoen het, en die verandering oorleef die voorval. 'n Reël wat op die bronreeks en die betrokke poort beperk is, is makliker om na te gaan, makliker om te verwyder, en laat die res van die masjien se beleid ongeskonde.

Verifieer met dieselfde toets wat gefaal het, vanaf dieselfde kliënt, en dan nog een keer ná 'n herverbinding, want 'n reël wat voor die tonnel weer onderhandel pas, kan daarna ophou pas:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Voordat jy dit afsluit:

• Die roete na die bestemming verlaat via die tonnel-koppelvlak, en die bronadres pas by wat die beleid verwag.
• Iets luister op die poort, en die weiering of tydsverloop word aan 'n genoemde reël toegeskryf eerder as aangeneem.
• Die gateway stuur in beide rigtings deur, en die bestemming sien die bron waarvoor jou reëls geskryf is.
• Geen kontrole is afgeskakel om die toets te laat slaag nie, en die verandering wat jy gemaak het, noem een bronreeks en een poort.