Site-to-site-VPN virker bare én vei: to forskjellige feil

Område A når B, B når ikke A, og tunnelen ser fin ut i begge retninger. Før du rører tunnelen, må du avgjøre hvilken feil du egentlig har. En ny tilkobling startet på B som avvises, og et svar på en tilkobling startet på A som aldri kommer, gir lignende klager og helt forskjellige diagnoser. Det ene er et policy- eller ruteproblem på veien; det andre er et returvei- eller tilstandsproblem for trafikk som allerede var tillatt.

Den forskjellen avgjør hvilke kommandoer det er verdt å kjøre.

To feil som ser identiske ut

I det første tilfellet sender verten på B et SYN til A, og ingenting kommer tilbake. I det andre åpner verten på A en økt med hell, og svaret forsvinner på vei tilbake. Begge brukerne sier at forbindelsen er enveis, og begge beskriver en pakke som forsvant, så beskrivelsen alene kan ikke skille dem.

Spør hvilken side som startet forsøket som mislyktes. Den ene opplysningen fjerner halvparten av de mulige årsakene.

Kontroller deretter at testen brukte de samme vertene og den samme tjenesten hele tiden. En ping fra den ene siden og en fildelingsforbindelse fra den andre tester to forskjellige ting, og en diagnostikk fra gatewayen kan velge en tunneladresse som ingen brukertrafikk noen gang bruker.

Sak én: returveien mangler

En fjernserver som svarer over en annen standardgateway, kan motta forespørselen og rute svaret et annet sted. Brannmurer med tilstandssporing forkaster da det asymmetriske svaret fordi det ikke passer til en etablert strøm, noe som ser nøyaktig ut som en retning som aldri virket. Oversettelse legger til en annen variant: målet ser en oversatt kilde og svarer på den, så en regel skrevet for den opprinnelige adressen passer aldri.

Kontroller adressen målet faktisk ser etter oversettelsen, og returruten for den adressen i stedet for for det opprinnelige subnettet.

Sak to: policyen tillot det aldri

Det motsatte tilfellet er enklere og vanligere enn det ser ut: ett kontor skal bruke en sentral tjeneste og aldri starte tilkoblinger inn mot senteret. Den asymmetrien er en bevisst tilgangsbeslutning, og tunnelen virker som designet. Les tilgangspolicyen før du endrer noen tunnelinnstilling. Dokumentet, ikke pakkefangsten, sier hvilken retning som var ment. En fangst kan bare vise hva som skjedde, ikke hva som var tillatt.

Hvis toveis initiering virkelig er nødvendig, legg til tillatelsen for den konkrete tjenesten gjennom plattformens støttede regelsett. Å gjøre hvert subnett gjensidig klarert for å fikse én applikasjon gjør et smalt krav om til en bred tillatelse, og den byttehandelen blir sjelden gjennomgått etterpå.

Sammenlign før og etter på de samme vertene

Følg begge endene av samme forsøk, ikke to separate forsøk. Fang på gatewayen til verten som starter og på målet, og sammenlign deretter hva som kom inn, hva som gikk ut og hvilken adresse den fjerne siden så.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Hvis fangsten på målet viser forespørselen med en uventet kildeadresse, ligger svaret i oversettelse eller ruting, ikke i tunnelens sikkerhetspolicy. Hvis målet ikke viser noen forespørsel i det hele tatt, krysset pakken aldri den beskyttede veien.

Etter en korreksjon gjentar du den identiske testen fra den identiske verten og bekrefter at uvedkommende tilgang fortsatt avvises. En tunnelstatus på “established” støtter ikke noen av de to konklusjonene alene.