Veröffentlichen eines internen Dienstes über ein ASA-Site-to-Site-VPN

Einen Dienst zu veröffentlichen, der hinter einem Site-to-Site-VPN lebt, ist eine Aufgabe mit fünf Fehlerpunkten, und sie scheitern in fester Reihenfolge. Der Tunnel kommt hoch, die Übersetzung passt, die Filiale antwortet, und die Antwort kommt über denselben Weg zurück. Wenn eines davon falsch ist, zeigt der Browser dasselbe: eine Verbindung, die hängt oder zurückgesetzt wird. Arbeiten Sie die Liste von oben nach unten ab und stoppen Sie bei der ersten Prüfung, die fehlschlägt.

Prüfung 1: der Tunnel schützt die Ursprungsadresse

Beginnen Sie mit einem Tunnel, der bereits Verkehr führt, und bestätigen Sie dann, dass die Adresse, die Sie veröffentlichen wollen, im geschützten Bereich liegt. Auf einer ASA stammt dieser Bereich aus der Krypto-ACL oder aus den Routen eines VTI, und er muss die echte Adresse des Ursprungs abdecken, nicht das Subnetz, das die Filiale für die Verwaltung nutzt. Ein Selektor, der den Ursprung verfehlt, liefert einen Tunnel, der steht, und einen Fluss, der nie in ihn hineingeht.

Bestätigen Sie das mit den Tunnelzählern und der Routentabelle, bevor Sie die Übersetzung anfassen. Ist der Ursprung vom Hub aus nicht über den Tunnel erreichbar, kann nichts weiter unten in dieser Liste das reparieren.

Stoppen Sie hier, wenn geschützter Bereich und Ursprungsadresse nicht übereinstimmen.

Prüfung 2: entscheiden Sie, welche Quelle die Filiale sieht

Die Filiale sieht entweder die ursprüngliche Client-Adresse oder eine übersetzte, und diese Wahl bestimmt den Rückweg. Die Client-Adresse zu bewahren liest sich in den Protokollen des Ursprungs sauberer, aber dann muss die Filiale Antworten für öffentliche Clients über den Tunnel zurückschicken; eine gewöhnliche Internet-Defaultroute schickt sie in die andere Richtung, und die Verbindung stirbt in eine Richtung. Die Quelle auf eine Adresse zu übersetzen, die die Filiale bereits über den Tunnel routet, beseitigt diese Anforderung.

Die Übersetzung ändert auch, was der Ursprung protokollieren kann und worauf quellenbasierte Regeln passen. Muss die Anwendung den Menschen hinter einer Anfrage kennen, gehört das in einen authentifizierten Reverse-Proxy, nicht in eine NAT-Entscheidung.

Prüfung 3: schreiben Sie die Übersetzung gegen die echten Schnittstellen

Eine ASA wertet Übersetzungsregeln der Reihe nach aus und meldet, welche gepasst hat, deshalb ist das Schnittstellenpaar in der Regel nicht kosmetisch. Eine Regel für einen Weg von außen nach innen passt nicht auf einen Fluss, dessen Eingang und Ausgang von den angenommenen abweichen.

Der Weg, den Sie bauen, hat vier Abschnitte, und alle vier müssen übereinstimmen:

Behandeln Sie die Bereiche in dieser Tabelle als Platzhalter. Entscheidend ist, dass das Tupel nach der Übersetzung eine Adresse ist, die die Filiale über den Tunnel akzeptiert, und dass die Rückabbildung im NAT-Zustand existiert, damit die Antwort auf dem Weg nach draußen wiederhergestellt wird.

Prüfung 4: begrenzen Sie die Zugriffsregel auf den veröffentlichten Port

Veröffentlichen Sie den Port, nicht den Host. Eine Regel, die den Ursprung auf jedem Dienst erlaubt, macht aus einer veröffentlichten Anwendung einen Weg zu allem, was der Ursprung ausführt, einschließlich der Verwaltungsschnittstelle, die Sie absichtlich aus dem Internet herausgehalten haben. Erlauben Sie den veröffentlichten Port von der übersetzten Quelle zum Ursprung, und lassen Sie administrative Dienste auf ihrem Nur-VPN-Weg.

Prüfen Sie gleichzeitig die Regelreihenfolge. Eine breite Erlaubnis über Ihrer spezifischen Regel macht die spezifische Regel unsichtbar.

Prüfung 5: verfolgen Sie eine Anfrage und ihre Antwort

Fangen Sie nicht mit einem Browser an, denn ein Browser verbirgt, welcher Abschnitt fehlgeschlagen ist. Verfolgen Sie den Fluss am Hub und lesen Sie das Ergebnis, bevor Sie etwas ändern.

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

Die Verfolgung nennt die Übersetzung, die gepasst hat, die Zugriffsregel, die den Fluss erlaubt oder verweigert hat, und ob das Paket in den Tunnel geroutet wurde. Zeigt sie den Fluss auf einer Schnittstelle, die Sie nicht erwartet haben, ist das Schnittstellenpaar in der NAT-Regel falsch. Zeigt sie eine Verweigerung, ist die Regelreihenfolge falsch. Erreicht er den Tunnel, aber der Ursprung antwortet nie, ist der Rückweg der Filiale das Problem.

Senden Sie dann eine echte Anfrage von außen und bestätigen Sie, dass die Antwort über denselben Tunnel zurückkommt. Halten Sie den veröffentlichten Eintrag, die Übersetzung, das geschützte Adresspaar und die Rückroute als Veröffentlichungsnachweis fest.