Site-to-site-VPN verkar berre éin veg: to ulike feil

Område A når B, B når ikkje A, og tunnelen ser fin ut i begge retningar. Før du rører tunnelen, må du avgjere kva feil du eigentleg har. Ei ny tilkopling starta på B som vert avvist, og eit svar på ei tilkopling starta på A som aldri kjem, gir liknande klager og heilt ulike diagnosar. Det eine er eit policy- eller ruteproblem på vegen; det andre er eit returveg- eller tilstandsproblem for trafikk som allereie var tillaten.

Den skilnaden avgjer kva kommandoar det er verdt å køyre.

To feil som ser identiske ut

I det første tilfellet sender verten på B eit SYN til A, og ingenting kjem tilbake. I det andre opnar verten på A ei økt med hell, og svaret forsvinn på veg tilbake. Begge brukarane seier at sambandet er einvegskøyrt, og begge skildrar ein pakke som forsvann, så skildringa åleine kan ikkje skilje dei.

Spør kva side som starta forsøket som mislukkast. Den eine opplysninga fjernar halvparten av dei moglege årsakene.

Kontroller deretter at testen brukte dei same vertane og den same tenesta heile tida. Ein ping frå den eine sida og ei fildelingskopling frå den andre testar to ulike ting, og ein diagnostikk frå gatewayen kan velje ei tunneladresse som ingen brukartrafikk nokon gong brukar.

Sak éin: returvegen manglar

Ein fjernserver som svarar over ein annan standardgateway, kan ta imot førespurnaden og rute svaret ein annan stad. Brannmurar med tilstandssporing kastar då det asymmetriske svaret fordi det ikkje passar til ein etablert straum, noko som ser nøyaktig ut som ei retning som aldri verka. Omsetjing legg til ein annan variant: målet ser ei omsett kjelde og svarar på henne, så ein regel skriven for den opphavlege adressa passar aldri.

Kontroller adressa målet faktisk ser etter omsetjinga, og returruta for den adressa i staden for for det opphavlege subnettet.

Sak to: policyen tillét det aldri

Det motsette tilfellet er enklare og vanlegare enn det ser ut: eitt kontor skal bruke ei sentral teneste og aldri starte tilkoplingar inn mot senteret. Den asymmetrien er ei medviten tilgangsavgjerd, og tunnelen verkar som designa. Les tilgangspolicyen før du endrar noka tunnelinnstilling. Dokumentet, ikkje pakkefangsten, seier kva retning som var meint. Ein fangst kan berre vise kva som skjedde, ikkje kva som var tillate.

Viss toveg-initiering verkeleg er naudsynt, legg til løyvet for den konkrete tenesta gjennom det støtta regelssettet til plattforma. Å gjere kvart subnett gjensidig klarert for å fikse éin applikasjon gjer eit smalt krav om til eit breitt løyve, og den byttehandelen vert sjeldan gjennomgått etterpå.

Samanlikn før og etter på dei same vertane

Følg begge endane av same forsøket, ikkje to separate forsøk. Fang på gatewayen til verten som startar og på målet, og samanlikn deretter kva som kom inn, kva som gjekk ut og kva adresse den fjerne sida såg.

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

Viss fangsten på målet viser førespurnaden med ei uventa kjeldeadresse, ligg svaret i omsetjing eller ruting, ikkje i sikkerheitspolicyen til tunnelen. Viss målet ikkje viser nokon førespurnad i det heile, kryssa pakken aldri den verna vegen.

Etter ei korreksjon gjer du den identiske testen på nytt frå den identiske verten og stadfestar at uvedkommande tilgang framleis vert avvist. Ein tunnelstatus på “established” støttar ingen av dei to konklusjonane åleine.