Site-to-site-VPN virker kun én vej: to forskellige fejl
Et svar der aldrig kommer tilbage, og en forbindelse der blev afvist, er to forskellige fejl. Sammenlign politik, routing og den kildeadresse, som serveren faktisk ser.
Lokation A kan nå B, B kan ikke nå A, og tunnelen ser fin ud i begge retninger. Før du rører tunnelen, skal du afgøre, hvilken fejl du egentlig har. En ny forbindelse startet på B, som afvises, og et svar på en forbindelse startet på A, som aldrig kommer, giver lignende klager og helt forskellige diagnoser. Det ene er et politik- eller ruteproblem på vejen; det andet er et returvejs- eller tilstandsproblem for trafik, der allerede var tilladt.
Den forskel afgør, hvilke kommandoer det er værd at køre.
To fejl der ser identiske ud
I det første tilfælde sender B-værten et SYN til A, og der kommer intet tilbage. I det andet åbner A-værten en session med succes, og svaret forsvinder på vej tilbage. Begge brugere siger, at forbindelsen er envejs, og begge beskriver en pakke, der forsvandt, så beskrivelsen alene kan ikke skille dem.
Spørg, hvilken side der startede det mislykkede forsøg. Den ene kendsgerning fjerner halvdelen af de mulige årsager.
Kontroller derefter, at testen hele tiden brugte de samme værter og den samme tjeneste. Et ping fra den ene side og en fildelingsforbindelse fra den anden tester to forskellige ting, og en diagnosticering fra gatewayen kan vælge en tunneladresse, som ingen brugertrafik nogensinde bruger.
Sag et: returvejen mangler
En fjernserver, der svarer over en anden standardgateway, kan modtage anmodningen og rute svaret et andet sted hen. Stateful firewalls kasserer derefter det asymmetriske svar, fordi det ikke matcher en etableret strøm, hvilket ser præcis ud som en retning, der aldrig virkede. Oversættelse tilføjer en anden version: destinationen ser en oversat kilde og svarer på den, så en regel skrevet til den oprindelige adresse matcher aldrig.
Kontroller den adresse, destinationen faktisk ser efter oversættelsen, og returruten for den adresse i stedet for for det oprindelige subnet.
Sag to: politikken tillod det aldrig
Det modsatte tilfælde er enklere og mere almindeligt, end det ser ud: et kontor skal bruge en central tjeneste og aldrig starte forbindelser ind i centret. Den asymmetri er en bevidst adgangsbeslutning, og tunnelen fungerer som designet. Læs adgangspolitikken, før du ændrer nogen tunnelindstilling. Dokumentet, ikke pakkefangsten, angiver, hvilken retning der var hensigten. En fangst kan kun vise, hvad der skete, ikke hvad der var tilladt.
Hvis tovejs initiering virkelig er nødvendig, skal du tilføje den specifikke tjenestetilladelse via platformens understøttede regelsæt. At gøre hvert subnet gensidigt betroet for at rette én applikation gør et snævert krav til en bred tilladelse, og den byttehandel bliver sjældent gennemgået bagefter.
Sammenlign før og efter på de samme værter
Overvåg begge ender af samme forsøg, ikke to separate forsøg. Fang på den startende værts gateway og på destinationen, og sammenlign derefter, hvad der kom ind, hvad der gik ud, og hvilken adresse den fjerne side 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 ved destinationen viser anmodningen med en uventet kildeadresse, ligger svaret i oversættelse eller routing, ikke i tunnelens sikkerhedspolitik. Hvis destinationen slet ikke viser nogen anmodning, krydsede pakken aldrig den beskyttede vej.
Efter en rettelse gentages den identiske test fra den identiske vært, og bekræft at uvedkommende adgang stadig afvises. En tunnelstatus på “established” understøtter ikke nogen af de to konklusioner alene.